Zendesk

Datafly Signal delivers your first-party events to the Zendesk Events API as custom events on the Zendesk end-user profile timeline. Each event Signal collects (a page view, a product view, an order, a sign-up) is recorded against the matching Zendesk end user, so your support agents see the customer’s recent activity before they ever open a ticket.

Delivery is server-to-server: events go from your Signal deployment straight to Zendesk’s API. No Zendesk JavaScript runs in the browser.

Prerequisites

• A Zendesk account with the Events API available on your plan.
• An admin or agent email address.
• A Zendesk API token. Create one in Admin Center → Apps and integrations → APIs → Zendesk API → Add API token. Make sure token access is enabled.
• Your Zendesk subdomain (the acme in acme.zendesk.com).

Configuration

Authentication uses Zendesk’s API-token scheme: Signal sends the credential {email}/token:{api_token} as an HTTP Basic Authorization header.

Configure in Signal

1. In your Signal management UI, open Integrations and add Zendesk.
2. Enter your Subdomain, Email, and API Token.
3. Attach the Zendesk blueprint to the pipeline that carries the events you want recorded.
4. Save and enable the integration.

The blueprint maps Signal’s standard snake_case events (page, Product Viewed, Order Completed, Signed Up, Logged In, Lead Generated) to Zendesk custom event types. Any event not in the blueprint is dropped.

API Endpoint

POST https://{subdomain}.zendesk.com/api/v2/user_profiles/events

The request body carries two objects: a profile (which Zendesk matches to an existing end user) and an event (the activity to record).

Identity Signals

Zendesk matches each event to an end user using the profile identifiers Signal sends:

The email is sent in plain form (lowercased, trimmed) — Zendesk matches end users by the actual identifier value, so a hashed email would not resolve to a known user. If no profile matches, Zendesk creates an anonymous user and attaches the event to it.

Marketing consent (from your CMP, via Signal’s canonical consent category) is recorded as a marketing_consent profile attribute (granted / denied / unknown).

Event Mapping

A Signal event like this:

datafly.track("Order Completed", {
  order_id: "1001",
  revenue: 99.99,
  currency: "USD",
  coupon: "WELCOME10"
});

with an identified user:

datafly.identify("u-42", { email: "Jane@Example.com", name: "Jane Doe" });

produces this Zendesk Events API payload:

{
  "profile": {
    "source": "datafly_signal",
    "type": "visitor",
    "name": "Jane Doe",
    "identifiers": [
      { "type": "email", "value": "jane@example.com" },
      { "type": "external_id", "value": "u-42" }
    ],
    "attributes": { "marketing_consent": "granted" }
  },
  "event": {
    "source": "datafly_signal",
    "type": "order_completed",
    "description": "Completed an order",
    "created_at": "2026-06-06T10:00:00Z",
    "properties": {
      "order_id": "1001",
      "revenue": 99.99,
      "currency": "USD",
      "coupon": "WELCOME10"
    }
  }
}

Default event map

Testing

1. Send a test event through the pipeline (or use Signal’s Event Debugger to preview the outgoing payload).
2. In Zendesk, open the matching end user’s profile and check the events / interaction timeline for the new custom event.
3. A successful call returns HTTP 200.

Troubleshooting