Reference · built on requestConnectorStreams, queues & webhooks

RudderStack

Identify, Track, Page, Screen, Group, and Alias events from RudderStack sources via a Webhook destination, written back over the HTTP API.

Request accessPricing ↗

About

RudderStack is a customer data pipeline. Event Streams sources collect Identify, Track, Page, Screen, Group, and Alias calls from SDKs and servers through an HTTP API on your data plane URL, and Reverse ETL sources pull rows from a warehouse. Each event carries a messageId, a userId or anonymousId, and the timestamps RudderStack needs to correct for client clock skew. Destinations, including a plain Webhook, receive the events in cloud mode.

Through Fibric, a Webhook destination posts each event to the connector. An operator watches the stream for the accounts it is responsible for and proposes actions; once approved, the connector sends one call back through the HTTP API and keeps a receipt of what it sent and why.

This is a reference listing. It documents what Fibric would read from RudderStack 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 events forwarded by the Webhook destination as JSON requests to an HTTP or HTTPS URL
  • Fields set on each event: userId or anonymousId, messageId, type, channel, context, integrations, originalTimestamp, and sentAt
  • Fields RudderStack fills in on ingestion: receivedAt, a timestamp corrected for client-side clock skew, and request_ip
  • Events from Event Streams sources and Reverse ETL sources connected to the same Webhook destination
  • The headers on each delivery: user-agent RudderLabs, content-type application/json, and any custom headers configured on the destination

Proposed actions

  • Target capability: propose a POST to /v1/track or /v1/identify on your data plane URL, authenticated with the source write key
  • Target capability: propose a /v1/alias call that merges an anonymous identity into a known user
  • Target capability: propose a /v1/batch of up to 4 MB, 32 KB per call, when several events belong together

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

What you can build

  • Usage that signals an upgrade

    Track events with their properties show a feature crossing the threshold on the account's plan. The operator proposes an outreach with the event trail attached, and you decide whether it goes.

    With Usage Upsell

  • Merge two records of one person

    The operator notices an anonymousId whose Page events match a known userId's Identify traits. It proposes an Alias call; once approved, the connector sends it and the identities merge.

    With Duplicate Lead

  • Check the pipeline is alive

    The operator compares receivedAt on the newest events with the clock. When the feed from a source stalls beyond its usual cadence, it proposes a freshness notice naming the source.

    With Data Freshness

  • Accounts that have gone quiet

    Track events for an account thin out and then stop. The operator proposes a check-in, with the last event, its timestamp, and the gap measured against the account's own history.

    With Churn Watch

Requirements

  • A RudderStack workspace with an Event Streams source and its write key, shown on the source page below the source name
  • Your workspace's data plane URL, the location where events are routed for processing
  • A Webhook destination connected to the source, pointed at the connector's HTTPS URL, which must present a valid TLS certificate
  • A custom header set on the destination that the connector can check, because the destination offers no request signing
Authentication
HTTP Basic Authentication against the data plane URL using the source write key, with Content-Type application/json; the Webhook destination carries only the headers you configure on it.

Limits

  • Each call is at most 32 KB and a batch at most 4 MB. JSON nested deeper than 200 levels is rejected with a 400.
  • The HTTP API answers 429 when it receives too many requests; the connector must slow down and resend.
  • The Webhook destination signs nothing. It adds only user-agent, content-type, and the custom headers you define.
  • Large integer values should be passed as strings, or precision can be lost in transit.

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 RudderStack ↗

Questions and answers

How do RudderStack events get to Fibric?
Through a Webhook destination. Connect it to the source, set the URL and method, POST by default, and add a custom header the connector can check. RudderStack sends each event as JSON with user-agent RudderLabs and content-type application/json.
How does RudderStack handle clock differences?
Each event carries originalTimestamp from the client and sentAt when it left. RudderStack records receivedAt on ingestion and computes timestamp to account for client-side clock skew. The operator orders events by timestamp and judges freshness by receivedAt.
Can an operator write events into RudderStack?
Yes, once you approve. The connector POSTs to /v1/track, /v1/identify, or /v1/alias on your data plane URL with the source write key, within 32 KB per call, and the event flows to every destination on that source.
Ask about RudderStack

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 RudderStack 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