Request tracing & audit log
Pass your own request id to correlate logs, read how state-changing calls are audited, and why these server-to-server endpoints must never be called from a browser.
Request tracing
Every endpoint reads an X-Request-Id header from the request and logs it on every line it emits. If you do not send one, a UUID is generated for you.
Set your own controlled value so a request is traceable end to end, and quote it in support tickets so we can correlate our logs with your event:
X-Request-Id: panel:order:42:create:attempt-1A descriptive, structured value — panel, operation, entity id, and attempt — is far more useful in a ticket than an opaque UUID.
Audit log
Every state-changing call writes structured rows to an internal lifecycle log. Each row records:
| Field | Meaning |
|---|---|
op | The operation, e.g. suspend, terminate. |
step | The stage within the operation. |
status | ok, error, or skipped. |
| account / workspace / project ids | What the row pertains to. |
detail | Free-form context for the step. |
Read access to this log is service-role only — it is not host-callable. When you are investigating a tenant, ask support to surface that tenant's trail; quoting your X-Request-Id makes that lookup precise.
CORS
Endpoints respond to OPTIONS preflight and emit CORS headers. This does not make them browser-safe.
Server-to-server only
These calls are server-to-server. Your sk_live_ key carries full access to
your platform account and must never be exposed to a browser or client app.
The presence of CORS headers is an implementation detail, not an invitation to
call the API from front-end code. See Authentication.
Error reference
Every error the Platform API can return, consolidated. Conventional HTTP codes — 5xx are retryable, 4xx are terminal except 429 and the 409 state codes.
Versioning
Paths are unversioned today. A breaking change introduces /v2 alongside v1, which then receives only additive changes — so parse responses defensively.