L2B Governance

Manage Look-to-Book usage through response headers, control outcomes, and state-change notifications.

Atlas uses Look-to-Book (L2B) governance to manage inefficient airline requests.

Request compatibility: This update does not change request parameters or call order.

Read the x-l2b-* response headers for each request. Clients should ignore unrecognized fields.

Scope and calculation

L2B is calculated independently for each combination:

Client × Carrier × API Action

Each rule has a rolling observation window. Windows can be 6, 12, 24, or 48 hours.

Atlas normally evaluates the latest window every five minutes. One carrier or Action never affects another.

ORDER is monitored and can send state-change notifications. It is not degraded or rejected by L2B control.

Whether online control applies to a client, carrier, and Action depends on the effective Atlas configuration.

Action	API
VERIFY	verify.do
GET_OFFERS	getOffers.do
GET_OFFER_PRICE	getOfferPrice.do
GET_SEAT	seatAvailability.do
GET_LUGGAGE	getLuggage.do
ORDER	order.do

For a window W, Atlas calculates:

• N: successful, in-scope real-time API requests

• D: paid orders for the carrier

• K: a base protection allowance

Current L2B = N / (D + K)

Allowed requests = T × (D + K), where T is the configured L2B limit.

Usage = Current L2B / T × 100%

K protects low-volume scenarios. It does not represent a paid order. Degraded and rejected requests do not count toward N.

Calculation example

For a 24-hour window, assume T = 80, D = 3, K = 2, and N = 320:

Current L2B = 320 / (3 + 2) = 64
Allowed requests = 80 × (3 + 2) = 400
Usage = 320 / 400 = 80%

Atlas enters WARNING at this point. Requests remain real-time.

Policy states and request outcomes

Policy state	Meaning
NORMAL	Usage is within the normal range.
WARNING	Usage is near or at the limit.
CONTROL	Sustained over-limit usage is confirmed.

State transition diagram

NORMAL
  │ Usage reaches 80%
  ▼
WARNING
  │ Usage remains at 100% and is confirmed
  ▼
CONTROL
  │ Usage remains below the release threshold, normally 90%
  ▼
WARNING
  │ Usage remains below 70%
  ▼
NORMAL

The current policy enters WARNING at 80% usage. It returns to NORMAL below 70%.

WARNING enters CONTROL after sustained, confirmed 100% usage. CONTROL normally returns to WARNING after sustained usage below 90%.

The configured limit and window remain the source of truth for each rule.

During CONTROL, Atlas does not send affected non-ORDER requests to the airline.

x-l2b-state	Request outcome
NORMAL	The request is not controlled.
WARNING	The request remains real-time.
DEGRADED	Atlas returned a non-real-time fallback result.
REJECTED	No fallback result was available.

CONTROL is a policy state. It appears in state-change notifications, not in request response headers.

DEGRADED results are not real-time airline results. Treat them as less current or accurate.

Response headers

Header	Description
x-l2b-current	Effective L2B in the current window.
x-l2b-limit	Configured L2B limit.
x-l2b-window-minutes	Rolling-window length in minutes.
x-l2b-state	Request state or result.

When no valid decision exists for an identifiable scope, Atlas passes the request through:

x-l2b-current: unknown
x-l2b-limit: unknown
x-l2b-window-minutes: unknown
x-l2b-state: NORMAL

This NORMAL result does not confirm a normal L2B evaluation. If Atlas cannot identify the client, carrier, or Action, it does not return L2B headers.

In browser integrations, Atlas exposes these headers through CORS. Client code can read them directly.

Rejected requests

When x-l2b-state is REJECTED, Atlas returns business error code 907:

Request rejected by L2B control because no degraded result is available.

Use backoff before retrying. Do not use high-frequency retries.

Notifications

Atlas sends Webhook, email, or DingTalk notifications for these policy transitions:

• NORMAL → WARNING

• WARNING → CONTROL

• CONTROL → WARNING

• WARNING → NORMAL

Notifications are best effort. They do not replace response-header monitoring.

Read L2B State Change Notification for endpoint requirements and event fields.

Estimated release time

A CONTROL notification can include an estimated release time. It is based on the current rolling window.

New paid orders can bring that time forward. Reaching the estimate does not guarantee release.

Atlas still confirms sustained usage below the release threshold. Use later notifications and response headers as the final status.

Client handling

NORMAL → WARNING

Requests remain real-time. Check recent request growth for the carrier and Action.

Remove duplicate calls for the same itinerary, Offer, or session. Reuse valid results and apply backoff to automated retries.

WARNING → CONTROL

Record DEGRADED and REJECTED results immediately. Treat DEGRADED results as non-real-time.

Use backoff after error 907. Investigate polling, repeated verification, and repeated Offer requests.

CONTROL → WARNING

Real-time requests resume, but usage remains high. Restore traffic gradually.

Keep deduplication, cache reuse, and retry backoff enabled. Continue monitoring the response headers.

WARNING → NORMAL

Requests have returned to the normal range. Continue using reasonable deduplication, caching, and retry controls.

During CONTROL, identify the carrier and Action before reducing traffic. Do not stop order.do because of an ORDER notification.

For support, provide the event ID, client code, carrier, Action, request ID, timestamp, L2B headers, and business response.

Operational boundaries

• L2B manages request volume relative to paid orders. It is not a billing metric.

• Each client, carrier, and Action is calculated independently.

• A degraded result is not a real-time airline result.

• State changes include an evaluation and confirmation delay.

• Response headers, notifications, and effective configuration provide the observable L2B status.

Effective date and change record

Version	Effective date	Change
1.0	2026-09-14	Introduced response-header outcomes, policy-state notifications, and L2B Webhook guidance.