# Get Started

Prepare your app's authentication token and a user ID, then call the Context API and check the response and your service's behavior.

Source: https://cue.airbridge.io/docs/en/quickstart
Language: en
Updated: 2026-10-15

To connect your service to CUE, you need your app's authentication token and a user ID. Marketers define how to use the response and which conditions to apply. Developers call the Context API and implement the rules in your service.

## Before you start

Confirm with your Airbridge contact that CUE is enabled and prediction data is ready for your app.

### Prepare your authentication token

The Context API uses the app SDK token or web SDK token for your app to authenticate requests. In the Airbridge dashboard, go to **\[Settings]>\[Tokens]** to find the token. See [Tokens](https://help.airbridge.io/en/guides/tokens) for details.

Store the token in secure server or CRM settings.

### Choose a user ID

Send exactly one of the following three fields in a Context API request. Use an ID collected for the same app as the token. The value must be a non-empty string.

| Request field             | ID type                                             |
| ------------------------- | --------------------------------------------------- |
| `userId`                  | The Airbridge Generated UUID assigned by Airbridge  |
| `brazeDeviceId`           | The Device ID from the Braze SDK                    |
| `airbridgeExternalUserId` | The external user ID your service sent to Airbridge |

`brazeDeviceId` is different from Braze's `external_id`.

### Connect your user ID

The ID you use in the Context API must identify the user you want to look up. For SDK retrieval instructions and setup for Braze Device IDs and external user IDs, see [User ID mapping in Check Event Tracking](/docs/en/event-integration#user-id-mapping).

### Prepare a test request

Choose a test user and device with user ID mapping set up, then open the app to prepare the ID for your request. Include exactly one ID field in the body described in [Send your first request](#send-your-first-request), and send it with the token for your app. Follow [Check the response](#check-the-response) to review the result.

## Define your use case

Define the screen or message to personalize, the conditions to apply, and the default behavior:

* Choose the screen or message to personalize. For example, you can show different products on the first screen to users with a high predicted likelihood of purchase.
* Choose the predictions to use in your personalization rules. Purchase and churn predictions describe different events, so choose the ones that fit your purpose.
* Define the default screen or message for users who do not meet a condition or whose API response is unavailable.

## Send your first request

The request below looks up an external user ID. Replace `abc-123` with an external user ID that your app sent to Airbridge. Send the request from your server or CRM.

cURL

Set the `AIRBRIDGE_APP_TOKEN` environment variable on your server to the token you prepared, then run the command below. The output includes both response headers and the JSON body.

```bash
curl --request POST --include \
  'https://api.airbridge.io/entry/inference/v1/context' \
  --header "Authorization: Bearer ${AIRBRIDGE_APP_TOKEN}" \
  --header 'Content-Type: application/json' \
  --data '{"airbridgeExternalUserId":"abc-123"}'
```

HTTP

Replace `<AIRBRIDGE_APP_TOKEN>` with the token you prepared.

```http
POST /entry/inference/v1/context HTTP/1.1
Host: api.airbridge.io
Authorization: Bearer <AIRBRIDGE_APP_TOKEN>
Content-Type: application/json

{
  "airbridgeExternalUserId": "abc-123"
}
```

For other ID types, see [Payload examples in the Context API reference](/docs/en/reference/context-api#payload-examples). Include exactly one ID field in the request body.

## Check the response and your service's behavior

After sending the first request, check that the API response is correct. Then test whether your service uses it as intended.

### Check the response

A successful request returns HTTP `200`. The example below shows a successful response.

```http
HTTP/1.1 200 OK
Content-Type: application/json
X-Request-Id: 01915c8e-7a12-7d3f-8b2a-1f2e3d4c5b6a

{
  "requestId": "01915c8e-7a12-7d3f-8b2a-1f2e3d4c5b6a",
  "appId": 1234,
  "user": {
    "id": "abc-123",
    "type": "airbridge_external_user_id"
  },
  "context": {
    "lastTouchpoint": {
      "channel": "media_A",
      "campaign": "moving_service",
      "adGroup": "moving_quote",
      "adCreative": "moving_guide_video",
      "term": null
    }
  },
  "predictions": {
    "d3_purchase": {
      "probability": 0.723,
      "tier": "high"
    },
    "d3_churn": {
      "probability": 0.812,
      "tier": "high"
    }
  }
}
```

* \[ ] Confirm an HTTP `200` response for a test user whose prediction data is ready.
* \[ ] Confirm that `appId` identifies the target app and that `user.id` and `user.type` match the value and type of ID you sent.
* \[ ] Confirm that your service reads the ad attribution fields it needs from `context.lastTouchpoint` and that the values match the attribution result expected in your test.
* \[ ] Confirm that your service reads `probability` and `tier` from `predictions.d3_purchase` and `predictions.d3_churn` and applies the intended rules.

### Check your service's behavior

* \[ ] Confirm the intended screen or message appears both when a user meets a rule and when they do not.
* \[ ] For rules that use installation attribution, confirm that your default rules apply when the `context.lastTouchpoint` object or a required field is `null`.
* \[ ] Confirm that your service uses the default behavior after an API error, a timeout, or an unreadable response.

Use the default behavior when predictions are unavailable. Converting an error into probability `0` or tier `low` would confuse missing information with a low predicted likelihood. See [Error Handling](/docs/en/reference/errors) for how to handle each situation.

## Get help with setup

When contacting Airbridge, include the request time, `requestId`, HTTP status code, and `error.code`. If you did not receive a `requestId`, include the URL, method, and what happened.

Once the initial setup works, review your existing events in [Check Event Tracking](/docs/en/event-integration). Then explore [Using Context](/docs/en/guides/using-context) to define specific personalization rules and default behavior.