Skip to main content
An account is an id that a login, a rate scope, a balance row and a call record all agree on. Nothing has to create it: an account exists the moment a login names it or a message arrives carrying it, and the app_account row is a label bolted on afterwards.

​
Leave accountId blank and something else becomes the account

accountId is optional on a credential, and what fills the gap differs by protocol.
An HTTP login with an apiKey and no accountId bills to the API key itself. The secret lands in cdr_submit.account_id, in the control panel’s revenue figures and in every CSV export — copied into records that live as long as billing history does, and that leave the platform in spreadsheets. Rotating the key afterwards splits that customer’s history across two ids.Set accountId explicitly on every credential and neither fallback matters.

​
Why the account and not the login

One account may hold several logins, and everything that carries money or a ceiling is keyed on the account:
A per-login limit would let a customer raise their own ceiling by creating another login. Keying on the account is what makes any of these mean something.
Approvals are the one thing that can go either way: a sender ID or template row may name a system_id to bind it to one login, or leave it null for every login on the account. See Sender IDs.

​
What the catalogue row actually holds

app_account is name, contact and hierarchy — nothing the message path reads. The tree is exactly two levels deep, and the database enforces it: app_account_two_levels refuses a row that both names a parent and resells, so an account either holds others or belongs to one.
Unlisting an account stops nothing. The gateway never reads the account catalogue, so clearing enabled removes the row from this panel’s lists and leaves its logins connecting, its traffic sending and its rate rules pricing exactly as before. It is the opposite of what enabled means on a vendor or a product, and far more expensive to get backwards.To stop traffic, disable the logins. To stop spend, use the balance.

​
Creating a login does not create a balance

An account with no account_balance row is not at zero — it has no balance, which is a different state and the one that quietly swallows a top-up.
A RECHARGE written for an account with no balance row credits nothing. It stays pending and logs, and applies itself the moment the row appears — but until then the customer has paid and cannot send. Open the account for credit first (Open for credit on the account page), then top up.
The panel tells the two apart deliberately: “no balance row” and “credit switched off” are shown as different answers rather than collapsed into one empty figure. See Prepaid credit.

​
An account id that is also a vendor name

Rating matches a rate scope by name alone, and the same table holds both sides of the trade. An id that is also a vendor instance name has its rules read as our cost for that vendor as well as what this customer pays. The account page paints that red rather than letting it be discovered in a margin report. Rename one before pricing either. * is reserved outright and cannot be used as an account or a vendor name.

​
What is on the account page

Logins

Who may connect as this account, what product each carries, and rotating a secret.

Custom tariff

What this account pays. No rules of its own means it is priced by whatever catch-all covers it.

Statement

What is owed for a period, billed on submitted — so the amount stops moving when the period does.

Sender IDs and content

The two approval lists and the enforcement switch beside them.
Traffic on the page is derived from the messages that actually arrived, split by login and product — so it shows traffic that came in under this account from a login this panel has never seen.