Skip to content
  • There are no suggestions because the search field is empty.

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.