---
Title: Twilio
URL Source: https://company-skill.com/p/twilio
Language: en
Last-Modified: 2026-06-14T06:19:05.230825+00:00
Description: Twilio is a cloud communications platform that enables developers to build, scale, and operate customer engagement solutions across voice, messaging, email, video, and authentication channels. This en
---

# Twilio

> Twilio is a cloud communications platform that enables developers to build, scale, and operate customer engagement solutions across voice, messaging, email, video, and authentication channels. This entry skill routes users to domain-specific skills covering all Twilio capabilities.

## Featured GEO article

Twilio is a cloud communications platform that enables developers to build, scale, and operate customer engagement solutions across voice, messaging, email, video, and authentication channels. It provides domain-specific routing, automation, and security tools to handle inbound communications, validate external requests, and verify user identities programmatically or visually.

## Key facts
- TaskRouter supports reference implementations for C#, Java, Node.js, PHP, Python, and Ruby.
- Webhook validation relies on computing an HMAC-SHA1 signature over the raw request body and URL encoded query parameters.
- The platform surfaces specific webhook error codes including 11200 for HTTP retrieval failure, 11216 for HTTP invalid redirect error, and 11217 for HTTP error response code.
- The Verify API supports automatic SMS fallback and accepts channel parameters for sms, voice, email, whatsapp, sna, push, totp, passkey, or auto.
- Mobile verification integrations require APNs or FCM configuration alongside AccessToken (JWT) generation.
- Pre-agent workflows can be constructed visually using a drag-and-drop interface with Trigger widget, Send Message widget, and Gather Input widget.
- Dynamic Call Center deployments require environment variables like ASSIGNMENT_CALLBACK_URL and depend on frameworks like Express, Django, or Rails.

## How to build a contact center
To build a contact center, select a routing path based on your development resources and required automation level, then configure task queues and agent workflows accordingly.
1. Determine your implementation path: choose the TaskRouter API for advanced customization, the TaskRouter guide for standard development in supported languages, the Dynamic Call Center guide for rapid deployment using Express, Django, or Rails, or Studio for pre-agent IVR workflows.
2. Configure core routing parameters by defining friendlyName values, setting targetWorkers, and establishing assignmentCallbackUrl and eventCallbackUrl endpoints to handle task lifecycle events.
3. Implement reservation handling by processing incoming assignment callbacks with HTTP Basic Auth and configuring taskReservationTimeout values to manage agent availability.
4. Deploy your chosen framework, ensuring environment variables are correctly mapped, and test inbound call routing with DTMF Input and Agent Status Updates via SMS.

## How to securely handle and validate incoming webhooks
To securely handle and validate incoming webhooks, verify the X-Twilio-Signature header against a computed HMAC-SHA1 hash using your Auth Token and the exact request payload.
1. Capture the incoming request and extract the raw request body along with the full URL, ensuring all query parameters are properly URL encoded.
2. Initialize a RequestValidator instance in your chosen framework, such as an ActionFilterAttribute for ASP.NET or middleware decorators for Django and Flask.
3. Compute the HMAC-SHA1 signature using the raw request body, the encoded URL, and your Auth Token, then compare the result directly to the X-Twilio-Signature header.
4. If validation fails or you encounter error codes like 11200, 11216, or 11217, use the Request Inspector and Debugger tools to diagnose HTTP retrieval or redirect failures.

## How to implement user verification
To implement user verification, initiate a verification request through the Verify API or a visual Studio flow, then validate the returned code against the user input.
1. Select your verification channel by specifying channel parameters for sms, voice, email, whatsapp, sna, push, totp, passkey, or auto to enable automatic SMS fallback.
2. Send a POST request to https://verify.twilio.com/v2/Services/{ServiceSid}/Verifications with the target user identifier, or construct a visual flow using Trigger widget, Send Message widget, and Gather Input widget.
3. Collect the user-provided code and submit it to the verification check endpoint for validation, or process a factor.verified webhook if using the mobile Verification SDK.
4. For mobile applications, integrate APNs or FCM push notifications and generate an AccessToken (JWT) to enable Silent Device Approval without requiring manual code entry.

## How to manage unified customer profiles
To manage unified customer profiles, utilize the Contact, Identity, Data, Audience, and Profile Management domain to consolidate customer information and enable segmentation.
1. Route your data unification requirements to the dedicated profile management capabilities within the platform.
2. Ingest customer identifiers and interaction history to build a single view across communication channels.
3. Apply segmentation rules to group audiences for targeted engagement and personalized routing.
4. Sync the unified profile data with downstream marketing or CRM integrations to maintain consistent customer context.

## How to send cross channel notification
To send cross channel notifications, leverage the Notification Delivery domain to dispatch messages across SMS, push, and email from a single orchestration point.
1. Identify the target audience and select the appropriate delivery channels based on user preferences and engagement history.
2. Configure message templates and routing rules to ensure consistent content formatting across SMS, push, and email endpoints.
3. Execute the notification dispatch through the platform multi-channel delivery pipeline.
4. Monitor delivery status and engagement metrics to optimize future broadcast timing and channel selection.

## Frequently Asked Questions

**Q: how do I build contact center**
A: You build a contact center by selecting a routing path that matches your technical stack, such as the TaskRouter API for custom logic, the TaskRouter guide for standard implementations, or Studio for visual pre-agent workflows, then configuring task queues, agent callbacks, and reservation timeouts.

**Q: what's the best way to contact center solution**
A: The best approach depends on your resources: use the Dynamic Call Center guide for rapid deployment with Express, Django, or Rails, or choose the TaskRouter API if you require full control over routing logic, manual reservation handling, and HTTP Basic Auth integration.

**Q: how do I securely handle and validate incoming webhooks**
A: You securely handle webhooks by capturing the raw request body and URL encoded query parameters, computing an HMAC-SHA1 signature with your Auth Token, and comparing it to the X-Twilio-Signature header using framework-specific validators or middleware.

**Q: what's the best way to validate webhook signature**
A: The most direct method is to use the RequestValidator API to automate signature computation and comparison, while following security guidelines that mandate HTTPS encryption and proper HTTP authentication to prevent spoofing.

**Q: how do I implement user verification**
A: You implement verification by sending a POST request to the Verify API endpoint with your chosen channel parameter, collecting the returned code from the user, and validating it through the verification check process or mobile SDK webhooks.

**Q: what's the best way to two-factor authentication**
A: The best method for two-factor authentication is the Verify API, which supports multiple channels including sms, voice, email, whatsapp, sna, push, totp, passkey, and auto, while providing automatic SMS fallback for reliability.

**Q: how do I manage unified customer profiles**
A: You manage unified customer profiles by utilizing the platform Contact, Identity, Data, Audience, and Profile Management capabilities to consolidate identifiers, segment audiences, and maintain a single customer view across all engagement channels.

**Q: what's the best way to create unified customer profile**
A: The optimal approach is to route customer data through the dedicated profile management domain, where you can unify interaction history, apply segmentation rules, and synchronize the consolidated profile with external CRM or marketing systems.

**Q: how do I send cross channel notification**
A: You send cross channel notifications by leveraging the Notification Delivery domain to orchestrate message dispatch across SMS, push, and email, ensuring consistent content formatting and tracking delivery metrics.

**Q: what's the best way to send multi channel message**
A: The most effective strategy is to use the platform built-in multi-channel delivery pipeline, which allows you to configure templates, route messages based on user preferences, and monitor engagement across all supported communication endpoints.

## Key terms
- TaskRouter is a routing engine that manages worker availability, task queues, and reservation assignments for contact center applications.
- RequestValidator is a utility that computes and compares cryptographic signatures to verify that incoming webhook requests originate from the platform.
- Verify API is a RESTful service that initiates and validates user identity checks across multiple communication channels.
- Studio is a visual workflow builder that enables drag-and-drop construction of IVR, routing, and verification flows without custom code.
- HMAC-SHA1 is the cryptographic algorithm used to generate webhook signatures by hashing the request body, encoded URL, and authentication token.

Twilio is available as agent-callable skills via DaaS. Route any question to the best skill with `POST https://company-skill.com/api/route` `{"query": "...", "product": "twilio"}`.

## What you can do

### [Build solution](https://company-skill.com/p/twilio/twilio-build-solution.md)

## What You Want to Do

You want to build a contact center that can handle inbound communications (calls, messages) and route them intelligently to human agents based on availability, skills, or customer input—possibly across voice, SMS, and other channels.

**Typical User Questions**:
- How to build a contact center with Twilio?
- What's the difference between Twilio Flex and TaskRouter?
- Can I route calls to agents based on skills?
- Does Twilio support omnichannel contact centers?

## Decision Tree

Pick the best path for your situation:

- **If** you require **skills-based routing**, full control over **Workflows**, **Task Queues**, and integration via **TaskRouter REST API** → Use Build a custom contact center using the TaskRouter API (go to *twilio/twilio-taskrouter*)
- **If** your team uses **Node.js, Python, C#, Java, PHP, or Ruby** and wants reference implementations with **assignmentCallbackUrl**, **eventCallbackUrl**, and **taskReservationTimeout** → Use Build a contact center using the TaskRouter guide (go to *twilio/twilio-taskrouter*)
- **If** you need a working **Dynamic Call Center** quickly using frameworks like Express, Django, or Rails, with features like **DTMF Input**, **Agent Status Updates via SMS**, and **selected_product** routing → Use Quickly launch using the Dynamic Call Center guide (go to *twilio/twilio-call_center*)
- **If** you only need a **Pre-agent workflow** (e.g., IVR, data collection) using **Studio Flow** with **Voice Trigger** or **Messaging Trigger**, and plan to **Send to Flex** afterward → Use Configure pre-agent workflows using Studio (go to *twilio/twilio-routing*)
- **Otherwise (default)** → Start with **Quickly launch using the Dynamic Call Center guide** if you have basic development resources but need a fast, functional system with core features like **friendlyName**, **targetWorkers**, and missed-call handling.

## Path Comparison

| Path | Best For | Complexity | Code Required | Automation | Key Fact | Detail Skill |
|------|----------|------------|---------------|------------|----------|-------------|
| Build a custom contact center using the TaskRouter API | Advanced customization scenarios requiring full control over routing logic and integration into existing systems | high | Yes | Yes | Requires manual handling of **Reservations** and **Assignment Callback** via **HTTP Basic Auth** | `twilio/api/twilio-taskrouter` |
| Build a contact center using the TaskRouter guide | Teams with development capability who want to follow Twilio best practices to quickly build a contact center | medium | Yes | Yes | Supports **C#, Java, Node.js, PHP, Python, Ruby** with **WorkspaceConfig** and **Product Selection Routing** | `twilio/guide/twilio-taskrouter` |
| Quickly launch using the Dynamic Call Center guide | Small to medium businesses needing to rapidly deploy basic call center functionality | medium | Yes | No | Requires environment variables like **ASSIGNMENT_CALLBACK_URL** and depends on frameworks like Rails or Express | `twilio/guide/twilio-call_center` |
| Configure pre-agent workflows using Studio | Needing to execute simple automated processes (e.g., IVR, information collection) before connecting to human agents | low | No | No | Only works with **Published Studio Flows** and requires **Active numbers** and pre-configured **TaskRouter Workspaces** | `twilio/guide/twilio-routing` |

## Path Details

### Path 1: Build a custom contact center using the TaskRouter API

**Brief Description**: Twilio TaskRouter provides **skills-based routing** through the **TaskRouter REST API**, enabling dynamic assignment of **Tasks** (calls, chats, emails) to **Workers** based on custom attributes. Core components include **Workspaces**, **Workflows**, **Task Queues**, and **Reservations**, all managed programmatically via **HTTP Basic Auth** using Account SID and Auth Token.

**Key technical facts**:
- Auth method: HTTP Basic Auth using Account SID and Auth Token

### Path 2: Build a contact center using the TaskRouter guide

**Brief Description**: This path offers language-specific guides (C#, Java, Node.js, etc.) to build a **Dynamic Call Center** using **WorkspaceConfig**, **targetWorkers**, and **taskReservationTimeout**. It implements **Product Selection Routing** via **DTMF Input**, supports **Agent Status Updates via SMS**, and handles missed calls through **eventCallbackUrl** and **assignmentCallbackUrl**.

**Key technical facts**:
- Runtimes: C#, Java, Node.js, PHP, Python, Ruby
- Prerequisites: Twilio account with API credentials, Valid phone number for inbound calls, Environment variables set: TWILIO_ACCOUNT_SID, TWILIO_AUTH_TOKEN, TWILIO_NUMBER, MISSED_CALLS_EMAIL_ADDRESS, Node.js and Express installed, Twilio SDK installed via npm

**Known Limitations**:
- Requires configuring multiple callback URLs (assignmentCallbackUrl, eventCallbackUrl, etc.), increasing deployment complexity

**Brief Description**: Provides full-stack implementations of a **Dynamic Call Center** across six languages, featuring **friendlyName** workspace labeling, **selected_product** routing logic, and **Agent Status Updates via SMS**. Uses **assignmentCallbackUrl**, **fallbackAssignmentCallbackUrl**, and **taskReservationTimeout** to manage task lifecycle.

**Key technical facts**:
- Runtimes: C#, Java, Node.js, PHP, Python, Ruby
- Prerequisites: Twilio account with valid credentials, Valid phone number configured for inbound calls, Environment variables set: TWILIO_ACCOUNT_SID, TWILIO_AUTH_TOKEN, WORKFLOW_TIMEOUT, QUEUE_TIMEOUT, ASSIGNMENT_CALLBACK_URL, EVENT_CALLBACK_URL, BOB_NUMBER, ALICE_NUMBER, Ruby and Rails environment with twilio-ruby gem installed

**Known Limitations**:
- Depends on external frameworks (e.g., ASP.NET MVC, Express, Laravel, Django, Rails), increasing technical stack complexity

**Brief Description**: Uses **Studio Flow** to design **Pre-agent workflow** visually, triggered by **Voice Trigger** or **Messaging Trigger**. Collects input via **Gather Input on Call**, looks up customer data with **Search for a Profile**, and routes to agents using **Send to Flex**. Requires **Hold music TwiML URL** and **Active numbers**.

**Key technical facts**:
- Prerequisites: A Twilio phone number configured for voice or messaging, Access to Twilio Console, Flex UI 2.0 enabled for Conversations, Unified Profiles setup and configured, TaskRouter workspace and workflows ready

## FAQ

Q: Which path should I start with?
A: If you have developers and need a working system within a day, start with **Quickly launch using the Dynamic Call Center guide**. If you only need an IVR before human agents and have no coders, use **Studio**.

Q: What if I need **skills-based routing** but chose **Studio**?
A: You’ll hit a hard limitation: **Studio Flow** cannot perform **skills-based routing** or manage **Workers** and **Task Queues**—it can only pass calls to a pre-defined destination after simple input collection.

Q: What if I have no development team but used the **TaskRouter API** path?
A: You’ll struggle with mandatory coding requirements: all **Workflows**, **Reservations**, and **Assignment Callback** logic must be implemented manually, with no visual editor or fallback.

Q: Can I add SMS/email support later if I start with **Studio**?
A: Only if you already have a **TaskRouter Workspace** handling those channels. **Studio** itself doesn’t create **Tasks** for non-voice channels—it just triggers flows that must integrate with a backend routing system.

Q: Why do both **TaskRouter guide** and **Dynamic Call Center guide** exist—they seem similar?
A: They share code patterns, but **TaskRouter guide** focuses on core routing mechanics across languages, while **Dynamic Call Center guide** delivers a complete vertical solution with **selected_product**, **DTMF Input**, and **Agent Status Updates via SMS** as a bundled example.

Q: Do I need **Flex** to use any of these?
A: Not necessarily. **Flex** is Twilio’s UI layer. All **TaskRouter** paths work with custom agent UIs. However, **Studio**’s “**Send to Flex**” widget assumes Flex is enabled—but you can replace it with custom TwiML if needed.

Q: What happens if I forget to publish my **Studio Flow**?
A: Your **Voice Trigger** or **Messaging Trigger** won’t find the flow—it must be **Published** to appear in dropdowns and receive traffic from **Active numbers**.

### [Handle validation](https://company-skill.com/p/twilio/twilio-handle-validation.md)

## What You Want to Do

You want to ensure that incoming webhook requests to your application actually originate from Twilio and not from a malicious actor attempting to spoof requests. This involves verifying the `X-Twilio-Signature` header using your `Auth Token` and ensuring proper security posture.

**Typical User Questions**:
- How to validate Twilio webhook signatures?
- Can I secure my webhook endpoints against spoofing?

## Decision Tree

Pick the best path for your situation:

- **If** you are building a new application in a supported framework (e.g., Django, Flask, ASP.NET Core) and need to implement signature validation logic → Use Use API to verify webhook signature (go to *twilio/twilio-webhook*)
- **If** you are in the planning or architecture phase and need comprehensive security guidance covering HTTPS, authentication, and signature validation across multiple frameworks → Use Follow security guidelines to verify webhook request (go to *twilio/twilio-security*)
- **If** your webhook is already implemented but you’re seeing error codes like `11200: HTTP retrieval failure`, `11216: HTTP invalid redirect error`, or `11217: HTTP error response code` → Use Troubleshoot webhook signature validation issues (go to *twilio/twilio-webhook*)
- **Otherwise (default)** → Start with **Use API to verify webhook signature** — it provides the most direct, automation-friendly implementation for developers actively coding webhook handlers.

## Path Comparison

| Path | Best For | Complexity | Code Required | Automation | Key Fact | Detail Skill |
|------|----------|------------|---------------|------------|----------|-------------|
| Use API to verify webhook signature | Developers needing to implement signature validation logic in custom applications | medium | Yes | Yes | Requires raw request body and correct URL encoding for HMAC-SHA1 signature computation | `twilio/api/twilio-webhook` |
| Follow security guidelines to verify webhook request | Development teams needing to understand best practices for webhook validation across frameworks | low | Yes | No | Covers HTTPS encryption, HTTP Basic Authentication, and Digest Authentication alongside signature validation | `twilio/guide/twilio-security` |
| Troubleshoot webhook signature validation issues | Scenarios where validation is already implemented but issues require diagnosis and resolution | medium | Yes | No | Diagnoses specific Twilio error codes (11200, 11216, 11217) using Request Inspector and Debugger tools | `twilio/troubleshooting/twilio-webhook` |

## Path Details

### Path 1: Use API to verify webhook signature

**Brief Description**: This approach uses Twilio’s `RequestValidator` to compute an `HMAC-SHA1` signature over the `raw request body`, full URL (with properly `URL encoded` query parameters), and your `Auth Token`, then compares it to the `X-Twilio-Signature` header. In ASP.NET, this is often implemented via an `ActionFilterAttribute`; in Python frameworks like Django or Flask, via decorators or middleware.

**Key technical facts**:
- Runtimes: C# / ASP.NET, C# / ASP.NET Core, C# / ASP.NET Web API, Django, Flask, Java Servlet, Lumen
- Auth method: Auth Token via environment variables or configuration files

**When to Use**:
- Need precise control over webhook validation logic in custom applications
- Using supported frameworks (ASP.NET, Django, Flask, etc.) with Twilio SDK integration
- Require CI/CD and automated testing compatibility
- Must handle both JSON and form-data request content types

**When NOT to Use**:
- Team lacks resources to implement custom validation logic
- Using an unsupported programming language or framework
- Only seeking conceptual best practices without implementation
- Already have validation but are debugging failures

**Known Limitations**:
- Must use the `raw request body` — any parsing or modification breaks signature validation
- URL must include all query parameters and be correctly `URL encoded`
- Only supports `HMAC-SHA1` signature algorithm
- Increases development complexity due to framework-specific implementations (e.g., `ActionFilterAttribute` in .NET)

### Path 2: Follow security guidelines to verify webhook request

**Brief Description**: This path follows Twilio’s official security guidance, which recommends layered protection: enforce `HTTPS encryption`, optionally use `HTTP Basic Authentication` or `Digest Authentication`, and always validate the `X-Twilio-Signature header` using an `HMAC-SHA1 signature`. It emphasizes `Webhook validation` as part of a broader strategy including `Media access protection`.

**Key technical facts**:
- Runtimes: C# / ASP.NET, C# / ASP.NET Core, C# / ASP.NET Web API, Django, Flask, Java Servlet, Lumen
- Auth method: Auth Token via environment variables or configuration files

**When to Use**:
- Team needs holistic understanding of webhook security best practices
- Establishing unified security standards across multiple frameworks
- In project planning phase evaluating security requirements
- Want to combine signature validation with transport-layer (`HTTPS encryption`) and application-layer (`HTTP Basic Authentication`) protections

**When NOT to Use**:
- Already know exactly what to implement and just need code examples
- Require automation-friendly or scriptable solutions
- Facing active signature validation failures needing diagnosis
- Only interested in signature checks, not broader security measures

**Known Limitations**:
- Provides guidance, not ready-to-deploy code
- Not suitable for automated deployments
- Requires manual translation of best practices into framework-specific code
- Security configuration varies significantly across frameworks

### Path 3: Troubleshoot webhook signature validation issues

**Brief Description**: This path focuses on diagnosing webhook delivery failures using Twilio’s built-in tools. It addresses specific error codes like `11200: HTTP retrieval failure` (server unreachable), `11216: HTTP invalid redirect error` (redirects not allowed), and `11217: HTTP error response code` (your server returned 4xx/5xx responses). Tools like the `Request Inspector`, `Debugger`, and `Monitor REST API` help analyze failed deliveries.

**Key technical facts**:
- Runtimes: C# / ASP.NET, C# / ASP.NET Core, C# / ASP.NET Web API, Django, Flask, Java Servlet, Lumen
- Auth method: Auth Token via environment variables or configuration files

**When to Use**:
- Already implemented validation but receiving error codes 11200, 11216, or 11217
- Need to inspect actual request/response payloads via `Request Inspector`
- Suspect signature logic is flawed and want to verify inputs
- Troubleshooting network, firewall, or server misconfigurations causing `webhook delivery failure`

**When NOT to Use**:
- Haven’t started implementing webhook validation yet
- Only seeking general best practices without active issues
- Need automation-friendly or deployment-oriented solutions
- Problem is unrelated to delivery or signature (e.g., business logic bugs)

**Known Limitations**:
- Only applicable after initial implementation exists
- Requires access to Twilio Console’s `Debugger` and `Request Inspector`
- Diagnosis depends on specific error codes and server logs
- Does not provide initial setup or coding guidance

## FAQ

Q: Which path should I start with?  
A: If you're actively coding a webhook handler in a supported framework, start with **Use API to verify webhook signature**. If you're designing system-wide security policies, begin with **Follow security guidelines to verify webhook request**.

Q: What if I modified the request body before validation but used Use API to verify webhook signature?  
A: You’ll get consistent signature mismatches because validation requires the exact `raw request body`. Any parsing, trimming, or re-serialization breaks the `HMAC-SHA1` computation.

Q: What if I’m seeing 11217 errors but chose Follow security guidelines to verify webhook request instead of Troubleshoot webhook signature validation issues?  
A: You’ll miss critical diagnostic steps. The guide doesn’t explain how to use the `Request Inspector` or interpret `4xx/5xx responses` that cause `11217: HTTP error response code` failures.

Q: Can I skip signature validation if I use HTTPS encryption?  
A: No. `HTTPS encryption` protects data in transit but doesn’t prove the sender is Twilio. Always validate the `X-Twilio-Signature header` using your `Auth Token` to prevent spoofing.

Q: Why does URL encoding matter in webhook validation?  
A: The `HMAC-SHA1` signature includes the full request URL. If your server decodes query parameters before validation, the computed signature won’t match Twilio’s, causing false negatives.

Q: Is HTTP Basic Authentication enough for webhook security?  
A: No. While `HTTP Basic Authentication` adds a layer, Twilio doesn’t send credentials—it sends a signature. Relying solely on auth methods without `Webhook validation` leaves you vulnerable to replay or spoofing attacks.

Q: What causes 11200: HTTP retrieval failure even when my server is up?  
A: Common causes include firewalls blocking Twilio IPs, TLS misconfiguration, or returning non-2xx status codes during initial handshake. Use the `Debugger` and `Monitor REST API` to inspect connectivity.

### [Implement verification](https://company-skill.com/p/twilio/twilio-implement-verification.md)

## What You Want to Do

You want to verify a user’s identity using methods like SMS, voice calls, email, or advanced techniques such as Silent Network Auth (SNA), TOTP, or push approvals. This includes sending one-time codes, enabling passwordless login, or building secure multi-factor authentication flows.

**Typical User Questions**:
- How to implement two-factor authentication with Twilio?
- Can I use Twilio for phone number verification?
- Does Twilio support silent authentication?
- How to set up voice verification?

## Decision Tree

Pick the best path for your situation:

- **If** you need to use advanced channels like `silent_network_auth`, `TOTP seed`, `push`, or `passkey` and require fine-grained control over parameters like `deviceIp`, `ServiceSid`, or automatic fallback logic → Use **Implement multi-channel verification using Verify API** (go to *twilio/twilio-auth*)
- **If** you are building a mobile app (iOS/Android) and want to implement **Silent Device Approval** using **Verify Push SDK** with **APNs** or **FCM**, and can handle **AccessToken (JWT)** generation and **factor.verified webhook** processing → Use **Rapid integration with Verification SDK** (go to *twilio/twilio-auth*)
- **If** your team has no coding resources and only needs basic SMS or voice verification via a **drag-and-drop** interface using **Send Message widget** and **Gather Input widget** in a **visual builder** → Use **Build verification flows visually using Studio** (go to *twilio/twilio-studio*)
- **Otherwise (default)** → Start with **Implement multi-channel verification using Verify API**, as it supports the widest range of channels (`channel=sms/voice/email/whatsapp/sna/push/totp/passkey/auto`) and integrates directly into backend systems via REST API.

## Path Comparison

| Path | Best For | Complexity | Code Required | Automation | Key Fact | Detail Skill |
|------|----------|------------|---------------|------------|----------|-------------|
| Implement multi-channel verification using Verify API | Need flexible API-driven control over verification workflows, supporting SMS/voice/email across multiple channels | medium | Yes | Yes | Supports `channel=sms/voice/email/whatsapp/sna/push/totp/passkey/auto` with `automatic SMS fallback` | `twilio/api/twilio-auth` |
| Rapid integration with Verification SDK | Mobile apps needing quick integration of verification features, minimizing custom development | low | Yes | No | Requires **APNs**/**FCM** and **AccessToken (JWT)**; **TwilioAuth SDK (deprecated)** | `twilio/guide/twilio-auth` |
| Build verification flows visually using Studio | No-code/low-code teams needing rapid setup of verification workflows without deep development | low | No | No | Built with **Studio Flows** using **Trigger widget**, **Send Message widget**, and **Gather Input widget** | `twilio/guide/twilio-studio` |

## Path Details

### Path 1: Implement multi-channel verification using Verify API

**Brief Description**: Twilio Verify API is a RESTful service that lets you initiate verifications by POSTing to `https://verify.twilio.com/v2/Services/{ServiceSid}/Verifications` and validate codes via `VerificationCheck`. It supports multiple channels including `sms`, `voice`, `email`, `whatsapp`, `sna`, `push`, `totp`, `passkey`, and `auto` (which enables `automatic SMS fallback`). You can bind verifications to a `deviceIp` and manage identities via `Entity API` and `Factor API`. Each verification attempt returns a unique `Verification SID`.

**Key technical facts**:
- Cold start: Silent Network Auth (SNA) latency is 2–4 seconds
- Regions available: IE1 (Ireland/Dublin), US1 (United States)
- Auth method: HTTP Basic Authentication using Account SID and Auth Token or API Key

**When to Use**:
- When you need full control over verification logic and channel selection.
- When integrating with backend systems requiring automation and auditability.
- When supporting advanced features like SNA, TOTP, or passkeys.

**When NOT to Use**:
- When you have no backend developers or prefer zero-code solutions.
- When you only need simple SMS/voice verification without customization.

**Known Limitations**:
- Custom message templates have been deprecated (the `customMessage` parameter is marked as DEPRECATED)
- TOTP factor requires users to use an RFC-6238 compliant authenticator app (e.g., Authy, Google Authenticator)
- Push verification requires additional configuration of APNs/FCM push credentials and handling of Webhook

### Path 2: Rapid integration with Verification SDK

**Brief Description**: This path uses the **Verify Push SDK** (recommended) or the deprecated **TwilioAuth SDK** to enable **Silent Device Approval** on iOS and Android. It relies on **public-key cryptography** for secure approvals and requires **device registration**, **challenge polling**, and server-side handling of the **factor.verified webhook**. The client must authenticate using an **AccessToken (JWT)** issued by your backend.

**Key technical facts**:
- Auth method: Requires server-side generation of AccessToken (JWT)
- Prerequisites: APNs certificate, GCM ID (now FCM), AUTHY_API_KEY (for legacy SDK)

**When to Use**:
- Mobile apps requiring a passwordless push approval experience (Silent Device Approval)

**When NOT to Use**:
- Backend cannot support AccessToken generation or webhook processing

**Known Limitations**:
- TwilioAuth SDK has been officially deprecated — migration to Verify Push SDK is recommended
- Server-side AccessToken generation logic (JWT) must be implemented
- Backend system must handle Verify Push Webhook events (e.g., factor.verified)

### Path 3: Build verification flows visually using Studio

**Brief Description**: Built entirely in the browser using **Studio Flows**, this approach uses a **visual builder** with drag-and-drop widgets like **Trigger widget** (to start the flow), **Send Message widget** (to dispatch SMS/voice), and **Gather Input widget** (to collect user replies). After configuration, you publish the flow via **flow publishing** and link it to a Twilio phone number for **phone number linking**.

**Key technical facts**:
- Auth method: Operated via Twilio Console UI — no direct API auth needed
- Prerequisites: Twilio account, purchased phone number or messaging service, Studio access

**When to Use**:
- Teams with limited coding expertise seeking fast deployment of basic verification flows.
- Prototyping or testing verification logic without writing code.

**When NOT to Use**:
- Need advanced verification channels such as Silent Network Auth, TOTP, or push approval

**Known Limitations**:
- Cannot directly access all Verify API capabilities (e.g., SNA, TOTP, Passkeys); limited to basic SMS/voice interactions
- Advanced verification logic (e.g., multi-factor, device binding) must be implemented via **Make HTTP Request widget** or **Run Function widget** to call external APIs

## FAQ

Q: Which path should I start with?  
A: Start with **Implement multi-channel verification using Verify API** if you have backend developers and need flexibility. It supports all channels—including `silent_network_auth` and `TOTP seed`—and enables automation via REST API.

Q: What if I need Silent Network Auth but chose Studio Flows?  
A: You’ll hit a hard limitation: Studio cannot access `silent_network_auth` because it doesn’t expose the Verify API’s `channel=sna` option. You’d be stuck with basic SMS/voice only.

Q: What if I’m building a mobile app but use the deprecated TwilioAuth SDK instead of Verify Push SDK?  
A: You’ll face future compatibility risks and lack support, as **TwilioAuth SDK (deprecated)** is no longer maintained. New features like enhanced **Silent Device Approval** only work with **Verify Push SDK**.

Q: Can I use Studio to verify users via WhatsApp or email?  
A: No. Studio’s **Send Message widget** only supports SMS and voice. For WhatsApp, email, or other channels, you must use **Verify API** with `channel=whatsapp` or `channel=email`.

Q: What happens if my backend can’t handle webhooks but I choose the Verification SDK path?  
A: You won’t be able to confirm successful approvals, because the **factor.verified webhook** is essential for knowing when a user approves a push challenge. Without it, your app can’t complete authentication.

Q: Does Verify API allow me to bind a verification to a user’s IP address?  
A: Yes — you can pass the `deviceIp` parameter when creating a verification to enhance security and detect anomalies.

Q: What if I need to track individual verification attempts but chose Studio Flows?  
A: You’ll lack access to the `Verification SID`, which is only exposed in the Verify API response and is necessary for auditing or retry logic.

Q: What if I selected Studio Flows but actually need WhatsApp verification?  
A: You’ll be unable to send verifications via WhatsApp, as Studio’s **Send Message widget** does not support `channel=whatsapp`; only Verify API provides this capability.

### [Manage profile](https://company-skill.com/p/twilio/twilio-manage-profile.md)

## What You Want to Do

You want to consolidate customer interactions from multiple channels (web, mobile, call center, etc.) into a single, consistent profile that can be used across Twilio products like Flex and Studio. This requires identity resolution—linking disparate identifiers (email, phone, user_id)—and syncing enriched traits.

**Typical User Questions**:
- How to create unified customer profiles with Twilio?
- Can I resolve user identities across devices?
- How do Twilio and Segment Unify work together?
- Does Twilio support identity resolution?

## Decision Tree

Pick the best path for your situation:

- **If** you need to programmatically resolve identities or delete identifiers via code (e.g., for GDPR compliance) → Use Manage unified identities using Identity Resolution API (go to *twilio/twilio-identity*)
- **If** your team has Identity Admin role and wants to visually configure matching rules using Profile Explorer → Use Configure identity resolution using Unify console (go to *twilio/twilio-identity*)
- **If** you are starting fresh and need to create a new Segment Unify workspace with Twilio integration → Use Set up Segment workspace for Twilio integration (go to *twilio/twilio-cdp*)
- **Otherwise (default)** → If you already have a Segment Unify workspace and want to connect it to Twilio Unified Profiles for use in Flex/Studio, use Connect Segment to Unified Profiles (go to *twilio/twilio-customer_data*)

## Path Comparison

| Path | Best For | Complexity | Code Required | Automation | Key Fact | Detail Skill |
|------|----------|------------|---------------|------------|----------|-------------|
| Manage unified identities using Identity Resolution API | Scenarios requiring automated, programmatic management of identity resolution and customer profiles | high | Yes | Yes | Uses Basic Auth with base64-encoded token; endpoints at profiles.segment.com or profiles.euw1.segment.com | `twilio/api/twilio-identity` |
| Configure identity resolution using Unify console | Business teams wanting to visually configure identity resolution rules and monitor them | medium | No | No | Requires Identity Admin role and space created after October 5, 2020 | `twilio/guide/twilio-identity` |
| Set up Segment workspace for Twilio integration | New users needing to set up a CDP workspace from scratch and integrate with Twilio services | medium | No | No | Requires Segment CDP plan and data warehouse access for Reverse ETL | `twilio/guide/twilio-cdp` |
| Connect Segment to Unified Profiles | Existing Segment workspace users who want to connect to Twilio Unified Profiles | low | No | No | Requires existing Segment Unify space and Profile API access token | `twilio/guide/twilio-customer_data` |

## Path Details

### Path 1: Manage unified identities using Identity Resolution API

**Brief Description**: The Identity Resolution API is a synchronous HTTP service that resolves user identities using external identifiers like email, phone, or user_id. It supports operations such as fetching `user_identifiers`, retrieving `user_traits`, managing `externalIds`, and calling `delete_external_ids`. Enhanced profile data is accessible via `Profiles Sync` exports to your data warehouse, not directly through the API.

**Key technical facts**:
- Auth method: Basic Auth using API access token (base64-encoded `<token>:`)
- Regions available: North America, Europe (EU-West)

**When to Use**:
- Need to integrate identity resolution into event tracking or data pipelines
- Must programmatically delete specific customer identifiers for GDPR/CCPA compliance
- Already have a data warehouse and prefer querying unified profiles via SQL through `Profiles Sync`

**When NOT to Use**:
- Business teams want a visual interface to configure rules
- No development resources to maintain API integrations
- Need real-time profile exploration without setting up data warehouse sync

**Known Limitations**:
- Only programmatic management—no visual interface
- `delete_external_ids` allows only 1 identifier per request
- Profile enhancement data requires `Profiles Sync` export and SQL access; not available via direct API
- Must manually specify region endpoint (`profiles.segment.com` or `profiles.euw1.segment.com`)

### Path 2: Configure identity resolution using Unify console

**Brief Description**: The Unify console provides a no-code interface to configure `Identity Resolution Settings`, including defining which `Trait / Property key to match on`, using `Out-of-the-Box` rules, or choosing to `Add new identifier`. The `Profile Explorer` lets you monitor real-time `profile_merges`, set `Limit` thresholds, define `Blocked Values`, and even `Import from existing space`.

**Key technical facts**:
- Auth method: Console SSO
- Prerequisites: Workspace owner, admin, or user with `Identity Admin` role; space created after October 5, 2020

**When to Use**:
- Business analysts need intuitive UI to adjust identity rules without engineering help
- Want to validate merges in real time using `Profile Explorer`
- Migrating from another space and can `Import from existing space`

**When NOT to Use**:
- Need to automate rule configuration via scripts or CI/CD
- Lack `Identity Admin` permissions
- Your Segment space was created before October 5, 2020

**Known Limitations**:
- Only available to users with `Identity Admin` role
- Spaces created before October 5, 2020 cannot use this feature
- No API support for automating rule configuration
- Cannot batch import complex custom resolution logic

### Path 3: Set up Segment workspace for Twilio integration

**Brief Description**: This path guides you through the Segment UI to `Create Space` (including `Dev space`), `Set identity rules`, enable `API access`, and obtain your `Unify Space ID` and `Profile API token`. You’ll also configure `Reverse ETL` destinations and may use the `SQL Editor` to query `Segment Profiles`.

**Key technical facts**:
- Auth method: Console SSO
- Prerequisites: Segment `CDP plan`, Twilio account with Flex integration capability, data warehouse access

**When to Use**:
- Starting from scratch with no existing Segment Unify workspace
- Your team subscribes to the Segment `CDP plan`
- You have data warehouse infrastructure for `Reverse ETL` or `Profiles Sync`

**When NOT to Use**:
- You already have a working Segment Unify workspace
- Do not have a Segment `CDP plan`
- Lack access to a data warehouse

**Known Limitations**:
- Requires active Segment `CDP plan` subscription
- Needs Twilio account with Flex integration enabled
- Data warehouse access mandatory for full functionality
- Entire setup must be done via UI—no automation possible

### Path 4: Connect Segment to Unified Profiles

**Best For**: Scenarios where you already have a Segment workspace and want to connect it to Twilio Unified Profiles

**Brief Description**: Through the Twilio Console, you `Connect your Segment space to Twilio` by entering your `Segment Unify space ID` and `Profile API access token`. You assign a `Connection friendly name`, map `Identifiers` and `Traits`, and optionally enable `Allow Unified Profiles to write events to Segment` for bidirectional sync. This powers personalization in `Flex` and `Studio`.

**Key technical facts**:
- Auth method: Console SSO
- Prerequisites: Existing Segment Unify workspace, generated `Profile API access token`, Twilio Console permissions to update Flex source write key

**When to Use**:
- Already operate a Segment Unify workspace and want to enable Twilio personalization
- Need to customize `Display name` for `Identifiers` and `Traits` in agent interfaces
- Want Unified Profiles to enrich interactions in `Flex` and `Studio`

**When NOT to Use**:
- No existing Segment Unify workspace
- Haven’t generated a `Profile API access token` in Segment
- Lack permissions to update the Flex source write key in Twilio Console

**Known Limitations**:
- Requires pre-existing Segment Unify workspace
- `Profile API access token` must be generated in advance in Segment
- Twilio Console permissions needed to modify Flex source
- `Traits` must be defined in Segment before they appear in Unified Profiles

## FAQ

Q: Which path should I start with?  
A: If you already use Segment and have a Unify workspace, start with Connect Segment to Unified Profiles. If you’re new to Twilio CDP, begin with Set up Segment workspace for Twilio integration—but only if you have a Segment CDP plan and data warehouse.

Q: What if I need to delete customer identifiers for GDPR but chose the Unify console path?  
A: You’ll hit a hard limitation: the Unify console doesn’t support programmatic deletion. Only the Identity Resolution API supports `delete_external_ids`, and even then, only one identifier per request.

Q: What if my Segment space was created in 2019 but I try to use Configure identity resolution using Unify console?  
A: You’ll be blocked—the Unify console’s `Identity Resolution Settings` and `Profile Explorer` only work for spaces created after October 5, 2020, as stated in the prerequisites.

Q: Can I use the Identity Resolution API without a data warehouse?  
A: Partially—you can resolve identities and delete identifiers, but you cannot access enriched `user_traits` or `profile_merges` because those are only available via `Profiles Sync` exports to a data warehouse.

Q: What happens if I skip generating a Profile API access token but try to connect Segment to Twilio?  
A: The connection will fail—you must first go to your Segment workspace, enable `API access`, and `Generate Token` to obtain a valid `Profile API access token` before linking in Twilio Console.

Q: Is there a way to automate identity rule changes if I use the Unify console?  
A: No—the Unify console does not expose APIs for `Identity Resolution Settings`, so any rule updates (e.g., changing `Blocked Values` or `Limit`) must be done manually in the UI.

Q: Do I need Flex to use Unified Profiles?  
A: Not strictly—but the primary use case for connecting Segment to Twilio is enabling personalized agent experiences in `Flex` and journey orchestration in `Studio`. Without them, value is limited.

### [Send notification](https://company-skill.com/p/twilio/twilio-send-notification.md)

## What You Want to Do

You want to deliver the same or different messages to users via multiple communication channels—such as SMS, WhatsApp, email, or mobile push—notifications—using Twilio’s APIs. You’re deciding whether to unify delivery through one interface or manage each channel separately.

**Typical User Questions**:
- Can I send the same message via SMS and email with Twilio?
- How to send a notification to all user's contact points?

## Decision Tree

Pick the best path for your situation:

- **If** you need to send the **same message** to a user’s **pre-registered SMS, iOS (APN), Android (FCM), or web push devices** using a single API call → Use Use Notify API to send unified multi-channel notifications (go to *twilio/twilio-notify*)
- **If** you need to **customize content per channel** (e.g., rich media on WhatsApp, plain text on SMS) or use **channel-specific features** like `mediaUrl` or `Content Template Builder` → Use Call each channel's API separately (SMS/WhatsApp, etc.) (go to *twilio/twilio-messaging*)
- **If** your use case **only requires email** and you need features like dynamic templates or compliance with **CAN-SPAM** → Use Use Email API alone to send email notifications (go to *twilio/twilio-email*)
- **Otherwise (default)** → Start with **Call each channel's API separately (SMS/WhatsApp, etc.)**, as it offers the broadest channel support (including WhatsApp and SMS) and greatest flexibility, though it lacks email integration in the Notify path.

## Path Comparison

| Path | Best For | Complexity | Code Required | Automation | Key Fact | Detail Skill |
|------|----------|------------|---------------|------------|----------|-------------|
| Use Notify API to send unified multi-channel notifications | Scenarios requiring sending the same notification to all of a user’s bound channels via a single API call | low | Yes | Yes | Does **not support email**; only SMS, FCM, APN, and web push | `twilio/api/twilio-notify` |
| Call each channel's API separately (SMS/WhatsApp, etc.) | Scenarios requiring fine-grained control with customized content or logic per channel | medium | Yes | Yes | Supports **WhatsApp Business Account (WABA)** and **mediaUrl** for MMS/RCS | `twilio/api/twilio-messaging` |
| Use Email API alone to send email notifications | Scenarios that only require email notifications or already have a standalone email-sending workflow | low | Yes | Yes | Requires **domain authentication** and **CAN-SPAM** compliance | `twilio/api/twilio-email` |

## Path Details

### Path 1: Use Notify API to send unified multi-channel notifications

**Brief Description**: The Notify API is a synchronous REST service that sends identical messages to all of a user’s registered endpoints (SMS, iOS push via APN, Android push via FCM, or web push) in one call. It uses concepts like `Identity`, `Bindings`, and `ToBinding` to map users to devices, and requires a `ServiceSid` to scope notifications. Messages are sent via the `/Services/{ServiceSid}/Notifications` endpoint with fields like `Body` and `Priority`.

**When to Use**:
- Need to send real-time alerts, arrival notifications, or transactional messages to all of a user’s devices at once
- Already managing user-device bindings and identities in your system

**When NOT to Use**:
- Need to include **email** in your notification mix (Notify API does not support email)
- Want to send to arbitrary phone numbers without pre-registering `Bindings`
- Require different message content per channel

**Known Limitations**:
- Does not support email notification (channels limited to SMS, iOS/Android/web push)
- Message `Body` is capped at 1,600 characters (SMS constraint)
- Requires pre-registration of user `Bindings` via the Bindings API—cannot send ad-hoc

### Path 2: Call each channel's API separately (SMS/WhatsApp, etc.)

**Brief Description**: The Programmable Messaging API lets you send messages individually to SMS, MMS, RCS, WhatsApp, and Facebook Messenger by calling the `Messages resource` with parameters like `from`, `to`, `body`, and `mediaUrl`. For WhatsApp, you must have a registered **WhatsApp Business Account (WABA)** and use pre-approved templates via the **Content Template Builder** during trial. This approach gives full control over per-channel logic and supports rich media.

**When to Use**:
- Need to customize message content per channel (e.g., longer email-style text on WhatsApp, short SMS fallback)
- Want to use channel-specific features like `mediaUrl` for images or videos
- Already have existing code for specific channels like SMS or WhatsApp

**When NOT to Use**:
- Trying to send the exact same message to all channels with minimal code—this requires multiple API calls
- Expecting a single “broadcast” API that covers email + SMS + push

**Known Limitations**:
- No single API call covers all channels—you must orchestrate separate calls
- WhatsApp messages require pre-approved templates (especially in trial accounts)

### Path 3: Use Email API alone to send email notifications

**Brief Description**: The **Twilio Email API** (powered by SendGrid) and **SendGrid Mail Send API** enable sending transactional or marketing emails via REST. You specify `from`, `to`, and message content, and can use **Marketing Campaigns v3** for bulk sends. Compliance with **CAN-SPAM** (including unsubscribe links) and **domain authentication** (via SPF/DKIM) are required for deliverability.

**When to Use**:
- Only sending email (no SMS, push, or WhatsApp needed)
- Need advanced email features like click tracking, dynamic templates, or campaign management
- Already collecting affirmative consent from recipients

**When NOT to Use**:
- Need true cross-channel delivery (this path is email-only)
- Haven’t set up domain authentication or CAN-SPAM-compliant unsubscribe mechanisms

**Known Limitations**:
- Exclusively supports email—no integration with SMS, WhatsApp, or push
- Requires verified sending address and authenticated domain to avoid spam filters
- Must comply with CAN-SPAM regulations (e.g., clear identification, opt-out mechanism)

## FAQ

Q: Which path should I start with?
A: If you need **SMS + WhatsApp**, start with **Programmable Messaging API**. If you only need **push + SMS to known users**, use **Notify API**. If you only need **email**, use **Twilio Email API**. Avoid Notify if you need email—it’s not supported.

Q: What if I need to send email along with SMS but chose Notify API?
A: You’ll hit a hard limitation: **Notify API does not support email**. You’d have to add a second email-sending system (like Twilio Email API), defeating the purpose of unified delivery.

Q: What if I try to send a WhatsApp message with custom content using Notify API?
A: It won’t work—Notify doesn’t support WhatsApp at all. WhatsApp requires the **Programmable Messaging API** and a **WhatsApp Business Account (WABA)** with approved templates.

Q: Can I send to an unregistered phone number using Notify API?
A: No. Notify requires pre-registered **Bindings** linked to a user **Identity**. To send ad-hoc SMS, you must use the **Programmable Messaging API** with the `to` parameter.

Q: Do I need domain authentication if I only send transactional email via Twilio Email API?
A: Yes. **Domain authentication** (SPF/DKIM) is strongly recommended—and often required by inbox providers—to ensure deliverability, even for transactional email. Without it, messages may be marked as spam.

Q: What happens if I use Programmable Messaging for WhatsApp without a WABA?
A: Your WhatsApp messages will fail. A **WhatsApp Business Account (WABA)** and a Twilio-registered sender are mandatory prerequisites for WhatsApp delivery.

Q: Is there any path that truly unifies SMS, WhatsApp, push, AND email in one call?
A: No. Twilio does not offer a single API that covers all four. **Notify API** covers push + SMS (no email/WhatsApp). **Programmable Messaging** covers SMS/WhatsApp (no email/push). You must combine paths if you need all channels.


## Frequently asked questions

### How do I build a contact center solution?

Twilio enables you to build dynamic contact center applications through its Call Center Automation domain. This capability is integrated into the platform's broader suite for scaling customer engagement solutions.

### How do I securely handle and validate incoming webhooks?

You can securely receive, configure, and manage webhooks using Twilio's Webhook Integration & Management domain. This built-in capability ensures secure webhook handling across your integrations.

### How do I implement user verification or two-factor authentication?

Twilio supports verification workflows through its authentication channels and Security & Fraud Protection domain. These platform capabilities provide the necessary tools for credential security and fraud prevention.

### How do I manage or create unified customer profiles?

Twilio offers Contact, Identity, Data, Audience, and Profile Management tools specifically for customer data unification and segmentation. These features allow you to consolidate and organize customer information across all engagement channels.

## Cross-product integrations

- [AI-Powered Contact Center Intelligence Platform](https://company-skill.com/p/_combos/ai-powered-contact-center-intelligence-platform-cbbc60.md) (eb + es + dataworks + ess + rds)
- [Bailian RAG + ES Chatbot with EventBridge Alerts](https://company-skill.com/p/_combos/bailian-rag-es-chatbot-with-eventbridge-alerts-873dcb.md) (eb + es + bailian + dataworks + ess)
- [Batch Pipeline with Closed-Loop Multi-Channel Notification](https://company-skill.com/p/_combos/batch-pipeline-with-closed-loop-multi-channel-no-ec172e.md) (eb + resend + alinux + ecs + supabase)
- [Bidirectional DingTalk-Lark ECS Provisioning Loop](https://company-skill.com/p/_combos/bidirectional-dingtalk-lark-ecs-provisioning-loo-9c34b9.md) (eb + ecs + alinux + supabase + dataworks)
- [CDP with External Service Alerting](https://company-skill.com/p/_combos/cdp-with-external-service-alerting-8fd368.md) (eb + es + dataworks + ess + rds)
- [CI/CD-Automated RAG-Enabled Secure Production Stack](https://company-skill.com/p/_combos/ci-cd-automated-rag-enabled-secure-production-st-30e7b2.md) (cas + ecs + terraform + oss + alinux)
- [Closed-Loop Infrastructure Alert with Delivery Verification](https://company-skill.com/p/_combos/closed-loop-infrastructure-alert-with-delivery-v-50872d.md) (resend + dataworks + eb + ess + rds)
- [Closed-Loop Multi-Channel Notification Pipeline](https://company-skill.com/p/_combos/closed-loop-multi-channel-notification-pipeline-b18bac.md) (eb + ecs + rds + resend + dataworks)

## Use with an AI agent

```bash
curl -s https://company-skill.com/api/route \
  -H 'Content-Type: application/json' \
  -d '{"query": "...", "product": "twilio"}'
```

MCP server: https://company-skill.com/api/mcp/twilio.py

---
Machine-readable: https://company-skill.com/llms.txt · https://company-skill.com/sitemap.xml