Skip to main content
Requests a server-side decision for a specific adaptive policy. Used for per-entity optimization when the SDK needs fresh entity weights from the edge rather than resolving from the bundle.
Most use cases don’t need this endpoint. The SDK resolves parameters locally from the config bundle. Use this endpoint only for per-entity adaptive policies configured with resolutionMode: "edge".

Request

POST /v1/decide/:policyId

Path parameters

ParameterTypeDescription
policyIdstringThe adaptive policy ID to get a decision for

Headers

HeaderRequiredDescription
AuthorizationYesBearer traffical_sk_... (requires sdk:read scope)
Content-TypeYesapplication/json

Body

{
  "entityId": "product_123",
  "unitKeyValue": "user_789",
  "allocationCount": 5
}
FieldTypeRequiredDescription
entityIdstringyesThe entity to get a decision for (e.g. productId)
unitKeyValuestringyesUnit key value (typically userId) — used for deterministic selection
allocationCountnumbernoFor dynamic allocations: how many options exist for this entity
contextobjectnoAdditional context (passed through to policy conditions)

Response

200 OK

{
  "allocationIndex": 1,
  "allocationName": "variant_b",
  "weights": [0.25, 0.50, 0.25],
  "coldStart": false,
  "stateVersion": "2025-01-15T10:30:00Z"
}
FieldTypeDescription
allocationIndexnumberIndex of the selected allocation
allocationNamestringName of the selected allocation
weightsnumber[]Current allocation weights (probabilities)
coldStartbooleantrue if no entity-specific weights exist yet (using global prior)
stateVersionstringTimestamp of the entity weight state

How selection works

The endpoint uses deterministic weighted selection:
  1. Reads the current weights for the entity.
  2. Uses a hash of the unit key to deterministically pick an allocation weighted by those probabilities (same user always picks the same allocation while weights don’t change).
  3. If no entity-specific weights exist yet, uses the global prior (cold start).
Selection is deterministic given a fixed weight state, so the same (policyId, entityId, unitKeyValue) always returns the same allocation until the weights change.

Batch endpoint

For multiple decisions in a single request:
POST /v1/decide/batch

Body

{
  "requests": [
    { "policyId": "policy_abc", "entityId": "product_123", "unitKeyValue": "user_789" },
    { "policyId": "policy_abc", "entityId": "product_456", "unitKeyValue": "user_789" }
  ]
}

Response

{
  "results": [
    {
      "allocationIndex": 1,
      "allocationName": "variant_b",
      "weights": [0.25, 0.50, 0.25],
      "coldStart": false,
      "stateVersion": "2025-01-15T10:30:00Z"
    },
    {
      "allocationIndex": 0,
      "allocationName": "variant_a",
      "weights": [0.40, 0.35, 0.25],
      "coldStart": false,
      "stateVersion": "2025-01-15T10:30:00Z"
    }
  ]
}
The batch endpoint groups decisions by policy ID, so multiple entity decisions for the same policy only require one lookup.