ranking api // one decision call

One ranking API to order every feed and fill sponsored slots.

Gortex is a ranking API for consumer platforms. One POST /v1/decide call takes the candidate set a platform already retrieved and returns the order a given user should see, with monetized slots placed inside the same response, in under 200ms p99. No ranking engine to build. No ad server to buy. A trace ID on every decision.

request beta access → read the API contract
p99 latency
< 200 ms
endpoint
1 (/v1/decide)
typed sdks
7 (languages)
integration levels
8 (L0-L7)
# 01 / the short answer

A ranking API returns a ranked order, not another system to maintain.

A ranking API is a hosted endpoint that receives a candidate set and a recipient, then returns the order that recipient should see. Gortex adds the half every consumer platform ends up needing second: sponsored placement resolved inside the same ranked response, in the same latency budget, on the same endpoint.

01 what goes in
A recipient, a surface, and the candidates already retrieved: posts, profiles, listings, jobs, creators, restaurants. Retrieval stays where it lives today.
02 what comes back
The organically ranked order, plus sponsored slots placed against that order rather than bolted beside it, plus a decision ID for audit.
03 what stops being a project
A two-quarter ranker build and a 12-to-24-month ad-infrastructure build collapse into one integration that starts at a single REST call.
request beta access →
# 02 / the problem

Two systems are needed. Neither exists, and neither is your product.

Most consumer platforms arrive here the same way: a feed ordered by a score somebody hand-tuned eighteen months ago, and a new board-level ask to put sponsored items inside it without wrecking relevance.

01 the heuristic ceiling
ORDER BY with a hand-weighted score stops moving engagement, and the one engineer who understood the weights has moved teams.
02 the monetization ask
Sellers, creators and advertisers start asking to pay for placement. Every month without slot logic is margin left on the table.
03 the build estimate
A real ranker plus an ad server means two to three senior engineers diverted for two quarters or longer, a six-figure line item on the core roadmap.
04 the unexplainable ranker
No trace, no audit trail, no answer when a creator, a seller, a PM or a regulator asks why an item ranked first.
# 03 / how the ranking engine works

One call, four stages, inside one latency budget.

The ranking engine runs as a single synchronous decision. Stages are published, not hidden, so a platform architect can review the hot path before it ships.

01 ingest
Candidates, recipient context and surface arrive on POST /v1/decide against an OpenAPI 3.1 contract with 7 typed SDKs.
02 score
Calibrated linear ranking produces comparable scores across candidate types, so relevance and commercial value sit on one scale.
03 place
Deterministic slot filling positions sponsored items against the organic order, priced by opportunity cost rather than dropped on top of it.
04 trace
Every decision returns an ID that resolves to the rationale behind each placement, replayable long after the request is served.
get a beta invite → see the live simulation
# 04 / ranking api by surface

Same ranking API, framed for each surface being ranked.

01 feed ranking api
Rank every social or home feed and fill sponsored slots in one call, ordered per recipient rather than per cron batch.
02 recommendation engine api
Personalized recommendations scored and monetized together, without a separate recommender service to operate.
03 marketplace ranking api
Balance relevance, take-rate and supply across both sides, with promoted listings placed in the same ranked result.
04 personalization api
Per-user ordering for any surface a platform ships: discovery, search results, category browse, notifications.
05 sponsored listings api
Paid placement priced against the organic order, so monetization never quietly outbids relevance.
# 05 / built for

For platforms that own a ranking surface and no ranking team.

a fit not a fit
Seed to Series B consumer platforms, roughly 5 to 100 engineers Catalog-first retail e-commerce
Social feeds, creator and discovery platforms, dating apps Teams that need an ad network to supply advertiser demand
Marketplaces, job boards, food delivery, consumer apps Pre-PMF apps with no interaction volume to rank on
Teams that outgrew a hand-tuned sort with no data science hire budgeted Anyone who needs a live real-time auction this quarter
Surfaces where monetization is already on the roadmap On-prem or air-gapped deployments

The job being hired for is narrow and specific: ship a personalized feed that also earns revenue, without hiring a ranking team or building an ad server.

# 06 / the difference

Ranking APIs rank. Ad servers monetize. This does both.

Comparing vendors? The guide to choosing a ranking api lists what to check before you integrate any of them, Gortex included.

01 vs. a ranking-only api
Relevance ships, then monetization arrives as a second vendor, a second integration and a second latency budget. Gortex resolves both in one response.
02 vs. an ad server
Ad infrastructure hands the ranking problem back: bring your own ranker. Gortex ranks and places in the same call.
03 vs. retail decisioning suites
Enterprise platforms that do both are shaped for SKUs and sold through long enterprise cycles. Gortex is shaped for posts, profiles and listings.
04 vs. building in-house
Published buy-vs-build figures put ad infrastructure at 12 to 24 months, before the ranker. Adoption starts at one REST call.
# 07 / integration path

Start at one REST call. Deepen when a surface earns it.

A published integration ladder replaces the usual rewrite-up-front commitment. Each level is opt-in and reversible.

L0 one call, shadow mode
Send candidates, log the returned order beside the current sort, compare before anything user-facing changes.
L1 live ranking
Serve the ranked order to a slice of traffic, with the trace ID stored against each impression.
L2 sponsored slots on
Turn on monetized placement inside the same response, priced against the organic order.
L3 full surface coverage
Every ranked surface moves onto one contract, one latency budget and one audit trail.

On the roadmap and dated, not implied: real-time auction Q1 2027, learned ranker mid-2027, agent-to-agent levels L4 to L7 from 2027.

# 08 / what is verifiable today

Claims that can be checked before a single line is written.

01 published architecture
Request lifecycle and stage-by-stage internals are documented publicly, including where the decision is made and what it costs in milliseconds.
02 open contract
OpenAPI 3.1 spec and 7 typed SDKs, so the request and response shape can be reviewed before access is granted.
03 live simulation
Three decisioning surfaces run against the real API shape, with baseline and active states side by side and rationale on every card.
04 stated honestly
Private beta, pre-seed, invite-only. No named logos yet, no learned ranker yet, no auction yet: dates published instead of hedges.
# 09 / questions

Ranking API, answered in one line each.

Does retrieval change?

No. Candidate generation stays in place. The ranking API receives those candidates and returns the order.

What about latency?

Sub-200ms p99 in beta on the single decide call, which is what makes it safe in the hot path of a live feed.

Can decisions be explained?

Every response carries a decision ID that resolves to the rationale behind each organic and sponsored placement.

How does a beta start?

Access is invite-only. Integrating during beta also means influencing the Q1 2027 auction design rather than adopting a finished one.

private beta // invite only

Rank your feed and monetize it on one API call.

Beta seats go to consumer platforms with a live ranking surface. Request access to get the OpenAPI spec, an SDK key, and a shadow-mode integration that compares Gortex against the current sort before anything ships to users.

request beta access → talk to engineering
# related // decisioning apis