---
"@context": https://schema.org
"@type": TechArticle
"@id": https://www.twilio.com/docs/data-destinations/destinations-overview#article
headline: Destinations overview
description: "Concepts shared across every data destination: eligibility models, delivery behavior, and testing, defined in one place."
url: https://www.twilio.com/docs/data-destinations/destinations-overview
inLanguage: en
dateModified: 2026-11-04T17:24:28.000Z
author:
  "@type": Organization
  name: Twilio Developer Education Team
publisher:
  "@type": Organization
  name: Twilio
---

# Destinations overview

> \[!IMPORTANT]
>
> Data Destinations is currently available as a Private Beta product and the information contained in this document is subject to change. Data Destinations is not a HIPAA Eligible Service or PCI compliant and should not be enabled in workflows that are subject to HIPAA or PCI. To learn more, see [Private beta legal information](/docs/data-destinations#private-beta-legal-information).

Twilio delivers event data from across the entire Twilio platform through a single, asynchronous, near-real-time data pipeline downstream to your destination.

Destinations are third-party business tools that can receive your Twilio event data. Destinations can be customer relationship management (CRM) tools, data warehouses, or raw data stores.

> \[!NOTE]
>
> All destinations are available in the United States (US1) region. [Amazon Kinesis](/docs/data-destinations/destination/amazon-kinesis), [Twilio Segment](/docs/data-destinations/destination/segment), and [Webhooks](/docs/data-destinations/destination/webhook) are also available in the Ireland (IE1) region.

## Join the Data Destinations private beta

[Sign up](https://airtable.com/appaJfyV6LiIFMxuP/pagIaOAtKsQVxTfdW/form)

Get early access to native destinations for data warehouses, observability tools, and event pipelines.

## Event eligibility

Most destinations can accept all event types. These destinations don't require that your events contain an end user identifier (like a phone number or email address). [Datadog](/docs/data-destinations/destination/datadog), [Slack](/docs/data-destinations/destination/slack), and the [warehouse destinations](/docs/data-destinations/destination-comparison) work this way, since they're built to receive operational or raw event data rather than user-attributed records.

However, some destinations require a resolvable end user identifier on every event. These destinations won't accept event types that don't have an identifier, such as TaskRouter or Studio events. These destinations' data models require every record to identify a user or device. [Amplitude](/docs/data-destinations/destination/amplitude), [Mixpanel](/docs/data-destinations/destination/mixpanel), and [Twilio Segment](/docs/data-destinations/destination/segment) work this way.

> \[!NOTE]
>
> See each destination's *Eligible events* section for a list of acceptable events. Each destination's documentation page states which model it uses and, for destinations that require each event to have an identifier, which event types the destination will accept.

## Create a destination

To create a destination in the Twilio Console or using the Destinations API, see [Set up a data destination](/docs/data-destinations/destination-setup).

Before setting up a destination, visit the specific destination's documentation to learn more about the specific configuration and authentication methods.

## Verification and test events

When you save a destination, Twilio validates your credentials and connectivity before making the destination active. However, the validation step doesn't check every permission a real delivery requires.

As a result, some configurations, like an Entra ID Azure Event Hubs connection or Mixpanel Service Account without Admin or Owner rights, can pass validation but won't receive events.

Learn more about the data that Twilio verifies about a destination in the *Verification and troubleshooting* section in each destination's documentation.

Every destination lets you trigger a test event so you can confirm delivery before subscribing to real events.

To check if your destination supports the *Trigger Test Event* utility, see the destination's documentation.

## Delivery errors

> \[!NOTE]
>
> If you created your destination in the United States (US1) region, Twilio sends notifications about delivery errors to your Debugger.

If Twilio can't deliver events to your destination, Twilio sends an initial error notification to the [Debugger](/docs/usage/troubleshooting/debugging-your-application).

If Twilio continues to encounter delivery errors after the initial notification, Twilio continues to notify you every 20 minutes after the initial error.

For destination-specific causes and fixes, see each destination's **Common errors** documentation.

## Available destinations

For a list of all availible destinations, see [Destination comparison](/docs/data-destinations/destination-comparison).