Inbound Events API¶

Inspect and replay signature-verified HTTP-trigger arrivals. For capture, security, auto-persist, and retention behavior, see Webhook Ingestion.

Base URL and Authorization¶

https://api.centrali.io/data/workspace/{workspace}/api/v1

Send Authorization: Bearer YOUR_TOKEN. Listing requires workspace retrieve permission on function-triggers; replay requires execute. Event lookups and lists are workspace-scoped.

List Arrivals¶

GET /inbound-events

Parameter	Accepted value
`limit`	Default 50; clamped to 1–100
`offset`	Default 0; minimum 0
`triggerId`	Trigger UUID
`signatureResult`	`verified`, `rejected`, or `unsigned`
`dispatchStatus`	`received`, `queued`, `dropped_dispatch`, or `dispatched`
`since`, `until`	Date/time strings; use ISO 8601

The live HTTP-trigger capture path currently writes only verified arrivals. Accepted filter values do not imply rejected or unsigned traffic is buffered.

The response contains data rows and meta: { total, limit, offset }. Rows include id (ievt_ prefix), triggerId, sourceName, functionId, signatureResult, dispatchStatus, correlationId, replayedFrom, and receivedAt. The list omits payloads and headers. Invalid enum, trigger ID, or date filters return 400.

Replay an Arrival¶

POST /inbound-events/{id}/replay

No request body is required. Use the inbound event ID, not a function-run ID.

Example 202 response:

{
  "data": {
    "inboundEventId": "ievt_NEW_EVENT_ID",
    "correlationId": "NEW_CORRELATION_UUID",
    "replayedFrom": "ievt_ORIGINAL_EVENT_ID",
    "dispatchStatus": "queued"
  }
}

Replay creates a new buffered row before queueing the stored payload through the original trigger's current target function, code, parameters, and auto-persist configuration. It retains the original signature result without a new provider signature check. Queue submission success is not function execution success; a failed status-bookkeeping update may leave the response status at received even though queueing succeeded.

HTTP status	Meaning
`202`	Replay submitted to the compute queue
`404`	Event, trigger, or current function no longer exists
`500`	Database, payload decryption, or queue failure

Authentication and authorization are required for both endpoints. Replay is not an idempotent operation: repeating it creates fresh arrivals and can repeat record writes and side effects. No batch/window replay endpoint is established by these routes.

Retention and Record Persistence¶

Buffered payloads are encrypted and default to 30-day retention through the inbound retention job. Operators can configure INBOUND_EVENT_RETENTION_DAYS. Replay requires a retained event row and readable encryption key; there is no promise of unlimited replay history.

Optional HTTP-trigger triggerMetadata.autoPersist: { enabled: true, recordSlug: "events" } attempts a separate collection record write before dispatch. It requires signature validation with a signing secret. The saved configuration resolves the slug to collectionId; the target link is immutable. Preserve the block when updating metadata, because omission clears the setting.

The encrypted _payload envelope and declared plaintext projections have different access and exposure properties. Persistence failure is recorded on inbound metadata as persistStatus with an optional persistedRecordId, does not block function queueing, and is not automatically retried. See Optional Auto-Persist for field and replay details.