Skip to main content
An accepted Data API command can create an operation that completes later. Keep its operation identifier, follow the operation’s status, and retrieve results through the documented result endpoint. An accepted response is not a successful final result.

​
Track the operation

Use the returned operation identifier and location to inspect progress. Keep failed, cancelled, and successful outcomes distinct. A cancellation request records an intention to cancel; inspect the resulting state rather than assuming work stopped immediately. Use bounded status checks with backoff, or register webhooks for the events your integration needs. A webhook subscription can cover query, schedule, transfer, operation, and run events, including successful and failed runs.

​
Verify webhook signatures

Webhook requests include X-ChatObserver-Signature, X-ChatObserver-Timestamp, X-ChatObserver-Event-Id, and X-ChatObserver-Delivery headers. Store the endpoint’s signing secret securely when it is issued. Compute HMAC-SHA256 over the timestamp, a period, and the exact raw request body:
Encode the digest as lowercase hexadecimal and compare it with the value after v1= in the signature header using a constant-time comparison. Do not parse and reserialise JSON before verifying it. Enforce a reasonable timestamp tolerance to reject stale requests.

​
Handle retries and repeated events

Deduplicate by event identifier and acknowledge a valid event after durably recording it. A delivery identifier identifies a delivery record and can recur when that delivery is retried. Use the event identifier to prevent duplicate business actions. Use delivery history to investigate failures. Update your receiver when rotating the signing secret, and use the documented replay action when a failed event needs another delivery. Read safe writes and error handling before automating recovery.