personalization api // decisioning infrastructure

Per-user ordering,
for every surface you ship.

The ranking layer between retrieval and any surface a user sees. Gortex orders each list per user and fills sponsored slots in one call, so you personalize once instead of rebuilding it surface by surface.

request access → view the simulation

# 01 / the problem

Personalizing every surface in-house gets harder as surfaces multiply.

The first personalized surface is expensive to build. The tenth is expensive to keep consistent with the other nine. Every list, shelf, and module drifts on its own models and its own tuning, and the team that built them keeps them all in sync, on the request path, forever.

01 built once per surface

Each new list or module needs its own ordering logic, feature pipelines, and serving path, then its own tuning as it ages.

02 consistency across surfaces

A user reads as one person on the home shelf and another in search. Keeping the ordering coherent across surfaces is manual work that never ends.

03 latency on every surface load

Ordering runs on the request path. Every added signal is latency you pay each time any surface renders, for every user.

04 explainability debt

When a placement is questioned, there is often no record of why an item landed where it did for that user.

# 02 / how it works

One endpoint orders any surface and places sponsored slots in the same response.

You send a recipient, the surface, and the candidate set you already retrieved. Gortex returns the per-user order and the sponsored placements together, inside one sub-200ms p99 budget, with a decision id you can audit later.

your retrieval

you gather the candidates for the surface: items, listings, profiles, or products.

gortex decides

order the candidates for this user and resolve sponsored slots against that order, in one call.

your surface

render the personalized list with sponsored slots already placed and priced.

01 you keep retrieval

Gortex orders the candidates you bring. No data migration, no re-platforming.

02 ordering and monetization in one call

Per-user order and sponsored slots resolve against each other, so a paid item only takes a slot when the placement fits.

03 every decision is traceable

Each response carries a decision id and a trace id. The reason an item placed where it did is recorded, not reconstructed.

04 seven typed sdks

Generated from one OpenAPI 3.1 spec, so contract drift across languages and surfaces is mechanically impossible.

# 03 / the call

One request. A personalized list and its sponsored slots.

POST /v1/decide
200 OK · 74ms
 // Order a personalized list and fill its sponsored slots.
$ curl api.gortex.ai/v1/decide \
  -H "Authorization: Bearer $GORTEX_KEY" \
  -d '{
    "recipient": { "id": "u_8120" },
    "context":   { "surface": "personalized_list" },
    "items":     [ /* 200 candidate items */ ]
  }'

{
  "ranked":      [ /* ordered item IDs */ ],
  "sponsored":   [{ "slot": 3, "price": 0.42 }],
  "decision_id": "d_01HXZ3M",
  "trace_id":    "t_01HXZ3N"
} 

# 04 / questions

Personalization, answered plainly.

What is a personalization API?

An endpoint that takes any list of candidate items and returns them ordered for a specific user. Gortex places sponsored slots in the same response, so per-user relevance and monetization resolve together.

Do I need to move my data to use Gortex?

No. You keep retrieval and send the candidates you already have. Gortex orders them per user and returns the sequence plus sponsored slots. There is no re-platforming.

How fast is a personalization call?

Per-user ordering and sponsored placement resolve inside one sub-200ms p99 budget, on the request path, so you can call it on every surface load.

# 05 / start

See a personalization decision, live.

The private beta is by invitation. Tell us the surfaces you personalize and we will get you a key.

request access → view the simulation read the anatomy read the guide

Per-user ordering, for every surface you ship.