Reference · built on requestConnectorStreams, queues & webhooks

Twilio Segment

Identify, Track, Page, Screen, Group, and Alias calls from Segment via the Webhooks destination, written back by the Tracking API.

Request accessPricing ↗

About

Twilio Segment is a customer data platform. Websites, apps, and servers send Identify, Track, Page, Screen, Group, and Alias calls to a source through the HTTP Tracking API, and Segment forwards them to destinations, warehouses, and audiences. Each call names a userId or anonymousId and carries a messageId that Segment uses to deduplicate.

Through Fibric, the Webhooks destination delivers a copy of those calls to the connector, signed with a shared secret. An operator reads a customer's stream, proposes an action, and, once you approve, records the outcome as a Track call with the source write key, so every destination sees the same history.

This is a reference listing. It documents what Fibric would read from Twilio Segment and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Identify, Track, Page, Screen, Group, and Alias calls sent by the Webhooks destination as JSON POST requests to up to 5 endpoints per source
  • Delete notifications from the Webhooks destination when a user's data is removed
  • On each payload, the userId or anonymousId, the event name on Track calls, and the messageId that Segment deduplicates on
  • The X-Signature header, an HMAC-SHA1 of the request body under your shared secret, with User-Agent Segment.io/1.0
  • Sources, destinations, warehouses, audiences, functions, tracking plans, and transformations through the Public API at api.segmentapis.com

Proposed actions

  • Target capability: propose a Track or Identify call to the HTTP Tracking API so an operator's decision appears in the customer's stream
  • Target capability: propose a batch call of up to 500 KB, 32 KB per event, when several events must land together
  • Target capability: propose a source or destination configuration change through the Public API

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Spot a customer going quiet

    Track calls for a userId stop arriving. The operator measures the gap against that account's usual rhythm and proposes a check-in, naming the last event seen and when.

    With Churn Watch

  • Follow a cohort after a launch

    Identify traits mark the users who joined in the launch window. The operator tallies their Track calls week by week and proposes a note when the cohort's activity falls behind the one before it.

    With Cohort Watch

  • Reply to a new sign-up while it is warm

    An Identify call with a new userId and a work email arrives. The operator drafts the first reply, and once you approve, records a Track call so the outreach shows in the same stream.

    With Lead Response

  • Prompt a reorder from purchase events

    Purchase events recorded under the Ecommerce spec show the interval between a customer's orders. When the next one is due, the operator proposes a reorder prompt for approval.

    With Reorder Prompt

Requirements

  • A Segment workspace with a server source and its write key
  • The Webhooks destination enabled on each source whose calls the operator reads, pointed at the connector's HTTPS endpoint
  • A shared secret in the destination's advanced settings, so every request carries an X-Signature the connector can check
  • For EU workspaces, the events.eu1.segmentapis.com and eu1.api.segmentapis.com endpoints in place of the US ones
Authentication
The source write key sent as the HTTP Basic Auth username with an empty password for the Tracking API, and a Bearer token created under Workspace settings, Access Management, Tokens for the Public API.

Limits

  • A Tracking API call is at most 32 KB. A batch is at most 500 KB, with 32 KB per event inside it.
  • Segment recommends staying under 1,000 requests per second, and reserves the right to queue events when a workspace sends more than 1,000 events per second.
  • The Webhooks destination expects a response within 5 seconds and retries temporary failures for up to four hours.
  • An event may carry at most 10,000 properties, and a source may have at most 5 webhook endpoints.

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Twilio Segment ↗

Questions and answers

How do Segment calls reach Fibric?
Through the Webhooks destination. Enable it on a source, add the connector's HTTPS endpoint, up to 5 per source, and set a shared secret. Segment POSTs each Identify, Track, Page, Screen, Group, Alias, and Delete call as JSON with an X-Signature header.
Does Segment tell me when a call was rejected?
Rarely. The Tracking API returns 200 for all requests except oversized payloads and JSON errors, which return 400. Above the rate limit it returns 429 with Retry-After and X-RateLimit-Reset headers. Segment deduplicates on messageId, so a safe retry reuses the same one.
Can the operator write events back?
Yes, as proposals. Once approved, the connector sends a Track or Identify call with the source write key, so the decision and its reason appear in the stream your destinations already read.
Ask about Twilio Segment

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Twilio Segment through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy