Event Replay

Webhooks push runtime events to your backend. Event replay is the pull counterpart: every event the platform emits is also kept in a per-app log with a monotonic cursor, so if your webhook endpoint was down, or you just want to re-process history, your backend can pull the events it missed.

How it works

1. Your backend calls GET /v1/events with a cursor (start at 0).
2. The response carries a batch of events and a nextCursor.
3. You process the batch, persist nextCursor, and pass it on the next call. Events are never skipped or duplicated across a resumed cursor.

Request

Authenticated with the same HMAC scheme as token exchange (the body hash is the SHA-256 of an empty string for this GET).

GET /v1/events?cursor=0&limit=100
  X-DropOnAir-Key:       <appId>
  X-DropOnAir-Timestamp: <unix seconds>
  X-DropOnAir-Nonce:     <random, 16-128 chars>
  X-DropOnAir-Signature: <HMAC-SHA256>

// optional query params
// types=message.delivered,call.ended   filter to specific event types
// from / to                            ISO-8601 or epoch-millis time range
// limit                                1-500, default 100

Response

{
  "events": [
    { "sequence": 41, "type": "message.delivered",
      "timestamp": 1747000000000, "data": { ... } }
  ],
  "nextCursor": 41,
  "hasMore": true
}

The event log is a replay buffer, not a permanent archive, entries are retained for 30 days. Poll on whatever cadence suits your app. Verify support via GET /api/info, the features array includes "event_replay".