How to get server-side experience result

Server-side experiments allow you to deliver personalized experiences and A/B test variations directly from your backend. Unlike client-side experiments, where variations are applied in the browser using JavaScript, server-side experiments are resolved on the server before the response is sent to the client. This ensures faster delivery, avoids flickering, and gives developers full control over rendering and applying experiment results.

With Intempt’s Choose API, you can request the appropriate experiment or personalization result for a given user and apply it within your server logic.

To learn how to create and configure experiences in Intempt, check out this guide

Endpoint

POST https://api.intempt.com/v1/{orgName}/projects/{projectName}/optimization/choose-api?apiKey=YOUR_API_KEY

  • orgName – Your Intempt organization name
  • projectName – The project identifier where the experiment is configured
  • apiKey – Your API key (add as query param)

Request body structure

The request body defines how the user is identified and which experiment(s) or group(s) you want to resolve.


Identification

You can identify the user in two ways:

  1. Using sourceId and profileId:
"identification": {
  "sourceId": "1575686747310551XXX",
  "profileId": "profile_c2daf740e3e9f7aa48c6f6563f192XXX"
}
  1. Using a single userId (works only for users that already have this identifier in Intempt):
"identification": {
  "userId": "user_123456"
}

Session and device parameters (optional)

In addition to user identification, you can (and should) provide information about the current session and device type.

  • sessionId – a unique identifier of the user’s current session.
    • This helps group multiple requests from the same browsing or app session.
    • For example: "sessionId": "my_session_1"
  • device – the type of device where the experiment is running.
    • Possible values: "mobile", "desktop".
    • This enables Intempt to serve device-specific experiment variations if configured.

👉 Both sessionId and device can also be used as limitations when configuring experiences in Intempt.
For example, you might restrict an experiment to mobile devices only, or ensure that a variation is consistently applied within the same session.

Although these fields are optional, including them improves both the accuracy of experience delivery and the consistency of reporting.


Resolving by experiment names

You can request specific experiences by passing their unique names:

{
  "identification": {
    "sourceId": "1575686747310551XXX",
    "profileId": "profile_c2daf740e3e9f7aa48c6f6563f192XXX"
  },
  "names": [
    "demo-server-side-experiment",
    "demo-server-side-personalization-most-popular"
  ],
  "device": "mobile",
  "sessionId": "my_session_XXX"
}

Resolving by groups

Alternatively, you can request experiences by specifying the group they belong to:

{
  "identification": {
    "sourceId": "1575686747310551XXX",
    "profileId": "profile_c2daf740e3e9f7aa48c6f6563f192XXX"
  },
  "groups": [
    "my-group"
  ],
  "device": "mobile",
  "sessionId": "my_session_XXX"
}

Example response

A successful response will return the chosen experiment variation(s) for the user. Example:

{
    "choices": [
        {
            "name": "demo-server-side-personalization-most-popular",
            "group": "my-group",
            "body": {
                "label": "My most popular products PERSONALIZATION",
                "products": [
                    {
                        "price": "250.0",
                        "title": "PMC Bronze 9mm (FMJ) 124 GR. 1000 Rds. (SKU: 9G)",
                        "category": "Ammunition"
                    }
                ]
            }
        }
    ]
}

Handling the response

⚠️ Important: Intempt only provides the experiment decision data.
It is your responsibility to interpret this response and apply it in your server-side rendering or business logic.

For example:

  • If the response returns a variation with a modified headline, your backend should replace the headline text before sending the page to the client.
  • If the response includes structured payload data (e.g., button color, feature flags), you should integrate those values into your server logic.

Summary

  • Use the Choose API to fetch server-side experiment or personalization results.
  • Identify users via sourceId + profileId or userId.
  • Request experiences by either names or groups.
  • Process the returned data within your backend — Intempt does not automatically apply the variation.