CDP integration

What's CDP?

The Customer Data Platform (CDP) is a powerful tool that enables partners to return enriched data points to FACEIT via the account linkage feature. By integrating with the CDP, advertisers can seamlessly share valuable user data, such as registration, KYC status, last deposit, and last bet. This data allows us to segment users and create targeted, custom tasks (called bonus tasks) that incentivize specific actions on the advertiser's side, such as depositing to receive a free FACEIT Premium Subscription. The CDP helps maximize user engagement and drive conversions, delivering measurable value for our advertising partners.

Flows

The following flows describe possible scenarios of CDP integration. We recommend using the asynchronous approach as suggested below. We don’t insist that the partner implement integration in this way but else the partner should solve the following problems:

1. Data races. Events should be sent only after account integration is finished and all parts of the FACEIT system are aware of the linked partner account.

2. Retrying. All events must be sent to FACEIT. If a send-event request fails, the partner must retry the event until FACEIT accepts it.

Sending initial events after linking accounts (required to launch)

If the user confirmed the email, passed KYC, made the deposit, etc, before linking accounts, the partner should send these events right after the accounts are linked. The partner can send only the last events for repeatable events like making deposits. If the partner can’t send events, they should be retried later.

Note

The account linkage flow is simplified here.

Sending event (required to launch)

When FACEIT and the partner accounts are linked, the partner must start to send user events for the user. For example, if the user confirms the email, the partner must send the corresponding event to FACEIT. If the partner can’t send the event, the event should be retried later.

Sync user's events

This flow isn’t mandatory for launch, but in the future, it can be useful in the following cases:

1. CDP integration was implemented after linking accounts and users already started to link accounts. After CDP integration the partner should send events for all users who linked accounts.

2. There was an incident and events weren’t sent to FACEIT. The partner should resend lost events. Usually, we need to sync events for a list of users or for a time interval, for example, to send events for all users for last week.

Send-event endpoint

This POST request is used to send user events (KYC, deposit, etc.).

• Endpoint

POST https://cdp.faceit.com/cdp/v1/users/events/send

Note

For test env domain will be cdp.faceit-stage.com

• Header (required)

  Content-Type: application/json

  Authorization: We use Bearer authentication. We will share API key.

• Data (JSON format)

  Request body with following params:

Parameter name	Type	Description
platform_user_id	string	The user ID in the partner platform. The partner returns this ID in the user-info-endpoint response after linking accounts.
platform	string	The platform defines the partner ID in the FACEIT.
event	Event	The event contains related to the event information from the partner platform.

The Event contains the following fields:

Field name	Type	Description
id	string	The event identificator. It should be unique for every event. FACEIT uses it to check if the event is already handled. If the partner sends the same ID, FACEIT does nothing and returns OK. For two different events, the partner should send two different IDs.
name	string	The name defines a human-readable event name. FACEIT accepts any event name, but they should be negotiated with management.
created_at	int64	Unix timestamp. It defines the date when the event actually happened, not the time when the event was sent.
attributes	array Attribute	Attributes define event-specific information. It can be empty. FACEIT accepts any attributes, but they should be negotiated with management. The partner doesn’t have to send redundant attributes.

The Attribute contains the following fields:

Field name	Type	Description
name	string	Human-readable attribute name.
value	string	Attribute value.

An example of a well-formed request:

POST https://cdp.faceit.com/cdp/v1/users/events/send
Authorization: Bearer <API key>
Content-Type: application/json
{
  "platform_user_id": "1ee5c514-8064-6a42-ab01-0242ac17000a",
  "platform": "<partner>",
  "event": {
    "id": "deposit-1423452345",
    "name": "deposit",
    "created_at": 1708703778,
    "attributes": [
      {
        "name": "amount",
        "value": "100"
      }
    ]
  }
}

Method returns:

200 HTTP code if an event was sent successfully.

4XX HTTP code with an error object in the response body with the following parameters:

Parameter name	Type	Description
code	string	A human-readable error code used to identify the error that occurred.
message	string	A detailed error message.

An example of a response:

{
   "error": {
      "code": "UserNotFound",
      "message": "user is not found"
   }
}

Note

Currently, there aren’t special errors. The partner should retry every error from FACEIT. That’s why there aren’t examples of error codes.

Integration steps

We suggest that the account linkage is already implemented.

1. The partner must negotiate with management events that will be sent and share the event-name list with FACEIT.

2. FACEIT shares with the partner the platform name and the API tokens for stage and prod.

3. The partner implements the required flows for sending events.

4. FACEIT and partner test account linkage on stage

5. FACEIT and partner test account linkage on prod

Limitation

API rate limit is 40rps.