Location: Targets → RTBs; Targets → RTB Groups
Use case: Prevent expired or nearly expired buyer routes from being returned as valid RTB bids.
Related release note: Bid Expiration and TTL Controls
Overview
An RTB response can look valid when it is returned, but still be unusable by the time a publisher sends the call. This happens when the downstream route expires during the handoff window.
Bid Expiration Controls allow Moja to evaluate the buyer-provided expiration before returning a route. If the bid is already expired—or does not have enough remaining life—it is excluded instead of being returned as a positive result.
Why this matters
Without expiration protection, a publisher can receive a positive bid, send the call, and find that the downstream route has already expired. That produces avoidable failed transfers and makes a valid-looking response misleading.
With expiration protection enabled, Moja can reject stale bids before they reach the publisher.
How the control works
The buyer returns a bid and, when available, an expiration value.
In the RTB response mapping, map the buyer expiration field to Expires At.
Moja calculates the bid’s remaining usable life, including a small safety buffer.
If the bid is expired or below the configured minimum, Moja excludes it from routing.
Absolute expiration versus relative TTL
Use Expires At when the buyer sends an absolute timestamp, such as:
expires_at: 2026-08-11T13:13:31.657Z
Map it in Response Mapping as:
Expires At → [step1].expires_at
Use TTL Seconds only when a buyer sends a relative number of seconds remaining.
Common expiration scenarios
Bid Expiration Controls evaluate the buyer’s actual remaining route life before Moja returns a route.
Buyer response scenario | Example | Result with expiration protection |
Already expired timestamp | The buyer returns a positive bid, but its expiration was 45 seconds ago. | Moja rejects the bid as expired. |
Too little time remaining | The buyer route has 6 seconds remaining and the Minimum Bid TTL is 15 seconds. | Moja rejects the bid as below the configured minimum. |
Healthy remaining lifetime | The buyer route has 45 seconds remaining and the Minimum Bid TTL is 15 seconds. | The bid remains eligible to compete. |
No expiry supplied | The buyer returns a bid but does not provide a usable expiration value. | Behavior depends on the configured policy; see the mixed-group guidance below. |
Understanding a negative remaining lifetime
A buyer may return an absolute expiration timestamp that is already in the past. When Moja compares that timestamp with the response time, the calculated remaining lifetime is negative.
expiration time − response time = negative remaining lifetime
That does not mean the buyer sent a negative TTL integer. It means the buyer-provided expiration timestamp had already passed. When Expires At is mapped, Moja rejects that bid instead of returning it as a positive route.
Configure protection on an RTB endpoint
Open Targets → RTBs, select the RTB endpoint, then configure:
Response Mapping
Expires At: Map the buyer’s absolute expiry field, for example
[step1].expires_at.TTL Seconds: Use only if the buyer returns a relative TTL field.
Bid TTL
Minimum Bid TTL: The minimum number of seconds a bid must have remaining to be eligible. A practical starting point is 10–15 seconds, then adjust for your normal publisher-to-call delay.
Default Bid TTL: A fallback only for buyers that do not provide an expiry. Do not set this merely to compensate for a buyer that should be sending a real expiration value; it can create an assumed lifetime rather than validate the buyer’s actual route life.
Configure protection at the RTB group level
Open Targets → RTB Groups to apply shared controls across a buyer pool:
Minimum TTL: Rejects bids that are expired, too close to expiry, or do not provide a usable expiry value.
Maximum TTL: Excludes bids whose available lifetime exceeds the configured maximum.
Per-target TTL overrides: Use these when one endpoint in the group needs a different policy.
Important: groups with mixed buyer behavior
A group-level Minimum TTL is appropriate only when every endpoint in the group returns a usable expiry value—or when endpoints without expiry should be intentionally excluded.
If a group contains a mix of expiry-aware and non-expiry-aware endpoints, a blanket group Minimum TTL can reject the non-expiry-aware bids because Moja cannot verify that they remain valid.
For mixed groups, use per-target Minimum TTL controls on the endpoints that provide a real buyer expiry, rather than applying one blanket minimum to the entire group.
What publishers receive
Publishers receive only routes that meet the configured expiration policy. If every eligible bid is expired or below the required remaining TTL, Moja returns no valid route instead of returning a route that is likely to fail in transit.
Recommended rollout
Start with RTB endpoints that already return an absolute expiration timestamp.
Map Expires At from the buyer response.
Set a conservative Minimum Bid TTL, such as 10–15 seconds.
Monitor rejected bids and successful handoffs.
Expand to RTB groups only after confirming which endpoints provide usable expiry information.
Related guidance