# Get an account's limits and enforcement state

Returns every plan limit of the account with its resolved threshold (the account's own number, or the platform default it follows), enforcement state, stored value, and whether the number is an operator-agreed limit; plus the vetting label and billing tier. `enforcement` is enforced, log_only (shadow mode: measured without refusing), or off (`limit` null). Shadow mode preserves the numeric threshold. This describes configured behavior, not transient ledger health or other refusal checks. The mailbox ceiling and the mailbox, address and domain creation limits bound the account's own key; an operator's system key is not held to them. Current usage is on send-usage, receive-usage and storage-usage.

## `GET /api/v1/accounts/{accountId}/limits`

### Path parameters

- `accountId` (string, required) — Account ULID identifier

### Responses

**200** — Every plan limit's resolved threshold and enforcement state

`application/json` → AccountLimits

- `accountId` (string, required) — Account ULID
- `billingTier` ("free" | "pro", required) — What the billing tool sold this account. Not a limit: Pro's numbers are stamped only once the account is also vetted (`plan` = `trusted`)
- `limits` (object, required) — Every plan limit, keyed by its field name on GET and PATCH /accounts/:accountId, which describe what each bounds. Each NULL value follows its platform default: send* the ACCOUNT_SEND_* vars; mailboxSend* (the default for a mailbox with no override of its own, which comes first) the per-mailbox SEND_* vars; recvMsgsPerDay/recvBytesPerDay ACCOUNT_RECV_*; storageLimitBytes ACCOUNT_STORAGE_LIMIT_BYTES; maxMailboxes MAX_MAILBOXES_DEFAULT (no API stores 0 for it: positive or null; a row holding 0 anyway is a ceiling of zero, reported as limit 0, enforced, not as unlimited); mailboxCreatesPerDay, addressCreatesPerDay, domainCreatesPerDay MAX_{MAILBOX,ADDRESS,DOMAIN}_CREATES_PER_DAY and forwardMsgsPerDay FORWARD_MSGS_PER_DAY, each of which is also the limit's on switch; maxMailTemplates MAX_MAIL_TEMPLATES_DEFAULT, where a blank default is the built-in 50, so its limit is null only when unlimited. forwardMsgsPerDay is counted per domain: N domains get N x this
  - `addressCreatesPerDay` (AccountLimitInForce, required)
    - `agreed` (boolean, required) — True if this number is the account's AGREED LIMIT: an operator set it on this account with PATCH /accounts/:accountId, and no plan stamp (vet, revoke, billing-tier change) replaces it. An agreement of the platform default (value null) is an agreement too. While the account is unvetted, the stamped value is the stricter of the agreement and the unvetted number, so `value` can be lower than what was agreed
    - `enforcement` ("enforced" | "log_only" | "off", required) — Configured behavior of this threshold: enforced = exceeding it can trigger refusal; log_only = measured and logged without refusing; off = no threshold applies (`limit` is null). SEND_LIMITS_LOG_ONLY shadows the eight send/mailbox-send limits, the three creation limits and forwarding; RECV_LIMITS_LOG_ONLY shadows both receive limits; STORAGE_LIMITS_LOG_ONLY shadows the account storage pool. Only the exact flag value true enables shadow mode. maxMailboxes and maxMailTemplates remain enforced when finite. This describes limit configuration, not transient ledger health or other refusal checks
    - `limit` (integer | null, required) — The resolved threshold used by the limit's check: the account's own number, or the platform default when the account stores none. Shadow mode preserves this number; `enforcement` says whether exceeding it can trigger refusal. null = no threshold applies on this axis: the account stores 0 (explicitly unlimited), or it stores null and the platform default is blank or 0, or (mailboxCreatesPerDay, addressCreatesPerDay, domainCreatesPerDay, forwardMsgsPerDay) the deployment has that limit switched off, which makes any account number inert. `value` says which
    - `value` (integer | null, required) — The account's stored number, as GET /accounts/:accountId reports it: null = the account follows the platform default, 0 = explicitly unlimited (except maxMailboxes, which has no such spelling), n = the account's own number. With `limit` it tells the causes of a null limit apart: value 0 = the account is unlimited; value null = the platform sets no bound; value n with a null limit = the deployment has the limit switched off
  - `domainCreatesPerDay` (AccountLimitInForce, required)
    - `agreed` (boolean, required) — True if this number is the account's AGREED LIMIT: an operator set it on this account with PATCH /accounts/:accountId, and no plan stamp (vet, revoke, billing-tier change) replaces it. An agreement of the platform default (value null) is an agreement too. While the account is unvetted, the stamped value is the stricter of the agreement and the unvetted number, so `value` can be lower than what was agreed
    - `enforcement` ("enforced" | "log_only" | "off", required) — Configured behavior of this threshold: enforced = exceeding it can trigger refusal; log_only = measured and logged without refusing; off = no threshold applies (`limit` is null). SEND_LIMITS_LOG_ONLY shadows the eight send/mailbox-send limits, the three creation limits and forwarding; RECV_LIMITS_LOG_ONLY shadows both receive limits; STORAGE_LIMITS_LOG_ONLY shadows the account storage pool. Only the exact flag value true enables shadow mode. maxMailboxes and maxMailTemplates remain enforced when finite. This describes limit configuration, not transient ledger health or other refusal checks
    - `limit` (integer | null, required) — The resolved threshold used by the limit's check: the account's own number, or the platform default when the account stores none. Shadow mode preserves this number; `enforcement` says whether exceeding it can trigger refusal. null = no threshold applies on this axis: the account stores 0 (explicitly unlimited), or it stores null and the platform default is blank or 0, or (mailboxCreatesPerDay, addressCreatesPerDay, domainCreatesPerDay, forwardMsgsPerDay) the deployment has that limit switched off, which makes any account number inert. `value` says which
    - `value` (integer | null, required) — The account's stored number, as GET /accounts/:accountId reports it: null = the account follows the platform default, 0 = explicitly unlimited (except maxMailboxes, which has no such spelling), n = the account's own number. With `limit` it tells the causes of a null limit apart: value 0 = the account is unlimited; value null = the platform sets no bound; value n with a null limit = the deployment has the limit switched off
  - `forwardMsgsPerDay` (AccountLimitInForce, required)
    - `agreed` (boolean, required) — True if this number is the account's AGREED LIMIT: an operator set it on this account with PATCH /accounts/:accountId, and no plan stamp (vet, revoke, billing-tier change) replaces it. An agreement of the platform default (value null) is an agreement too. While the account is unvetted, the stamped value is the stricter of the agreement and the unvetted number, so `value` can be lower than what was agreed
    - `enforcement` ("enforced" | "log_only" | "off", required) — Configured behavior of this threshold: enforced = exceeding it can trigger refusal; log_only = measured and logged without refusing; off = no threshold applies (`limit` is null). SEND_LIMITS_LOG_ONLY shadows the eight send/mailbox-send limits, the three creation limits and forwarding; RECV_LIMITS_LOG_ONLY shadows both receive limits; STORAGE_LIMITS_LOG_ONLY shadows the account storage pool. Only the exact flag value true enables shadow mode. maxMailboxes and maxMailTemplates remain enforced when finite. This describes limit configuration, not transient ledger health or other refusal checks
    - `limit` (integer | null, required) — The resolved threshold used by the limit's check: the account's own number, or the platform default when the account stores none. Shadow mode preserves this number; `enforcement` says whether exceeding it can trigger refusal. null = no threshold applies on this axis: the account stores 0 (explicitly unlimited), or it stores null and the platform default is blank or 0, or (mailboxCreatesPerDay, addressCreatesPerDay, domainCreatesPerDay, forwardMsgsPerDay) the deployment has that limit switched off, which makes any account number inert. `value` says which
    - `value` (integer | null, required) — The account's stored number, as GET /accounts/:accountId reports it: null = the account follows the platform default, 0 = explicitly unlimited (except maxMailboxes, which has no such spelling), n = the account's own number. With `limit` it tells the causes of a null limit apart: value 0 = the account is unlimited; value null = the platform sets no bound; value n with a null limit = the deployment has the limit switched off
  - `mailboxCreatesPerDay` (AccountLimitInForce, required)
    - `agreed` (boolean, required) — True if this number is the account's AGREED LIMIT: an operator set it on this account with PATCH /accounts/:accountId, and no plan stamp (vet, revoke, billing-tier change) replaces it. An agreement of the platform default (value null) is an agreement too. While the account is unvetted, the stamped value is the stricter of the agreement and the unvetted number, so `value` can be lower than what was agreed
    - `enforcement` ("enforced" | "log_only" | "off", required) — Configured behavior of this threshold: enforced = exceeding it can trigger refusal; log_only = measured and logged without refusing; off = no threshold applies (`limit` is null). SEND_LIMITS_LOG_ONLY shadows the eight send/mailbox-send limits, the three creation limits and forwarding; RECV_LIMITS_LOG_ONLY shadows both receive limits; STORAGE_LIMITS_LOG_ONLY shadows the account storage pool. Only the exact flag value true enables shadow mode. maxMailboxes and maxMailTemplates remain enforced when finite. This describes limit configuration, not transient ledger health or other refusal checks
    - `limit` (integer | null, required) — The resolved threshold used by the limit's check: the account's own number, or the platform default when the account stores none. Shadow mode preserves this number; `enforcement` says whether exceeding it can trigger refusal. null = no threshold applies on this axis: the account stores 0 (explicitly unlimited), or it stores null and the platform default is blank or 0, or (mailboxCreatesPerDay, addressCreatesPerDay, domainCreatesPerDay, forwardMsgsPerDay) the deployment has that limit switched off, which makes any account number inert. `value` says which
    - `value` (integer | null, required) — The account's stored number, as GET /accounts/:accountId reports it: null = the account follows the platform default, 0 = explicitly unlimited (except maxMailboxes, which has no such spelling), n = the account's own number. With `limit` it tells the causes of a null limit apart: value 0 = the account is unlimited; value null = the platform sets no bound; value n with a null limit = the deployment has the limit switched off
  - `mailboxSendMsgsPerDay` (AccountLimitInForce, required)
    - `agreed` (boolean, required) — True if this number is the account's AGREED LIMIT: an operator set it on this account with PATCH /accounts/:accountId, and no plan stamp (vet, revoke, billing-tier change) replaces it. An agreement of the platform default (value null) is an agreement too. While the account is unvetted, the stamped value is the stricter of the agreement and the unvetted number, so `value` can be lower than what was agreed
    - `enforcement` ("enforced" | "log_only" | "off", required) — Configured behavior of this threshold: enforced = exceeding it can trigger refusal; log_only = measured and logged without refusing; off = no threshold applies (`limit` is null). SEND_LIMITS_LOG_ONLY shadows the eight send/mailbox-send limits, the three creation limits and forwarding; RECV_LIMITS_LOG_ONLY shadows both receive limits; STORAGE_LIMITS_LOG_ONLY shadows the account storage pool. Only the exact flag value true enables shadow mode. maxMailboxes and maxMailTemplates remain enforced when finite. This describes limit configuration, not transient ledger health or other refusal checks
    - `limit` (integer | null, required) — The resolved threshold used by the limit's check: the account's own number, or the platform default when the account stores none. Shadow mode preserves this number; `enforcement` says whether exceeding it can trigger refusal. null = no threshold applies on this axis: the account stores 0 (explicitly unlimited), or it stores null and the platform default is blank or 0, or (mailboxCreatesPerDay, addressCreatesPerDay, domainCreatesPerDay, forwardMsgsPerDay) the deployment has that limit switched off, which makes any account number inert. `value` says which
    - `value` (integer | null, required) — The account's stored number, as GET /accounts/:accountId reports it: null = the account follows the platform default, 0 = explicitly unlimited (except maxMailboxes, which has no such spelling), n = the account's own number. With `limit` it tells the causes of a null limit apart: value 0 = the account is unlimited; value null = the platform sets no bound; value n with a null limit = the deployment has the limit switched off
  - `mailboxSendMsgsPerHour` (AccountLimitInForce, required)
    - `agreed` (boolean, required) — True if this number is the account's AGREED LIMIT: an operator set it on this account with PATCH /accounts/:accountId, and no plan stamp (vet, revoke, billing-tier change) replaces it. An agreement of the platform default (value null) is an agreement too. While the account is unvetted, the stamped value is the stricter of the agreement and the unvetted number, so `value` can be lower than what was agreed
    - `enforcement` ("enforced" | "log_only" | "off", required) — Configured behavior of this threshold: enforced = exceeding it can trigger refusal; log_only = measured and logged without refusing; off = no threshold applies (`limit` is null). SEND_LIMITS_LOG_ONLY shadows the eight send/mailbox-send limits, the three creation limits and forwarding; RECV_LIMITS_LOG_ONLY shadows both receive limits; STORAGE_LIMITS_LOG_ONLY shadows the account storage pool. Only the exact flag value true enables shadow mode. maxMailboxes and maxMailTemplates remain enforced when finite. This describes limit configuration, not transient ledger health or other refusal checks
    - `limit` (integer | null, required) — The resolved threshold used by the limit's check: the account's own number, or the platform default when the account stores none. Shadow mode preserves this number; `enforcement` says whether exceeding it can trigger refusal. null = no threshold applies on this axis: the account stores 0 (explicitly unlimited), or it stores null and the platform default is blank or 0, or (mailboxCreatesPerDay, addressCreatesPerDay, domainCreatesPerDay, forwardMsgsPerDay) the deployment has that limit switched off, which makes any account number inert. `value` says which
    - `value` (integer | null, required) — The account's stored number, as GET /accounts/:accountId reports it: null = the account follows the platform default, 0 = explicitly unlimited (except maxMailboxes, which has no such spelling), n = the account's own number. With `limit` it tells the causes of a null limit apart: value 0 = the account is unlimited; value null = the platform sets no bound; value n with a null limit = the deployment has the limit switched off
  - `mailboxSendRcptsPerDay` (AccountLimitInForce, required)
    - `agreed` (boolean, required) — True if this number is the account's AGREED LIMIT: an operator set it on this account with PATCH /accounts/:accountId, and no plan stamp (vet, revoke, billing-tier change) replaces it. An agreement of the platform default (value null) is an agreement too. While the account is unvetted, the stamped value is the stricter of the agreement and the unvetted number, so `value` can be lower than what was agreed
    - `enforcement` ("enforced" | "log_only" | "off", required) — Configured behavior of this threshold: enforced = exceeding it can trigger refusal; log_only = measured and logged without refusing; off = no threshold applies (`limit` is null). SEND_LIMITS_LOG_ONLY shadows the eight send/mailbox-send limits, the three creation limits and forwarding; RECV_LIMITS_LOG_ONLY shadows both receive limits; STORAGE_LIMITS_LOG_ONLY shadows the account storage pool. Only the exact flag value true enables shadow mode. maxMailboxes and maxMailTemplates remain enforced when finite. This describes limit configuration, not transient ledger health or other refusal checks
    - `limit` (integer | null, required) — The resolved threshold used by the limit's check: the account's own number, or the platform default when the account stores none. Shadow mode preserves this number; `enforcement` says whether exceeding it can trigger refusal. null = no threshold applies on this axis: the account stores 0 (explicitly unlimited), or it stores null and the platform default is blank or 0, or (mailboxCreatesPerDay, addressCreatesPerDay, domainCreatesPerDay, forwardMsgsPerDay) the deployment has that limit switched off, which makes any account number inert. `value` says which
    - `value` (integer | null, required) — The account's stored number, as GET /accounts/:accountId reports it: null = the account follows the platform default, 0 = explicitly unlimited (except maxMailboxes, which has no such spelling), n = the account's own number. With `limit` it tells the causes of a null limit apart: value 0 = the account is unlimited; value null = the platform sets no bound; value n with a null limit = the deployment has the limit switched off
  - `mailboxSendRcptsPerHour` (AccountLimitInForce, required)
    - `agreed` (boolean, required) — True if this number is the account's AGREED LIMIT: an operator set it on this account with PATCH /accounts/:accountId, and no plan stamp (vet, revoke, billing-tier change) replaces it. An agreement of the platform default (value null) is an agreement too. While the account is unvetted, the stamped value is the stricter of the agreement and the unvetted number, so `value` can be lower than what was agreed
    - `enforcement` ("enforced" | "log_only" | "off", required) — Configured behavior of this threshold: enforced = exceeding it can trigger refusal; log_only = measured and logged without refusing; off = no threshold applies (`limit` is null). SEND_LIMITS_LOG_ONLY shadows the eight send/mailbox-send limits, the three creation limits and forwarding; RECV_LIMITS_LOG_ONLY shadows both receive limits; STORAGE_LIMITS_LOG_ONLY shadows the account storage pool. Only the exact flag value true enables shadow mode. maxMailboxes and maxMailTemplates remain enforced when finite. This describes limit configuration, not transient ledger health or other refusal checks
    - `limit` (integer | null, required) — The resolved threshold used by the limit's check: the account's own number, or the platform default when the account stores none. Shadow mode preserves this number; `enforcement` says whether exceeding it can trigger refusal. null = no threshold applies on this axis: the account stores 0 (explicitly unlimited), or it stores null and the platform default is blank or 0, or (mailboxCreatesPerDay, addressCreatesPerDay, domainCreatesPerDay, forwardMsgsPerDay) the deployment has that limit switched off, which makes any account number inert. `value` says which
    - `value` (integer | null, required) — The account's stored number, as GET /accounts/:accountId reports it: null = the account follows the platform default, 0 = explicitly unlimited (except maxMailboxes, which has no such spelling), n = the account's own number. With `limit` it tells the causes of a null limit apart: value 0 = the account is unlimited; value null = the platform sets no bound; value n with a null limit = the deployment has the limit switched off
  - `maxMailboxes` (AccountLimitInForce, required)
    - `agreed` (boolean, required) — True if this number is the account's AGREED LIMIT: an operator set it on this account with PATCH /accounts/:accountId, and no plan stamp (vet, revoke, billing-tier change) replaces it. An agreement of the platform default (value null) is an agreement too. While the account is unvetted, the stamped value is the stricter of the agreement and the unvetted number, so `value` can be lower than what was agreed
    - `enforcement` ("enforced" | "log_only" | "off", required) — Configured behavior of this threshold: enforced = exceeding it can trigger refusal; log_only = measured and logged without refusing; off = no threshold applies (`limit` is null). SEND_LIMITS_LOG_ONLY shadows the eight send/mailbox-send limits, the three creation limits and forwarding; RECV_LIMITS_LOG_ONLY shadows both receive limits; STORAGE_LIMITS_LOG_ONLY shadows the account storage pool. Only the exact flag value true enables shadow mode. maxMailboxes and maxMailTemplates remain enforced when finite. This describes limit configuration, not transient ledger health or other refusal checks
    - `limit` (integer | null, required) — The resolved threshold used by the limit's check: the account's own number, or the platform default when the account stores none. Shadow mode preserves this number; `enforcement` says whether exceeding it can trigger refusal. null = no threshold applies on this axis: the account stores 0 (explicitly unlimited), or it stores null and the platform default is blank or 0, or (mailboxCreatesPerDay, addressCreatesPerDay, domainCreatesPerDay, forwardMsgsPerDay) the deployment has that limit switched off, which makes any account number inert. `value` says which
    - `value` (integer | null, required) — The account's stored number, as GET /accounts/:accountId reports it: null = the account follows the platform default, 0 = explicitly unlimited (except maxMailboxes, which has no such spelling), n = the account's own number. With `limit` it tells the causes of a null limit apart: value 0 = the account is unlimited; value null = the platform sets no bound; value n with a null limit = the deployment has the limit switched off
  - `maxMailTemplates` (AccountLimitInForce, required)
    - `agreed` (boolean, required) — True if this number is the account's AGREED LIMIT: an operator set it on this account with PATCH /accounts/:accountId, and no plan stamp (vet, revoke, billing-tier change) replaces it. An agreement of the platform default (value null) is an agreement too. While the account is unvetted, the stamped value is the stricter of the agreement and the unvetted number, so `value` can be lower than what was agreed
    - `enforcement` ("enforced" | "log_only" | "off", required) — Configured behavior of this threshold: enforced = exceeding it can trigger refusal; log_only = measured and logged without refusing; off = no threshold applies (`limit` is null). SEND_LIMITS_LOG_ONLY shadows the eight send/mailbox-send limits, the three creation limits and forwarding; RECV_LIMITS_LOG_ONLY shadows both receive limits; STORAGE_LIMITS_LOG_ONLY shadows the account storage pool. Only the exact flag value true enables shadow mode. maxMailboxes and maxMailTemplates remain enforced when finite. This describes limit configuration, not transient ledger health or other refusal checks
    - `limit` (integer | null, required) — The resolved threshold used by the limit's check: the account's own number, or the platform default when the account stores none. Shadow mode preserves this number; `enforcement` says whether exceeding it can trigger refusal. null = no threshold applies on this axis: the account stores 0 (explicitly unlimited), or it stores null and the platform default is blank or 0, or (mailboxCreatesPerDay, addressCreatesPerDay, domainCreatesPerDay, forwardMsgsPerDay) the deployment has that limit switched off, which makes any account number inert. `value` says which
    - `value` (integer | null, required) — The account's stored number, as GET /accounts/:accountId reports it: null = the account follows the platform default, 0 = explicitly unlimited (except maxMailboxes, which has no such spelling), n = the account's own number. With `limit` it tells the causes of a null limit apart: value 0 = the account is unlimited; value null = the platform sets no bound; value n with a null limit = the deployment has the limit switched off
  - `recvBytesPerDay` (AccountLimitInForce, required)
    - `agreed` (boolean, required) — True if this number is the account's AGREED LIMIT: an operator set it on this account with PATCH /accounts/:accountId, and no plan stamp (vet, revoke, billing-tier change) replaces it. An agreement of the platform default (value null) is an agreement too. While the account is unvetted, the stamped value is the stricter of the agreement and the unvetted number, so `value` can be lower than what was agreed
    - `enforcement` ("enforced" | "log_only" | "off", required) — Configured behavior of this threshold: enforced = exceeding it can trigger refusal; log_only = measured and logged without refusing; off = no threshold applies (`limit` is null). SEND_LIMITS_LOG_ONLY shadows the eight send/mailbox-send limits, the three creation limits and forwarding; RECV_LIMITS_LOG_ONLY shadows both receive limits; STORAGE_LIMITS_LOG_ONLY shadows the account storage pool. Only the exact flag value true enables shadow mode. maxMailboxes and maxMailTemplates remain enforced when finite. This describes limit configuration, not transient ledger health or other refusal checks
    - `limit` (integer | null, required) — The resolved threshold used by the limit's check: the account's own number, or the platform default when the account stores none. Shadow mode preserves this number; `enforcement` says whether exceeding it can trigger refusal. null = no threshold applies on this axis: the account stores 0 (explicitly unlimited), or it stores null and the platform default is blank or 0, or (mailboxCreatesPerDay, addressCreatesPerDay, domainCreatesPerDay, forwardMsgsPerDay) the deployment has that limit switched off, which makes any account number inert. `value` says which
    - `value` (integer | null, required) — The account's stored number, as GET /accounts/:accountId reports it: null = the account follows the platform default, 0 = explicitly unlimited (except maxMailboxes, which has no such spelling), n = the account's own number. With `limit` it tells the causes of a null limit apart: value 0 = the account is unlimited; value null = the platform sets no bound; value n with a null limit = the deployment has the limit switched off
  - `recvMsgsPerDay` (AccountLimitInForce, required)
    - `agreed` (boolean, required) — True if this number is the account's AGREED LIMIT: an operator set it on this account with PATCH /accounts/:accountId, and no plan stamp (vet, revoke, billing-tier change) replaces it. An agreement of the platform default (value null) is an agreement too. While the account is unvetted, the stamped value is the stricter of the agreement and the unvetted number, so `value` can be lower than what was agreed
    - `enforcement` ("enforced" | "log_only" | "off", required) — Configured behavior of this threshold: enforced = exceeding it can trigger refusal; log_only = measured and logged without refusing; off = no threshold applies (`limit` is null). SEND_LIMITS_LOG_ONLY shadows the eight send/mailbox-send limits, the three creation limits and forwarding; RECV_LIMITS_LOG_ONLY shadows both receive limits; STORAGE_LIMITS_LOG_ONLY shadows the account storage pool. Only the exact flag value true enables shadow mode. maxMailboxes and maxMailTemplates remain enforced when finite. This describes limit configuration, not transient ledger health or other refusal checks
    - `limit` (integer | null, required) — The resolved threshold used by the limit's check: the account's own number, or the platform default when the account stores none. Shadow mode preserves this number; `enforcement` says whether exceeding it can trigger refusal. null = no threshold applies on this axis: the account stores 0 (explicitly unlimited), or it stores null and the platform default is blank or 0, or (mailboxCreatesPerDay, addressCreatesPerDay, domainCreatesPerDay, forwardMsgsPerDay) the deployment has that limit switched off, which makes any account number inert. `value` says which
    - `value` (integer | null, required) — The account's stored number, as GET /accounts/:accountId reports it: null = the account follows the platform default, 0 = explicitly unlimited (except maxMailboxes, which has no such spelling), n = the account's own number. With `limit` it tells the causes of a null limit apart: value 0 = the account is unlimited; value null = the platform sets no bound; value n with a null limit = the deployment has the limit switched off
  - `sendMsgsPerDay` (AccountLimitInForce, required)
    - `agreed` (boolean, required) — True if this number is the account's AGREED LIMIT: an operator set it on this account with PATCH /accounts/:accountId, and no plan stamp (vet, revoke, billing-tier change) replaces it. An agreement of the platform default (value null) is an agreement too. While the account is unvetted, the stamped value is the stricter of the agreement and the unvetted number, so `value` can be lower than what was agreed
    - `enforcement` ("enforced" | "log_only" | "off", required) — Configured behavior of this threshold: enforced = exceeding it can trigger refusal; log_only = measured and logged without refusing; off = no threshold applies (`limit` is null). SEND_LIMITS_LOG_ONLY shadows the eight send/mailbox-send limits, the three creation limits and forwarding; RECV_LIMITS_LOG_ONLY shadows both receive limits; STORAGE_LIMITS_LOG_ONLY shadows the account storage pool. Only the exact flag value true enables shadow mode. maxMailboxes and maxMailTemplates remain enforced when finite. This describes limit configuration, not transient ledger health or other refusal checks
    - `limit` (integer | null, required) — The resolved threshold used by the limit's check: the account's own number, or the platform default when the account stores none. Shadow mode preserves this number; `enforcement` says whether exceeding it can trigger refusal. null = no threshold applies on this axis: the account stores 0 (explicitly unlimited), or it stores null and the platform default is blank or 0, or (mailboxCreatesPerDay, addressCreatesPerDay, domainCreatesPerDay, forwardMsgsPerDay) the deployment has that limit switched off, which makes any account number inert. `value` says which
    - `value` (integer | null, required) — The account's stored number, as GET /accounts/:accountId reports it: null = the account follows the platform default, 0 = explicitly unlimited (except maxMailboxes, which has no such spelling), n = the account's own number. With `limit` it tells the causes of a null limit apart: value 0 = the account is unlimited; value null = the platform sets no bound; value n with a null limit = the deployment has the limit switched off
  - `sendMsgsPerHour` (AccountLimitInForce, required)
    - `agreed` (boolean, required) — True if this number is the account's AGREED LIMIT: an operator set it on this account with PATCH /accounts/:accountId, and no plan stamp (vet, revoke, billing-tier change) replaces it. An agreement of the platform default (value null) is an agreement too. While the account is unvetted, the stamped value is the stricter of the agreement and the unvetted number, so `value` can be lower than what was agreed
    - `enforcement` ("enforced" | "log_only" | "off", required) — Configured behavior of this threshold: enforced = exceeding it can trigger refusal; log_only = measured and logged without refusing; off = no threshold applies (`limit` is null). SEND_LIMITS_LOG_ONLY shadows the eight send/mailbox-send limits, the three creation limits and forwarding; RECV_LIMITS_LOG_ONLY shadows both receive limits; STORAGE_LIMITS_LOG_ONLY shadows the account storage pool. Only the exact flag value true enables shadow mode. maxMailboxes and maxMailTemplates remain enforced when finite. This describes limit configuration, not transient ledger health or other refusal checks
    - `limit` (integer | null, required) — The resolved threshold used by the limit's check: the account's own number, or the platform default when the account stores none. Shadow mode preserves this number; `enforcement` says whether exceeding it can trigger refusal. null = no threshold applies on this axis: the account stores 0 (explicitly unlimited), or it stores null and the platform default is blank or 0, or (mailboxCreatesPerDay, addressCreatesPerDay, domainCreatesPerDay, forwardMsgsPerDay) the deployment has that limit switched off, which makes any account number inert. `value` says which
    - `value` (integer | null, required) — The account's stored number, as GET /accounts/:accountId reports it: null = the account follows the platform default, 0 = explicitly unlimited (except maxMailboxes, which has no such spelling), n = the account's own number. With `limit` it tells the causes of a null limit apart: value 0 = the account is unlimited; value null = the platform sets no bound; value n with a null limit = the deployment has the limit switched off
  - `sendRcptsPerDay` (AccountLimitInForce, required)
    - `agreed` (boolean, required) — True if this number is the account's AGREED LIMIT: an operator set it on this account with PATCH /accounts/:accountId, and no plan stamp (vet, revoke, billing-tier change) replaces it. An agreement of the platform default (value null) is an agreement too. While the account is unvetted, the stamped value is the stricter of the agreement and the unvetted number, so `value` can be lower than what was agreed
    - `enforcement` ("enforced" | "log_only" | "off", required) — Configured behavior of this threshold: enforced = exceeding it can trigger refusal; log_only = measured and logged without refusing; off = no threshold applies (`limit` is null). SEND_LIMITS_LOG_ONLY shadows the eight send/mailbox-send limits, the three creation limits and forwarding; RECV_LIMITS_LOG_ONLY shadows both receive limits; STORAGE_LIMITS_LOG_ONLY shadows the account storage pool. Only the exact flag value true enables shadow mode. maxMailboxes and maxMailTemplates remain enforced when finite. This describes limit configuration, not transient ledger health or other refusal checks
    - `limit` (integer | null, required) — The resolved threshold used by the limit's check: the account's own number, or the platform default when the account stores none. Shadow mode preserves this number; `enforcement` says whether exceeding it can trigger refusal. null = no threshold applies on this axis: the account stores 0 (explicitly unlimited), or it stores null and the platform default is blank or 0, or (mailboxCreatesPerDay, addressCreatesPerDay, domainCreatesPerDay, forwardMsgsPerDay) the deployment has that limit switched off, which makes any account number inert. `value` says which
    - `value` (integer | null, required) — The account's stored number, as GET /accounts/:accountId reports it: null = the account follows the platform default, 0 = explicitly unlimited (except maxMailboxes, which has no such spelling), n = the account's own number. With `limit` it tells the causes of a null limit apart: value 0 = the account is unlimited; value null = the platform sets no bound; value n with a null limit = the deployment has the limit switched off
  - `sendRcptsPerHour` (AccountLimitInForce, required)
    - `agreed` (boolean, required) — True if this number is the account's AGREED LIMIT: an operator set it on this account with PATCH /accounts/:accountId, and no plan stamp (vet, revoke, billing-tier change) replaces it. An agreement of the platform default (value null) is an agreement too. While the account is unvetted, the stamped value is the stricter of the agreement and the unvetted number, so `value` can be lower than what was agreed
    - `enforcement` ("enforced" | "log_only" | "off", required) — Configured behavior of this threshold: enforced = exceeding it can trigger refusal; log_only = measured and logged without refusing; off = no threshold applies (`limit` is null). SEND_LIMITS_LOG_ONLY shadows the eight send/mailbox-send limits, the three creation limits and forwarding; RECV_LIMITS_LOG_ONLY shadows both receive limits; STORAGE_LIMITS_LOG_ONLY shadows the account storage pool. Only the exact flag value true enables shadow mode. maxMailboxes and maxMailTemplates remain enforced when finite. This describes limit configuration, not transient ledger health or other refusal checks
    - `limit` (integer | null, required) — The resolved threshold used by the limit's check: the account's own number, or the platform default when the account stores none. Shadow mode preserves this number; `enforcement` says whether exceeding it can trigger refusal. null = no threshold applies on this axis: the account stores 0 (explicitly unlimited), or it stores null and the platform default is blank or 0, or (mailboxCreatesPerDay, addressCreatesPerDay, domainCreatesPerDay, forwardMsgsPerDay) the deployment has that limit switched off, which makes any account number inert. `value` says which
    - `value` (integer | null, required) — The account's stored number, as GET /accounts/:accountId reports it: null = the account follows the platform default, 0 = explicitly unlimited (except maxMailboxes, which has no such spelling), n = the account's own number. With `limit` it tells the causes of a null limit apart: value 0 = the account is unlimited; value null = the platform sets no bound; value n with a null limit = the deployment has the limit switched off
  - `storageLimitBytes` (AccountLimitInForce, required)
    - `agreed` (boolean, required) — True if this number is the account's AGREED LIMIT: an operator set it on this account with PATCH /accounts/:accountId, and no plan stamp (vet, revoke, billing-tier change) replaces it. An agreement of the platform default (value null) is an agreement too. While the account is unvetted, the stamped value is the stricter of the agreement and the unvetted number, so `value` can be lower than what was agreed
    - `enforcement` ("enforced" | "log_only" | "off", required) — Configured behavior of this threshold: enforced = exceeding it can trigger refusal; log_only = measured and logged without refusing; off = no threshold applies (`limit` is null). SEND_LIMITS_LOG_ONLY shadows the eight send/mailbox-send limits, the three creation limits and forwarding; RECV_LIMITS_LOG_ONLY shadows both receive limits; STORAGE_LIMITS_LOG_ONLY shadows the account storage pool. Only the exact flag value true enables shadow mode. maxMailboxes and maxMailTemplates remain enforced when finite. This describes limit configuration, not transient ledger health or other refusal checks
    - `limit` (integer | null, required) — The resolved threshold used by the limit's check: the account's own number, or the platform default when the account stores none. Shadow mode preserves this number; `enforcement` says whether exceeding it can trigger refusal. null = no threshold applies on this axis: the account stores 0 (explicitly unlimited), or it stores null and the platform default is blank or 0, or (mailboxCreatesPerDay, addressCreatesPerDay, domainCreatesPerDay, forwardMsgsPerDay) the deployment has that limit switched off, which makes any account number inert. `value` says which
    - `value` (integer | null, required) — The account's stored number, as GET /accounts/:accountId reports it: null = the account follows the platform default, 0 = explicitly unlimited (except maxMailboxes, which has no such spelling), n = the account's own number. With `limit` it tells the causes of a null limit apart: value 0 = the account is unlimited; value null = the platform sets no bound; value n with a null limit = the deployment has the limit switched off
- `plan` (string | null, required) — The account's vetting label (`untrusted`, `trusted`, or a tooling tier's name; null = no plan recorded). Display only: the limits below describe the resolved thresholds and their enforcement state

**401** — unauthorized: the bearer credential is missing, malformed, expired, or revoked. Carries a `WWW-Authenticate: Bearer` challenge

`application/json` → ErrorBody

**404** — Account not found or not accessible to this principal

`application/json` → ErrorBody

**503** — temporary_failure: the platform's storage could not answer just now; retry after the Retry-After window. Any operation can answer this. A write that got it may have been applied, so retry it with the same idempotency key where it takes one, or read the state back first (see Transient failures in the API description)

`application/json` → ErrorBody

### Example request

```bash
curl -X GET 'https://api.open.email/api/v1/accounts/{accountId}/limits' \
  -H 'Authorization: Bearer oek_…'
```