Errors & status codes
The complete reference: every status code and the response shapes behind it.
Usage gating & limits
The admission gate and the
402 / 403 / 429 responses it returns.Errors & troubleshooting
What do the common error codes mean?
What do the common error codes mean?
Here is the short version:
401— you are not signed in, or your API key or token is invalid.402— your organization is out of credits (payment required).403— you do not have permission, or you are calling the wrong organization.404— the thing you asked for does not exist, or it is not in your organization.429— too many requests, or a usage limit was hit.500— something went wrong on our side.
Why do I get a 401?
Why do I get a 401?
Your API key or token is missing or invalid. API keys start with
mx_live_ and go in the Authorization: Bearer header, alongside the X-Organization-ID header. Check the value is correct and not expired — see authentication.Why do I get a 403?
Why do I get a 403?
Either you do not have the right role for that action, or your key is scoped to a different organization than the one you are calling. Building or running with Composer, the Assistant, and schedules needs an owner or admin role; see roles & permissions. A
403 on a run, Composer, Assistant, or managed-knowledge request can also mean a plan limit was reached — see usage gating & limits.Why do I get a 402?
Why do I get a 402?
Your organization is out of credits, so the request was blocked with a “payment required” response. Top up your wallet, turn on overage, or upgrade your plan in plans & pricing. For what counts as managed usage, see credits & metering.
Why do I get a 429?
Why do I get a 429?
You have hit a rate limit, or a usage limit on a run. Wait for the number of seconds given in the
Retry-After header on the response, then retry. See rate limiting.A tool or node failed — how do I debug it?
A tool or node failed — how do I debug it?
Open the run in your run history and look at the failed node’s error message. The usual causes are a missing or expired credential, bad input passed into the node, or the external service returning its own error. To reconnect a credential, see credentials & integrations; for retry behavior in a workflow, see error handling & retries.
A note on 402, 403, and 429
These three codes mean different things depending on where they come from, so it helps to know which is which.On the run, Composer, Assistant, and managed-knowledge surfaces, a
402, 403, or 429 from a usage limit returns a flat response that tells you exactly which limit was hit — for example {code, layer, key, current, limit, reason}. Plain create/read/update/delete and settings requests instead return the simpler {detail} message shape. The full breakdown of these response shapes is in errors & status codes.Debug a failed request from code
When you call ModuleX from the API or an SDK, every request usesAuthorization: Bearer mx_live_… together with the X-Organization-ID header. If a request fails, read the HTTP status code and the response body — the SDKs raise typed errors you can catch so you can branch on the status and the included fields.
The SDK error classes differ slightly between languages — for example, the Python SDK has a dedicated billing error family that the JavaScript SDK folds into its base error. See errors & status codes for the exact mapping.
Related help
Account & access — help
Signing in, organizations, and the roles behind a
403.Billing, plans & credits — help
What it costs, what uses credits, and how to clear a
402.Credentials & integrations — help
Reconnect an expired credential behind a failed tool or node.
Known limitations — help
Behaviors to be aware of so you do not chase a non-bug.