Skip to main content
143 commands across 25 modules. Every command is listed on its module’s page, grouped by what it does — orders, inventory, tickets, partners, and so on.
Gaps: none. Every command has a permission mapping, every mutation audits, and every client method it calls exists. This is checked on every release by the bot’s own release-verification script, not maintained by hand.

​
Categories

Orders

Refunds, cancellations, shipping, delivery and status changes

Invoices

Lookup and manual processing

Inventory

Stock, restocking, key delivery, crash recovery

Shop settings

Product info, bulk status/visibility, shop links

Customers

Lookup, balances, key lookup

Blacklist

Blocking customers from purchasing

Coupons

Shop-wide and product-scoped discounts

Product groups

Bundling products together

Affiliates & resellers

Referral codes, tiers, approvals

Purchase panels

Native in-Discord checkout

Role claim

Single-role purchase redemption

Role redemption

Granular per-product/variant role rules

Storefront

Payment methods, subscriptions, whitelist

Tickets

Support ticket handling

Feedback

Customer feedback

Analytics

Balance, overview, top performers

Insights

Abandoned checkouts, logs, traffic

Monitoring

Live SellAuth status monitor

Notifications

Sale/invoice/feedback/audit channels

Webhooks

Inbound webhook URL management

Permissions

Tier configuration per Discord role

Licensing

Registering, connecting, delegating

Admin

Health, help, servers list

Changelog

The bot’s own changelog

Utility

Standalone helpers

​
Permission tiers

Four tiers, least to most privileged: By default the only gate is the licence check — anyone with a registered (or delegated) licence can run anything at any tier. The tier system is opt-in per server. See Permissions to configure it, and Introduction for the full explanation of what each tier means and who is always owner.

​
Test coverage

143 of 143 commands are named by at least one test. A command is driven through its real callback by the test suite’s command kit, which loads the module’s actual register() and invokes the genuine function — never a re-implementation. Being named by a test is a floor, not a ceiling: it proves the command runs, not that every branch is checked. Every command is exercised, and the release check fails the build if that regresses.

​
Local by design

Commands that reach no SellAuth endpoint on purpose:
  • /leaveserver — a Discord-side operation — the bot leaves a guild, nothing shop-side
  • /permissions commands — renders the static capability table from core/capabilities.py
  • /setfeedback — SellAuth exposes no automatic-feedback setting on PUT /shops/{id}/update; the command says so rather than fabricating a toggle

​
What this does not tell you

A command page listing an endpoint means the command calls it, not that every branch of the command’s behaviour is covered end to end. It catches the command nobody tested at all, which is the failure worth catching automatically; depth of coverage still needs a person to judge.