Skip to main content
Most errors fall into a handful of codes, and each one has a clear fix. This page explains what the common codes mean in plain terms and what to do about them. For the full technical reference, follow the link in each answer.

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

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.
For the precise meaning and response body of each code, see errors & status codes.
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.
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.
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.
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.
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 uses Authorization: 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.

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.