An API and five events.

What the API exposes

A scoped REST API over the service half of the graph. Tokens are narrow and ideally issued one per integration, so a compromised token for an internal dashboard cannot reach anything else.

• Cases — type, status, owner, waiting-on, timeline and resolution
• Customers — identity, entitlement, open cases and health state
• Conversations — references and metadata, not raw message bodies
• Knowledge — published articles, their status and version
• Promises — what was committed, to whom, by when

What it never exposes

Cases marked sensitive are not reachable through the API under any scope. There is no token that returns them, which means an integration cannot leak them and a compromised token cannot reach them.

Events

Five webhooks covering the moments worth reacting to. Deliveries are signed; verify the signature before acting, and treat delivery as at-least-once rather than exactly-once.

• case.created — a new case, with its customer and type
• case.resolved — with the recorded resolution
• incident.declared — so your own systems can react
• promise.due — a commitment falling due
• customer.health_changed — a state transition, with its reasons

Writes are deliberately narrow

You can create a case, add a message to one, and attach product context. You cannot approve anything, send a customer-facing reply, or change a case's resolution. An automated integration replying to a customer unattended is exactly what this product exists to prevent.

The most useful integration is the smallest

When your product detects a failure for a specific customer, raise a case with the product state attached. The agent then opens a case that already contains what went wrong, instead of asking the customer to describe it.

Rate limits and pagination

Cursor pagination throughout, and limits set per token rather than per organization so one noisy integration cannot starve another. The limits are published in the API reference rather than discovered by hitting them.

Testing

Every organization can create a sandbox with generated customers, cases and knowledge. Point your integration at that first — particularly anything consuming the promise or health events, where a bug produces noise aimed at real people.