Chorus Ai Webhooks

generated: '2026-08-13'
method: derived
source: openapi/_original/chorus-ai-openapi.json (/v3/webhook operations)
asyncapi_published: false
summary: >-
  Chorus ships a real, self-service webhook surface: a customer can register, list and delete
  HTTP callbacks through the API itself. No AsyncAPI document is published — the event surface is
  described only as three REST management operations inside the OpenAPI — so this artifact
  captures the webhook catalog rather than a spec. No AsyncAPI is fabricated.
management_api:
  register:
    operationId: post-v3-webhook
    method: POST
    path: /v3/webhook
    description: Register a new webhook that Chorus will post to when a specified event occurs.
    request_body:
      required: true
      media_type: application/json
      fields:
      - name: event
        type: string
        required: true
        enum:
        - recording_done
        description: The event type that triggers the webhook.
      - name: hook_url
        type: string
        required: true
        description: The URL to post to when the event occurs.
      - name: type
        type: string
        required: false
        nullable: true
        description: >-
          Optional webhook type with predefined filters (e.g. 'zapier' for common Zapier use
          cases).
  list:
    operationId: get-v3-webhook
    method: GET
    path: /v3/webhook
    description: Retrieve all webhooks configured for the authenticated customer.
  delete:
    operationId: delete-v3-webhook
    method: DELETE
    path: /v3/webhook
    description: Delete an existing webhook by its URL.
    note: >-
      Deletion is keyed on the callback URL rather than a webhook id — there is no
      /v3/webhook/{id} path in the contract.
events:
- name: recording_done
  description: >-
    Fired when Chorus has finished processing a recording and its transcript/AI output is
    available. This is the only event value the contract enumerates.
  payload_schema:
    published: false
    note: >-
      The contract defines the registration request but never describes the callback payload
      Chorus POSTs to hook_url. A consumer cannot know the delivered shape from the published
      contract — this is the single largest gap in the event surface.
filtering:
  supported: true
  note: >-
    The registration description states webhooks "can be filtered based on conversation
    criteria", but the request body exposes no filter field beyond the opaque `type` shortcut,
    and the criteria grammar is not documented.
delivery_semantics:
  transport: HTTPS POST
  retries: not documented
  backoff: not documented
  ordering: not documented
  at_least_once: not documented
  signing:
    published: false
    note: >-
      No signature header, shared secret, or verification procedure is documented. A receiver
      has no published way to authenticate that a callback genuinely came from Chorus.
  replay_protection: not documented
integrations:
  zapier:
    note: >-
      The `type` field names 'zapier' as a preset with predefined filters, indicating a
      first-class Zapier path built on this same webhook surface.
gaps:
- No AsyncAPI (or any event-schema) document is published.
- The callback payload for recording_done is entirely undocumented.
- No webhook signing or verification mechanism is documented.
- No retry/backoff/delivery guarantees are stated.
- Only one event type exists, so there is no coverage of conversation deletion, user changes,
  scorecard completion or CRM writeback outcomes.
cross_links:
  openapi: openapi/chorus-ai-openapi.yml
  conventions: conventions/chorus-ai-conventions.yml