Skip to main content

​
Success bodies are unwrapped

On /api/v0 a successful response is the object itself. There is no { data, code, message, status } wrapper around it.
Generate quote — 200
The Webhooks API is the exception — its service responses use the envelope below. See Errors and the response envelope.

​
The envelope

Errors raised at the edge — a rejected key, a tripped rate limit, an unreachable service — use this shape on every surface. A request with no API-KEY header at all is the clearest case: it is rejected by the platform security layer before partner error formatting applies, so that one response keeps the legacy envelope. Key off the HTTP status, not the body.
​
integer
The HTTP status code, repeated in the body.
​
string
A human-readable summary of the outcome.
​
enum
Either SUCCESS or ERROR.
​
object | null
The payload. null on error.
​
array
A list of {code, message, field} objects. Empty on success. Body-validation failures return one entry per offending field.
Check status, not just the HTTP code. A response is only successful when status is SUCCESS and errors is empty.

​
Where an error is raised

Every /api/v0 endpoint sits behind the same Endl edge, and an error can come from either the edge or the service behind it. Which one answered determines both the status and the body shape.
Authentication runs before routing. Without a valid key you will get 401 for every request, including one to a path that does not exist or with the wrong verb — a 404 or 405 only becomes visible once you are authenticated. If a URL you are sure is correct returns 401, check the credential before you check the path.

​
Status codes

​
A real 401

Verified against sandbox. A request with no API-KEY header:
401 Unauthorized
A request carrying a key the platform does not recognise answers the same way, with Invalid API key in place of Authentication Failed!. The two are deliberately hard to tell apart. A 401 carries no X-Request-ID header.
Note the mixed-case "Error" and the numeric-string errors[].code. Service errors use "ERROR" and a symbolic code such as VALIDATION_ERROR. Compare status case-insensitively, or better, ignore it and switch on the HTTP status.

​
Module error codes

The services behind the edge return stable ERR<MODULE>_<nnnn> codes, inside the same envelope as every other error. The top-level code is the HTTP status number; the module code is in errors[0].code.
Every code, what returns it and how to fix it is on Error codes.
Every error is the full envelope — there is no flat { code, message } body. Edge errors and service errors differ only in what sits in errors[0].code: the HTTP status as a string ("401") at the edge, a module code such as ERRWLT_1000 from a service.One rule handles both: branch on the HTTP status, then read errors[0].code.

​
Retrying safely

Never blindly retry a write that may have succeeded — Submit transaction in particular. Read the transaction back before resubmitting it.