Enrichment API

The Contentsquare Enrichment API is organized around REST. Our API has predictable resource-oriented URLs, accepts form-encoded request bodies, returns JSON-encoded responses, and uses standard HTTP response codes, authentication, and verbs.

Not a developer? Contact your CSM. They will direct you to the best solution to meet your data needs.

• Base URL of the API: https://enrichment-api.{cloud}.contentsquare.com/
• Current Version of the API: 1.0

Contentsquare is a next-gen Analytics tool that helps you understand how and why your users are interacting with your app, mobile and website.

Contentsquare relies on a web tracking tag or mobile SDK to track session-based data. By session we mean a user’s visit on a website or app.

This API allows for enriching the behavioural data tracked by Contentsquare client-side, with other session-based data that can be sent server-side.

For example, you can start reconciling offline and online journeys by enriching web sessions data with phoning data for calls that were triggered from those sessions. As Contentsquare cannot access phone call data during a web session via its tag or SDK, the related data must be sent to Contentsquare server-side, once the calls are ended and processed. In Contentsquare, you can then create user segments based on this phoning data and start answering questions like: “how does a specific journey on my website impact my conversion on the phone?”, or “How do users who end up making a qualitative call behave on my website?”

Making an integration based on the Enrichment API up and running goes through the following steps:

1. As a starting point, the Provider provides an integration schema to Contentsquare and gets listed in the Contentsquare integrations catalog
2. Customers install the integration and provides the Provider with the generated Contentsquare OAuth credentials (client_id/client_secret)
3. During web sessions, the Provider pulls Contentsquare session information (project ID, session ID) that will be used by Contentsquare to match the data received server-side
4. The Provider can then send enrichment data batches:
   1. The Provider authenticates with the OAuth credentials provided by the customer, and receives both a JWT access token valid for 1 hour and the dynamic base URL of the enrichment endpoint (that depends on the cloud the target project is installed on)
   2. The Provider sends the data to the enrichment endpoint with a valid JWT access token

And here is a diagram summarizing the detailed interactions involved in the authentication flow for an integration based on the integration API:

We will detail each step in the following sections.