Errors, pagination & retries
Handle rejected requests without losing context or repeating mutations.
Read the result, not just the status
JSON error responses use application/problem+json with the generated ErrorModel shape. Some raw protocol endpoints have different responses; inspect each operation. Not every possible error status is individually enumerated in the contract’s default error response.
- 2xx: success according to the operation; a 204 has no JSON body.
- 3xx: authentication operations redirect as part of the browser protocol.
- 401: no valid application session; start sign-in again.
- 403: request verification, role scope or fresh authentication was rejected.
- 409: the submitted state conflicts with the current revision or record.
- 422: validation or a learning command was rejected; inspect the returned problem.
- 503: a required capability cannot complete the operation.
Pagination and bounded views
Company people uses an after cursor. Pass the returned cursor unchanged and stop when no further cursor is supplied. See the response schema for the exact fields.
Report history returns the current actor’s last 50 requests. Activity returns the latest 100 administration events. Workspace snapshots may be bounded and include a limitation flag. Do not sum these views as complete company-wide metrics.
Retry intentionally
For read failures, use a bounded retry strategy and follow any applicable server retry guidance. For writes, first inspect whether the change was saved; do not blindly replay a request after a lost response.
Use the operation’s revision or request identifier where its schema and workflow require one. There is no documented universal Idempotency-Key contract or fixed rate-limit entitlement for this API. Never infer one from a single successful request.