> For the complete documentation index, see [llms.txt](https://resources.atriptech.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://resources.atriptech.com/api-document/product-guides/booking/booking-overview/l2b-governance.md).

# 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.

{% hint style="info" %}
**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.
{% endhint %}

### 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.

{% hint style="warning" %}
`DEGRADED` results are not real-time airline results. Treat them as less current or accurate.
{% endhint %}

### 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:

```http
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](/api-document/product-guides/extensions-and-integrations/webhook-overview/l2b-state-change-notification.md) 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. |