Webhooks in CoRecruit
CoRecruit webhooks provide real-time delivery of completed meeting data to external systems.
A webhook is emitted when a meeting has completed processing and all associated assets have been finalized. Each delivery contains a complete, structured representation of the event, suitable for immediate ingestion into downstream systems.
Supported Events
Currently, CoRecruit only supports the `Meeting Completed` event. We will be adding more webhook events to the product soon.
Meeting Completed
Generated when a meeting has ended and all post-processing has completed, including meeting metadata, recordings, transcripts, notes, and follow-up materials.
A single logical meeting.completed event is generated per meeting lifecycle. The event payload represents the terminal state of the meeting’s data.
Delivery Semantics & Retries
- Method: POST
- Content-Type: application/json
- Delivery timing: Near real-time after processing completion
CoRecruit uses an at-least-once delivery model.
For each logical event, CoRecruit attempts delivery up to five times if the destination endpoint does not return a successful 200-level response.
Retry behaviour:
- Initial retry delay: 2 seconds
- Subsequent retries use exponential backoff
- The delay is doubled on each attempt
- Delivery stops after 5 total attempts if unsuccessful
All retry attempts for the same event contain the same event ID and identical payload.
Downstream systems must:
- Expect duplicate deliveries
- Implement idempotent processing using the event id
- Treat retries as transport-level retries, not new events
Idempotency
Each webhook event includes a globally unique ID. The ID uniquely identifies the logical event, not the delivery attempt.
Downstream systems must use this id as the idempotency key, safely ignore duplicate deliveries and treat retries as delivery artefacts, not new events.
Payload Structure
Each webhook payload is self-contained and includes:
- Event metadata
A globally unique event identifier, event type, and generation timestamp. - Meeting context
Identifiers, timing, participants, ownership, privacy state, and optional ATS linkage. - Organization context
Account- and team-level identifiers for multi-tenant ingestion. - Assets
Canonical URLs for all generated deliverables, including transcripts, recordings, structured notes, and follow-up materials.
Sample Payload
The following example illustrates the full payload delivered for a meeting.completed event
{ "id": "evt_789456123", "eventType": "meeting.completed", "createdAt": 1765198584697, "data": { "meeting": { "id": "mtg_01H2J3K4L", "name": "Project Sync: Q4 Roadmap", "startTime": "2025-10-10T10:23:27.000Z", "ownerName": "Alex Rivers", "participants": ["+12345678900"], "atsRecordName": "First Last", "isPrivate": false }, "organization": { "accountId": "acc_554433", "teamId": "team_998877" }, "assets": { "transcriptionUrl": "https://api.provider.com/v1/transcripts/abc123.txt", "recordingUrl": "https://api.provider.com/v1/recordings/abc123.mp4", "actionItemsUrl": "https://api.provider.com/v1/actions/abc123.json", "databaseNotes": [ { "name": "Summary",
"note": "Discussed budget and timeline for the upcoming launch." } ], "followUpMaterials": [ { "name": "Meeting Recap", "txtUrl": "https://api.provider.com/docs/recap.txt", "pdfUrl": "https://api.provider.com/docs/recap.pdf" } ] } }}
Asset Guarantees
The meeting.completed event is emitted only after all assets are finalized.
This guarantees:
- URLs are permanent and immediately accessible
- Structured notes and summaries reflect final AI output
- No subsequent webhook is required to retrieve additional deliverables for the meeting
Downstream systems can treat this event as the authoritative completion signal.
Schema Stability and Forward Compatibility
Webhook payloads may include optional fields and may expand over time.
Receiving systems are expected to ignore unknown fields, avoid strict schema rejection on additive changes.
Webhooks Settings Page
To create and manage webhooks on CoRecruit, click the gear icon for the settings page, and navigate to “Webhooks” on the left menu panel. This opens the Webhooks page.

This page lists all webhook subscriptions configured for the current team. Each row represents a single webhook subscription and shows:
- Name
An internal label used to identify the webhook. This does not affect delivery or payloads. - Webhook Type
The event the webhook is subscribed to. Currently, we only support meeting.completed events. - Webhook URL
The destination endpoint where webhook payloads are delivered. - Status
Indicates whether the webhook is actively receiving events.- Active: Events are delivered according to the retry policy.
- Deactivated: No events are delivered.
From this page, you can:
- Create a new webhook
- Activate or deactivate an existing webhook
- Open a webhook to view its configuration and delivery logs
Deactivating a webhook stops delivery immediately but preserves its configuration and historical logs.
Create Webhook
This screen is used to register a new webhook subscription.
Fields
- Name
A descriptive label to help you identify the webhook internally. - URL
The HTTPS endpoint that will receive webhook POST requests. The endpoint must be publicly accessible and capable of handling JSON payloads. - Event Types
Select the events this webhook should receive.
Currently, we only support the meeting.completed event.
Once created, the webhook appears in the Webhooks list and follows the selected activation state.
Webhook Detail Page
Each webhook has a dedicated detail view that combines configuration visibility and delivery diagnostics.
Configuration
At the top of the page, you can review:
- Webhook name
- Destination URL
- Subscribed event types
- Current activation status
This view is read-only and reflects the active configuration.
Webhook Logs
The logs table shows delivery attempts for this webhook. Each row represents a single delivery attempt, not a unique event. For each attempt, you can see:
- Event Type
The logical event being delivered. - Timestamp
When the delivery attempt occurred. - Status
- Success: The endpoint returned a 200-level response.
- Retrying / Failed: The endpoint did not acknowledge successfully and will be retried.
- Actions
Inspect the request payload and response details for debugging.
Because CoRecruit uses an at-least-once delivery model, the same event may appear multiple times if retries occur. All retries share the same event ID and payload.