Cheetah Digital

Datafly Signal delivers events server-to-server to Cheetah Digital by Marigold (Cheetah Messaging / Marigold Engage) using the Standard Event Trigger API. Each delivered event fires a triggered campaign and loads the recipient’s data into your Cheetah target list, with no client-side pixel and no exposure to ad blockers or browser tracking prevention.

Why route Cheetah Digital through Datafly Signal

• Profiles are updated from the server, not the browser. Events reach Cheetah Digital even when a tracker blocker or a failed page unload would have dropped a client-side call, so the profile reflects what actually happened.
• Email is hashed before leaving your infrastructure. Signal normalises (trim and lowercase) and applies SHA-256 inside your own deployment, so Cheetah Digital receives match keys rather than raw personal data.
• Token lifecycle is handled for you. Signal obtains and refreshes the OAuth credentials Cheetah Digital requires, so nothing expires quietly in the middle of a campaign.
• One consent decision governs every destination. Cheetah Digital is gated by the same consent state as the rest of your stack, so a withdrawal applies everywhere at once.

Prerequisites

Before configuring Cheetah Digital in Signal, you need a Cheetah Messaging account with API access and a configured API Post.

Configuration

Configure in Signal

1. In Signal, open Integrations and add Cheetah Digital.
2. Enter your API Base URL, Consumer Key, Consumer Secret, and API Post ID.
3. Attach the integration to a pipeline and select the Default preset.
4. Save and enable the pipeline.

API Endpoint

Signal authenticates and delivers in two stages.

Token request

POST {API Base URL}/services2/authorization/oAuth2/Token
Content-Type: application/x-www-form-urlencoded

grant_type=password&username={Consumer Key}&password={Consumer Secret}

The response returns an access_token (default 8-hour lifetime). Signal caches it and refreshes automatically on expiry.

Event delivery

POST {API Base URL}/services2/api/Recipients
Authorization: Bearer {access_token}
Content-Type: application/json

Identity Signals

Signal sends the recipient’s system columns as {name, value} pairs so Cheetah can match or create the recipient:

• email: the match key and send address (required, trimmed, lower-cased, plain text).
• name_first / name_last: the contact name.

pk_recip_id is Cheetah’s own record key and is never sent. Other columns (phone, opt-in status, order fields) differ per list: map them as _d.<system column name> once they exist on your list.

Event Mapping

One integration is one API Post, and every call fires the triggered campaign the API Post is set up with. The Default preset sends sign_up and newsletter_subscribed; identify and purchase are mapped but disabled, so enable them only for an API Post meant for them.

Example

{
  "apiPostId": "2515",
  "data": [
    {"name": "email", "value": "jane.doe@example.com"},
    {"name": "name_first", "value": "Jane"},
    {"name": "name_last", "value": "Doe"}
  ]
}

data is an array of {name, value} pairs keyed by the list’s system column names. Add a column by mapping _d.<system column name>. The email is sent in plain text because it is the recipient’s send address; events without an email are not sent.

Testing

1. In Signal, open the Event Debugger and send a test sign_up event from a visitor identified with an email through the pipeline.
2. Confirm the delivery shows a 200 response from /services2/api/Recipients.
3. In the Cheetah console, open the API Post’s target list and confirm the recipient was created or updated.
4. Confirm the triggered campaign fired for the recipient.

Troubleshooting