Alpharun Webhooks

Edited

Overview

Webhooks let Alpharun notify your systems when customer interaction data changes or a voice agent’s call task progresses. You can use them to sync information to your CRM, trigger workflows, or keep an external system up to date.

When an event occurs, Alpharun sends an HTTP POST request to a URL you configure, called an endpoint. You choose which event types that endpoint receives and can filter supported events by playbook or voice agent.

Set up an endpoint

  1. In Alpharun, go to Settings > Webhooks.

  2. Add an endpoint and enter the URL that should receive webhook requests.

  3. Select the event types you want to receive.

  4. Add any playbook or voice agent filters.

  5. Save the endpoint.

An endpoint with no event type filter receives all event types. Select specific types if your integration only handles certain events. You can create separate endpoints for different systems or workflows.

Filter events

There are two ways to control which events reach an endpoint:

Filter

What it controls

Event types

Which kinds of updates you receive, such as a recording being added or extracted data being saved

Channels

Which playbooks or voice agents you receive supported events for

Alpharun uses these channel names:

Channel

Format

Supported events

Playbook

playbook_<playbook_id>

Customer interaction events

Voice agent

voice_agent_<agent_id>

Customer interaction events for that agent, plus call task events

Replace the placeholder with the relevant Alpharun ID.

Channel filters work as follows:

  • No channels selected: receive all events that match your event type selection.

  • One channel selected: receive matching event types associated with that channel.

  • Multiple channels selected: receive matching event types associated with any selected channel.

Event type and channel filters apply together. For example, selecting customer_interaction.summary.updated and one playbook channel limits delivery to summary updates for that playbook.

Selecting both a playbook and a voice agent channel does not require an event to match both. Channels use “any match” logic.

Call task events carry a voice agent channel, so a playbook-only filter will not receive them.

Customer interaction events

A customer interaction can contain one or more recordings. Its recordings, extracted fields, and assessment results can become available at different times.

customer_interaction.recording_added

Fires when a completed recording becomes part of a customer interaction.

The payload identifies both the customer interaction and the recording that was added. Use this event to fetch the interaction’s recordings or transcripts.

This event does not mean scoring, data extraction, or summary generation has finished. It also does not guarantee an audio file exists: transcript-only recordings can be part of an interaction.

customer_interaction.updated

Fires after data extraction saves the interaction’s configured extraction fields.

This is not a notification for every change to an interaction, and it does not fire specifically when scoring finishes. Keep these behaviors in mind:

  • Scoring and data extraction run independently. Receiving this event does not guarantee scores are ready.

  • An interaction can be scored without this event firing if its playbook has no data-extraction fields configured.

  • The event can fire more than once, including when high-priority fields are extracted before the full extraction finishes.

  • The payload does not list the fields that changed or distinguish between extraction stages. Fetch the interaction to read its current values.

customer_interaction.summary.updated

Fires when an assessment saves a different interaction summary template, including when the first summary is created or a later recording changes it.

This event occurs late in the assessment flow, after the updated assessment and summary have been saved. It is useful for integrations that want to fetch an updated summary.

It is not a universal “processing complete” event. Separate extraction jobs may still be running, and an assessment that leaves the summary unchanged does not trigger this event. Interactions without a configured summary template may not produce a summary event.

Is there an event that means everything is ready?

No. Alpharun does not currently provide a dedicated event guaranteeing that recordings, scores, extracted fields, and the summary are all ready.

The three customer interaction events are not a guaranteed sequence. You should not assume that receiving one means the others have already arrived or will arrive afterward.

Subscribe to the events relevant to your integration and fetch the current interaction data when they arrive. If your workflow requires several kinds of data before proceeding, check those requirements explicitly and fetch again later when needed.

Read customer interaction data

Customer interaction webhooks contain a lightweight reference rather than the full interaction:

{

  "event_type": "customer_interaction.updated",

  "data": {

    "customer_interaction": {

      "id": "<interaction_id>",

      "playbook_id": "<playbook_id>",

      "public_api_url": "https://api.alpharun.com/api/v1/customer-interactions/<interaction_id>"

    }

  }

}

The customer_interaction.recording_added event also includes data.recording.id.

Use the public_api_url with your Alpharun API key to fetch the interaction’s current details. To include assessment analysis and the configured outcome, add ?include_analysis=true.

Recordings and transcripts are available through:

  • GET /api/v1/customer-interactions/<interaction_id>/recordings

  • GET /api/v1/customer-interactions/<interaction_id>/transcripts

These requests return the data available when you make the request. A webhook does not preserve a full snapshot of the interaction at the moment it was triggered.

For API authentication and usage, see the Alpharun developer portal.

Call task events

Call task events describe the progress of work assigned to a voice agent. They are separate from customer interaction events, which describe the resulting recordings and analysis.

Event type

What triggers it

What the payload contains

call_task.attempted

A calling attempt is settled and its retry or ending decision has been recorded. This includes attempts that could not dial.

The call task and the specific attempt, including its result and any error

call_task.updated

A text is sent, a text is received, or an opt-out is recorded on an agent-managed task

The task’s identity and status, plus the new timeline event

call_task.completed

An agent-managed task reaches a completed ending, which can happen after a call, a text exchange, or a decision to stop

The call task, including its attempts and public event history

For call_task.attempted, inspect the task’s status to determine whether more work is scheduled or the task has ended. An attempt ending does not necessarily mean the whole task is complete.

call_task.updated does not announce every internal task change. Calls use customer interaction events; the agent’s internal decisions and waits do not generate this event. Incoming texts can still generate updates on a closed task without reopening it.

call_task.completed applies to completed agent-managed tasks. It does not announce failed or canceled tasks, or the completion of standard dialer tasks. It also does not guarantee that the task’s interaction analysis has finished.

Inspect and replay events

Open an endpoint in Settings > Webhooks to review its message history. Filter by event type and date to find a delivery, then inspect its payload, delivery attempts, and response. These history filters only change what you see; they do not change the endpoint’s subscriptions. Learn more about filtering message history.

Replay one event

  1. Find and open the message.

  2. Open the options menu beside a delivery attempt.

  3. Select Resend.

This sends the same message to your endpoint again.

Recover failed deliveries

  1. Open the endpoint’s details.

  2. Select Options > Recover Failed Messages.

  3. Choose the time window to recover.

You can also open a message’s options menu and use Replay… to recover failed messages since that message’s time.

Replay Missing is used for stored messages that were never attempted for an endpoint, such as when an endpoint’s subscriptions have changed.

Replaying sends an existing notification again. It does not rerun scoring, data extraction, or summary generation. If your handler fetches the interaction after a replay, it receives the interaction’s current data.

Handle deliveries reliably

Return a 2xx response promptly after safely accepting a webhook. Failed requests are retried automatically; redirects and other non-2xx responses count as failures. See delivery and retry behavior.

Your integration should safely handle repeated deliveries and events arriving in a different order than expected. Avoid creating duplicate CRM records or repeating other actions when the same notification is received again.

Alpharun’s webhook delivery uses Svix. Verify each request using your endpoint’s signing secret, the original request body, and the signature headers before processing it. The signing secret is separate from your Alpharun API key. See signature verification instructions.

If an expected event is missing, check the endpoint’s event type and channel filters, then confirm that the event’s trigger actually occurred. For example, completed scoring alone does not trigger customer_interaction.updated, and an unchanged summary does not trigger customer_interaction.summary.updated.