API Reference

This reference documents only real, publicly usable JSON endpoints -- method, path, authentication type, required parameters, an example request and response, and the documented error codes for each endpoint. Zentor has no general developer API-key system; depending on the route, access is either unauthenticated or protected by a Widget embed token with origin validation. Internal dashboard routes and Master Admin endpoints are deliberately excluded from this public reference, since they are only reachable through a regular signed-in session.

Every endpoint entry carries a live-test note that discloses whether the information comes from the registry schema, an automated test, or an actual live observation -- mere similarity to a working code path is not treated as full proof. A technically successful call also only ever confirms that the specific request was processed, not that downstream steps such as email delivery, payment completion, or a finished SSO login have taken place.

Authentication depends on the endpoint group. Public legal, marketing and form routes can be called without a dashboard session. Widget routes use the `X-Widget-Token` header and an origin allowlist, so a copied widget integration cannot automatically be used from an unapproved domain. Dashboard authentication relies on a session JWT with a 12-hour lifetime and a refresh token valid for seven days. SSO callbacks and exchange routes follow their own one-time-code flow.

Each endpoint page should be read as a contract for that specific route. Check the HTTP method, path parameters, query parameters, request body, required fields, example response, idempotency statement and documented error codes. A successful example does not mean that every request with the same structure will succeed; validation, configuration state, origin checks and entitlement rules can still reject the operation.

The platform-wide API rate limit is 2,000 requests per 15 minutes. A separate per-endpoint rate limit is not consistently documented. Clients should therefore implement reasonable retry behavior and avoid tight polling loops. For operations marked non-idempotent, automatic retries can create duplicate effects and should be used only after the client has determined that the first request did not complete.