Skip to main content
Webhooks notify your application when presentation generation completes or fails. They are useful when your application exposes an HTTPS callback and should avoid repeatedly polling every task.

​
Supported events

​
1. Prepare the receiver

Before subscribing, deploy an HTTPS endpoint that can:
  • Read the raw request and parse the callback payload.
  • Return a successful response quickly.
  • Place longer processing work on an internal queue.
  • Safely handle repeated delivery of the same logical event.
  • Record sanitized delivery metadata for troubleshooting.
Keep webhook handling separate from user-facing request threads. A slow downstream export, notification, or database operation should not delay the callback response.

​
2. Subscribe to an event

Create one subscription for each event your application needs:
Create a second subscription for presentation.generation.failed if failures should also reach the receiver. The subscription response includes its identifier:
Store id; it is required to remove that subscription later. Treat the configured secret as a credential and never commit it to source control.

​
3. Enable delivery during generation

Set trigger_webhook to true on a supported synchronous, asynchronous, or structured-JSON generation request:
Subscribing creates the destination; trigger_webhook requests delivery for that generation operation. Use both parts.

​
4. List subscriptions

Audit the current account configuration with GET /webhook/all:
Use this list to detect stale destinations, accidental duplicate subscriptions, or an environment pointing at the wrong callback URL.

​
5. Remove a subscription

Use DELETE /webhook/unsubscribe/all only when every subscription for the authenticated account should be removed.

​
Reliability checklist

  • Use a different callback URL or subscription inventory for development, staging, and production.
  • Generate a strong, unique secret for each environment and rotate it when access changes.
  • Make event processing idempotent so repeated callbacks do not create duplicate notifications or records.
  • Associate callbacks with previously stored task or presentation identifiers when those values are present.
  • Use polling as a recovery path when a callback is delayed or your receiver was temporarily unavailable.
  • Never place an API key in the webhook URL.
  • Remove subscriptions before permanently deleting an environment or callback endpoint.
Polling remains the source-of-truth recovery mechanism for an individual async task. A webhook should trigger application work, while a status request can confirm the task’s current state when needed.

Generate asynchronously

Submit a background job and monitor the same task through its status endpoint.