RTB response caching

RTB response caching suppresses duplicate outbound HTTP requests to the same buyer during:

a single call (voice session), or
a single inbound RTB request.

It reuses the already‑resolved result instead of sending another identical request. Separate calls or separate inbound RTB requests never share cache entries — this is not a global cache of bids.

What is cached

The outbound HTTP result: status code, headers, and body.
Failures, including timeouts and errors.
The loaded and parsed RTB formula configuration for the session (so later steps reuse it without reloading).

Reusing a cached result means Moja does not send a new HTTP request for that evaluation.

How a request is considered identical

A request only matches and can be reused when all of the following are identical after resolution (tags substituted to concrete values):

HTTP method
URL
Query parameters
Request body
Headers

Additional details:

Header names are case‑insensitive.
Parameter/header key order does not matter.
Array element order does matter.
The timeout setting is NOT part of the match. Changing only a timeout does not create a new request.
“Same buyer” or “same formula” alone is not a match. Any changed value — for example a different ZIP/postal code, body content, or header — makes it a separate request.

Lifetime

Cache entries last only for the life of:

that call (voice session), or
that inbound RTB request.

There is no separate seconds‑based expiry.

Multi‑step RTB

In multi‑step RTB, each step is matched on its own fully resolved request. If a later step incorporates a value that came from an earlier response, that change can prevent reuse.

Failures are cached too

Failures (e.g., timeouts, HTTP/network errors) are cached. An identical request later in the same call/request receives the same failure result. Caching here is duplicate suppression, not a retry strategy.

Effects and non‑effects

Fewer duplicate buyer requests and less network overhead.
A cache hit does not consume another outbound request quota.
Expiration on reuse: cached HTTP data is re‑parsed on reuse. If the buyer returns a relative TTL (ttlSeconds) or a formula‑level default TTL applies, the expiry is recalculated from the time of reuse, so a later evaluation using cached data can push the effective expiry later. When the buyer returns an absolute expiresAt timestamp, that timestamp stays fixed. Buyers who need a hard cutoff should return an absolute expiresAt.
Reuse does not by itself make a bid eligible, billable, or routable — normal validation still applies.
Not exactly‑once: simultaneous in‑flight identical requests are not merged.
Separate feature: this differs from inbound request de‑duplication and from buyer bid expiration controls.

How to verify reuse

Identify the relevant session:

For calls, use the Call ID.
For inbound RTB, use the inbound request ID.

Then compare fully resolved outgoing requests — method, URL, params, body, and headers. Compare the actual values, not the formula names. In call/step event details, look for cached results:

Life‑log entries titled “RTB Request Success (Cache)” indicate a cached success.
Distinguish the original failure (if any) from later cache‑served copies.

When sharing examples with support, include the IDs and timestamps, but do not share authentication headers or unnecessary caller data.

Common misconceptions

“Same buyer” isn’t enough — requests must be identical after resolution.
Caching does not override buyer expiration policy: absolute expiresAt does not become later on reuse. Relative TTL (ttlSeconds) or a formula default TTL is recalculated from the reuse time, which can push the effective expiry later. For a hard cutoff, buyers should return an absolute expiresAt.
A cached result means no new request was sent to the buyer.
Failures are cached too; a later identical attempt won’t retry during the same session.