Cable’s Alloy integration allows you to automatically ingest identity verification data from Alloy’s Identity Decisioning Platform. Once configured, Cable receives webhook events from Alloy as your customers move through KYC (Know Your Customer) and KYB (Know Your Business) workflows, giving Cable the verification data it needs to run assurance checks.

This guide walks you through the setup process, including which Alloy events to send, how to configure your webhook, and how to map identifiers between your systems.

This guide assumes you have an active Alloy account with at least one Journey configured. If you’re new to Alloy, refer to Alloy’s developer documentation to set up your Journeys and Workflows first.

How It Works

Alloy’s Journey Application model drives the integration. A Journey is a decision configuration that chains multiple Alloy Workflows (e.g., an “Onboarding” workflow for KYC checks followed by an “Underwriting” workflow for credit decisions). Each end-user progresses through the Journey as an Application, advancing step-by-step based on configured outcomes.

When an Application progresses, Alloy sends a webhook event to Cable. Cable stores the raw event payload and then periodically fetches the full evaluation, person entity, and business entity data from Alloy’s API. This data powers Cable’s assurance checks for identity verification, name matching, address verification, and more.

Prerequisites

Before you begin, make sure you have:

An Alloy account with at least one active Journey and Workflow
A Cable API key for your organisation (contact your Cable point of contact)
The Cable webhook URL for your organisation (provided during onboarding)
Access to the Alloy Dashboard at app.alloy.com to configure webhooks

Step 1: Set Up Your Alloy Webhook

Get Your Cable Webhook URL

Cable provides a unique webhook URL for each customer organisation. Your URL follows this pattern:

https://ingestion.cable.tech/api/v1/webhooks/alloy/{your_customer_uuid}

Your Cable point of contact will provide your customer_uuid during onboarding.

Keep your webhook URL confidential. It contains your unique customer identifier and should only be configured in your Alloy account settings.

Configure the Webhook in Alloy

Sign in to the Alloy Dashboard
Navigate to Settings > Webhooks
Click Add Webhook
Enter your Cable webhook URL
Select an authentication type (see below)
Select the events to subscribe to (see Step 2)
Save the webhook configuration

Configure Webhook Authentication

Cable requires webhook signature verification to ensure events are authentic. In Alloy’s webhook settings, configure HMAC authentication:

In the webhook configuration, select HMAC as the authentication type
Generate or enter a signing secret
Share this signing secret with your Cable point of contact so it can be stored securely on Cable’s side

Cable supports HMAC webhook signatures. If your Alloy account uses a different authentication method, contact your Cable point of contact to discuss alternatives.

Step 2: Choose Which Events to Send

Alloy can send various webhook events. Cable processes Journey Application events to track the progress and outcomes of your identity verification workflows.

Required Events

At minimum, you should subscribe to these Journey Application events:

Event	Description	When It Fires
`completed_application`	Application has reached a terminal state	An application is approved, denied, or completed with a final outcome

The completed_application event is the most important — it signals that Alloy has finished processing and all evaluation results are available for Cable to fetch.

Recommended Events

For complete visibility into application progress, we recommend also subscribing to:

Event	Description	When It Fires
`started_application`	A new application has been created	A new end-user begins the Journey
`completed_evaluation`	An individual workflow evaluation has finished	Each step/workflow within the Journey completes
`data_request_evaluation`	Alloy needs additional information	A workflow requires more data before it can continue (e.g., step-up verification)

Subscribing to all four events gives Cable the fullest picture of your verification pipeline. At minimum, always include completed_application.

Event Type Format

Alloy webhook event types follow the format update:journeyapplications:{environment}. Make sure to configure events for the correct environment:

Environment	Event Type Pattern
Production	`update:journeyapplications:production`

Ensure you’re subscribing to production environment events. Sandbox events are not ingested by Cable.

Step 3: Map Your Identifiers

A critical part of the integration is ensuring Cable can link Alloy’s verification data back to the correct person or company in your system. This section explains the identifiers involved and strategies for mapping them.

Alloy’s Identifier Model

Alloy uses several tokens to identify entities and events:

Token	Description	Persistence
`entity_token`	Alloy’s internal identifier for a person or business entity	Permanent — stays the same across all evaluations for that entity
`evaluation_token`	Identifier for a single evaluation (one run of a workflow)	Permanent — unique per evaluation
`application_token`	Identifier for a Journey Application (one end-user’s progression through a Journey)	Permanent — unique per application
`external_entity_id`	Your identifier for the entity, set when creating the entity in Alloy	Permanent — you control this value

Cable’s Identifier Model

When you send person or company data to Cable’s API, you provide your own identifier:

Cable Field	Description
`person_id`	Your unique identifier for an individual (used with `POST /v2/person`)
`company_id`	Your unique identifier for a business (used with `POST /v2/company`)

Cable stores these IDs exactly as you provide them — no transformation or normalization occurs.

Recommended Strategy: Use `external_entity_id`

The simplest and most reliable mapping strategy is to use the same identifier as both your external_entity_id in Alloy and your person_id or company_id in Cable.

Your System             Alloy                          Cable
===========             =====                          =====
internal_user_id  -->   external_entity_id       -->   person_id
"usr_abc123"            "usr_abc123"                   "usr_abc123"
internal_co_id    -->   external_entity_id       -->   company_id
"co_xyz789"             "co_xyz789"                    "co_xyz789"

When you create an entity in Alloy, include your identifier as the external_entity_id:

1 {
2     "name_first": "Jane",
3     "name_last": "Doe",
4     "email_address": "jane@example.com",
5     "identifiers": {
6         "external_entity_id": "usr_abc123"
7     }
8 }

When you send the same person to Cable:

1 {
2     "person_id": "usr_abc123",
3     "first_name": "Jane",
4     "last_name": "Doe",
5     "timestamp": "2025-06-15T10:30:00Z",
6     "is_test_user": false,
7     "is_retail_customer": true
8 }

Cable’s Alloy integration uses the external_entity_id from Alloy’s entity data to join verification results back to the correct person or company in your Cable dataset.

If you don’t set external_entity_id in Alloy, Cable will still ingest the data, but you will need to manually reconcile Alloy’s entity_token with your Cable person_id or company_id. This makes downstream analysis significantly harder.

Alternative Strategies

If using the same ID across all three systems isn’t feasible, here are other approaches:

Strategy 2: Maintain a Mapping Table

If your Alloy entities use a different identifier scheme than Cable, maintain a mapping table in your system:

Your Internal ID	Alloy `external_entity_id`	Cable `person_id`
12345	`alloy_usr_12345`	`cable_usr_12345`

You would set external_entity_id in Alloy to whatever value you choose, and separately track how it maps to your Cable person_id. Cable’s analytics team can then use this mapping to join Alloy verification data with Cable entity data.

Strategy 3: Retroactive Assignment in Alloy

If you’ve already created entities in Alloy without setting external_entity_id, Alloy supports retroactive assignment. You can update existing entities with the correct external_entity_id at any time, and Cable will pick up the updated value on the next sync.

Alloy also supports multiple external_entity_id values per entity if your system uses different identifiers in different contexts. See Alloy’s documentation on Multiple External Entity IDs for details.

Step 4: Test Your Integration

Before going live, verify the integration is working correctly.

Configure your production webhook pointing to your Cable webhook URL
Subscribe to production events (update:journeyapplications:production)
Create a test application in Alloy with a known external_entity_id
Verify receipt — confirm with your Cable point of contact that the webhook event was received
Check the data — after the next sync cycle, verify that the evaluation and entity data appears in your Cable dataset

Data Available in Cable

After the integration is running, Cable stores three types of Alloy data in your dedicated dataset:

Evaluation Data

Verification results from each Alloy workflow execution, including:

Outcome — Approved, Denied, or Manual Review
Matching scores — Field-level verification results for name, address, date of birth, SSN, and more
Service results — Detailed responses from identity verification services (e.g., LexisNexis, ComplyAdvantage, Middesk, Vouched)
Risk scores — Fraud scores, watchlist screening results, and risk indicators
Sanctions data — Sanctions screening results and watchlist matches

Person Entity Data

Individual KYC data, including:

Name, date of birth, contact information
Identity documents (SSN, passport, driver’s licence)
Address history
The external_entity_id you set during entity creation

Business Entity Data

Business KYB data, including:

Business name and alternate names
Tax identification (EIN) and registry IDs
Business address and contact information
The external_entity_id you set during entity creation

Cable’s analytics team will configure dbt models to transform this raw data for your organisation’s specific assurance checks. This setup is handled as part of onboarding — no action required from your side.

Common Questions

What happens if a webhook event fails to deliver?

Cable acknowledges webhook events immediately upon receipt. If Cable’s endpoint is temporarily unavailable, Alloy’s built-in retry logic will attempt redelivery. You can monitor delivery status in Alloy’s Webhook Logs (Settings > Webhooks > Logs).

Cable also runs a periodic sync job that fetches data directly from Alloy’s API, so even if a webhook is missed, the data will be picked up on the next sync cycle.

Can I send events from multiple Alloy Journeys?

Yes. Cable processes events from all Journeys configured to send webhooks to your Cable URL. Each Journey’s evaluations and entities are stored and tracked independently.

Do I need to send person/company data to both Alloy and Cable separately?

Yes. Alloy and Cable serve different purposes — Alloy runs your identity verification workflows, while Cable performs ongoing assurance checks against regulatory requirements. The integration allows Cable to use Alloy’s verification results as part of its assurance, but you still need to send your core entity data (persons, companies, transactions) to Cable via the Customer Data API.

What if I already have Alloy entities without `external_entity_id`?

You can retroactively assign external_entity_id values to existing Alloy entities. Cable will pick up the updated values on the next sync cycle. See Strategy 3 above.

How quickly does data appear in Cable after a webhook?

Webhook payloads are stored immediately upon receipt. The full evaluation and entity data from Alloy’s API is fetched by a periodic sync job (typically hourly). Your Cable point of contact can confirm the exact schedule for your organisation.