Each HTTP status from the Allocadia API means something specific. Here's what to check first for each.
400 Bad Request
The request body or parameters are invalid. Common causes:
- Malformed JSON.
- Missing required fields in a POST or PUT.
- A field value violates a validation rule (e.g. a date before a start date, a value outside a documented range).
- A FIELD_INTEGRITY_EXCEPTION — the error message usually names the specific field.
Fix: read the error message carefully; it typically points to the field. Correct the request and retry.
401 Unauthorized
The token is missing, bad, or expired.
Fix: reacquire a token via POST /token and retry. If reacquisition also fails, confirm the user credentials and that API access is still enabled on the user.
403 Access Denied
The authenticated user doesn't have permission on the resource.
Fix: verify the user has at least Viewer permission on the budget/hierarchy. If working with a dedicated integration user, ask your admin to grant it access to the resource.
404 Not Found
The resource doesn't exist, or the authenticated user can't see it.
Fix: confirm the ID in your URL is correct. If the user can't see the resource in the Allocadia UI, the API won't return it either.
405 Method Not Allowed
The HTTP verb isn't supported for that endpoint (e.g. PUT where only POST and GET are allowed).
Fix: check the public API docs for the correct verb.
429 Too Many Requests
You've hit the rate limit of 100 calls per minute per user.
Fix: back off (60s, then 120s, then 240s) and retry. For a redesign to stay under the limit, see Allocadia API requests returning HTTP 429 — too many requests.
500 Internal Server Error
Something broke on the Allocadia side.
Fix: contact Support with the exact request URL, method, body (redacted if sensitive), timestamp, and the response body. Don't retry blindly — if the server is in a bad state, retries make it worse.
Comments
Please sign in to leave a comment.