Get your plan and current usage
GET/v1/organization/usage
x-scope: "usage:read"
Your organization's plan, its subscription status and the billing period that covers
now, with the messages and agents used against the limits Mojeeb's checks enforce.
Company-wide, whatever the key's agent list, and read-only. It never returns prices or
payment details. When no single billing period covers now, the answer is 409:
no_current_usage_period when none does (it clears when the renewal lands, and it is
also the answer with no subscription at all) or usage_periods_overlap when more than
one does.
Request
Responses
- 200
- 401
- 403
- 409
- 429
- 500
The plan and the current period's usage.
Response Headers
Correlation id for this request — paste into support tickets.
Authentication failed. Single code (invalid_api_key) covers every
sub-case: missing header, wrong scheme, malformed, unknown, revoked or
expired key. The message field disambiguates for humans debugging.
One exception: when the key could not be checked because of a server-side
fault, the status is still 401 but type is internal_error and code
is internal_server_error; retry with backoff.
Response Headers
Correlation id for this request — paste into support tickets.
insufficient_scope: the key lacks the scope in this operation's x-scope.
Response Headers
Correlation id for this request — paste into support tickets.
Mojeeb can't name one current billing period for your organization, so
it can't tell which limits apply. no_current_usage_period: no period
covers now, so Mojeeb treats the subscription as not renewed; it clears
when the renewal lands. usage_periods_overlap: more than one period
covers now. If either lasts, contact support with the correlation_id.
Response Headers
Correlation id for this request — paste into support tickets.
Per-key rate limit hit. Default is 60/min/key; an endpoint with an
x-rate-limit-per-minute of its own counts in a budget of its own
(today listWhatsAppTemplates, which allows 10/min/key, and
sendConversationMessage, which allows 20/min/key), and its 429
reports that limit in X-RateLimit-Limit. Retry-After tells you when to retry;
X-RateLimit-Reset is the Unix timestamp of the next window.
Per-success-response
X-RateLimit-*headers are a known gap; on 2xx responses these headers are NOT currently emitted. Customers should rely on 429 +Retry-Afterfor backoff signals.
Response Headers
Correlation id for this request — paste into support tickets.
Seconds to wait before retrying.
The per-minute request limit of the endpoint called. Every key has the same limits today.
Remaining requests in the current window. 0 on rejection.
Unix timestamp at which the current window resets.
Unexpected server-side failure. Retry with exponential backoff. If
the failure persists, send us the correlation_id.
Response Headers
Correlation id for this request — paste into support tickets.