Developer Events
Developer events coordinate with your webhook endpoint at configuration time. They're not business events — they're the mechanism Cirrus uses to verify your endpoint can receive and validate deliveries before real events start flowing. You subscribe to them implicitly (by creating a subscription); they are not opt-in via the events array on POST /api/v1alpha1/webhook-subscriptions.
Every developer event follows the same Eventmodel envelope as business events. Only the data shape differs.
developer.webhook.test
Fires when a new subscription enters the validating state — typically immediately after POST /api/v1alpha1/webhook-subscriptions returns. Your endpoint must respond 2xx within the validation window for the subscription to transition to active; see Setup for the full flow.
The data payload identifies the subscription being validated:
Fields
| Field | Type | Description |
|---|---|---|
subscriptionId | string | The subscription being validated, prefixed sub_. Same value as the envelope's event.subscriptionId. |
endpointUrl | string | The URL the subscription was configured with — the URL Cirrus is POSTing to right now. Useful for logging and multi-endpoint routing. |
createdBy | object | The Cirrus Insight user who created the subscription. Same shape as the host object on the Meeting model. |
What your endpoint should do
- Verify the signature (see Security).
- Confirm
subscriptionIdmatches a subscription you're expecting to validate. - Respond
2xx— no processing required beyond confirming receipt. The test event carries no business data.
Failure or non-2xx responses within the validation window transition the subscription to disabled. See Lifecycle for the retry policy.
{
"subscriptionId": "sub_...",
"endpointUrl": "https://example.com/cirrus-webhook",
"createdBy": {
"userId": "usr_...",
"email": "admin@example.com",
"firstName": "Alex",
"lastName": "Rivera",
"displayName": "Alex Rivera"
}
}