Braze Currents (event source)

Ingest Braze Currents  engagement and behavioral events into Zeotap as first-class events — participating in schema, contracts, real-time streaming, destination forwarding, and identity — using a Custom (server-to-server) event source with the prebuilt Braze Currents schema.

This is the events-pipeline path for Braze Currents. If you instead want Braze events landed in a dedicated warehouse table for modeling (not the events pipeline), use the Braze Currents loader.

How it works

Braze’s Custom HTTP Currents connector POSTs its own native batch envelope — {"events":[...]} — to your ingest endpoint. Zeotap’s standard batch endpoint, POST /v1/batch, reads its event array from a configurable top-level key, so you point Braze at /v1/batch, set the source’s batch array key to events, and Braze’s native payload flows in unchanged (no translation). The write key is passed as a query parameter on the endpoint URL (see Authenticating Braze for why).

Prerequisites

• A Braze account with Currents enabled (a paid add-on — contact your Braze account team if unavailable).

Set up the event source in Zeotap

1. Go to Event Sources and click Create.
2. Choose source type Custom (server-to-server).
3. Under Schema, select Braze Currents. This attaches the prebuilt Braze Currents schema, so Braze’s native fields become first-class columns.
4. The Batch array key field is pre-filled with events (Braze’s envelope key). Leave it as events.
5. Save. Copy the generated write key.

Authenticating Braze

Braze’s Custom HTTP Currents connector authenticates with a single Bearer token field and does not let you add arbitrary custom request headers. Zeotap’s /v1/batch endpoint doesn’t read the Authorization: Bearer header, so instead you pass the write key as a query parameter on the endpoint URL:

https://<your-ingest-host>/v1/batch?writeKey=<your write key>

This is a fully supported way to send the write key — write keys are public identifiers (the same key is embedded in browser SDKs and passed on navigator.sendBeacon URLs), so carrying it in the query string is expected, not a security concern.

If your Braze connector does expose a custom-headers option, you can instead send the key as an X-Write-Key header and use the plain …/v1/batch URL. But the query parameter is the reliable path for Braze’s Currents connector, so this guide uses it throughout.

Configure Braze

Zeotap doesn’t configure Braze for you (Braze has no public API for Currents connectors), so set up the export on the Braze side:

1. In Braze, go to Partner Integrations → Data Export → Currents and create a new Currents export.
2. Choose the Custom HTTP (HTTP / JSON) export type.
3. Set the endpoint to your ingest batch URL with the write key as a query parameter: https://<your-ingest-host>/v1/batch?writeKey=<your write key>
4. If Braze requires the Bearer token field to be filled in, you can paste the same write key there — it’s harmless (Zeotap ignores the Authorization header on this endpoint; the query parameter is what authenticates).
5. Select the event types you want to export.
6. Launch the export. Events begin flowing into Zeotap.

API contract

The endpoint accepts Braze’s native Currents payload — you don’t reshape anything. The write key travels in ?writeKey=, and the source’s batch array key (events) tells /v1/batch where to read the array.

POST https://<your-ingest-host>/v1/batch?writeKey=<your write key>
Content-Type: application/json
 
{
  "events": [
    {
      "event_type": "users.messages.email.Open",
      "id": "6a1b...",
      "time": 1700000000,
      "user": { "external_user_id": "user-123", "user_id": "braze-abc" },
      "properties": { "campaign_id": "abc123", "campaign_name": "Welcome" }
    }
  ]
}

The endpoint returns the number of events accepted:

{ "success": true, "received": 1 }

How data lands

Braze’s Custom HTTP payload is nested: an envelope (event_type, id, time) plus a user object (identity) and a properties object (everything else). Because the source carries the Braze Currents schema and no translation, events flow through in their native shape, and when they’re delivered to a warehouse (see below) the schema maps each nested field to a typed column:

• Envelope → typed columns: event_type, id, time (Braze’s time is unix-epoch seconds, so it lands as a numeric column).
• user fields → user_* columns: user_external_user_id, user_user_id, user_device_id, user_timezone.
• properties fields → properties_* columns: properties_campaign_id, properties_email_address, properties_price, and the rest of Braze’s universal Currents fields across email, push, SMS, content cards, custom events, and purchases.
• Anything not in the schema (rare channels, event-specific one-offs, customer-defined custom_properties / purchase_properties) → the _extra JSON column, so nothing is dropped and the schema stays stable as Braze’s payloads evolve.

Because Braze events carry no Segment type, they are ingested as type custom, so they land in a single per-source table (the Braze event kind is preserved in the event_type column). Note that Braze nests identity under user, so the canonical user_id / anonymous_id envelope columns are empty — identity for these events is user_external_user_id.

Getting events into your warehouse

Ingesting the events is not the same as storing them in your warehouse. To persist Braze events as warehouse tables (with the columns above), create an event-forwarding rule that targets a warehouse — see Event Warehouse. Until such a rule exists, events are accepted, validated, and available to real-time features, but are not written to any warehouse (and forwarding does not back-fill events received before the rule was created). From there the events are normal CDP events — build models, audiences, contracts, and forward them to destinations.

Delivery semantics

At-least-once. Deduplicate downstream on the Braze event id if you need exactly-once.

Troubleshooting