> ## Documentation Index
> Fetch the complete documentation index at: https://docs.atlasscripts.net/llms.txt
> Use this file to discover all available pages before exploring further.

# Providers

> How atlasBridge detects your framework, inventory, and target system, and when to force a provider.

A **provider** is the family the bridge selects for a given role — for example the `esx` framework provider or the `ox` inventory provider. Each provider is backed by an **adapter**: the implementation that translates that family's API into the bridge's normalized contract. You pick a provider with a convar; the bridge loads the matching adapter.

Most owners can leave every provider on `auto`. The bridge detects what you run at startup and loads the right adapter.

## Auto-detection order

When a convar is `auto`, the bridge checks for started resources in a fixed priority order and selects the first match. If nothing matches, it falls back to the standalone provider.

<Tabs>
  <Tab title="Framework">
    ```text theme={null}
    qbx_core → es_extended → qb-core → default
    ```

    Resolved once at boot from the `atlas:framework` convar.
  </Tab>

  <Tab title="Inventory">
    ```text theme={null}
    ox_inventory → qb-inventory → qs-inventory → es_extended → default
    ```

    `es_extended` here means ESX's legacy inventory. Resolved once at boot from `atlas:inventory`.
  </Tab>

  <Tab title="Target">
    ```text theme={null}
    ox_target → qb-target → own
    ```

    `own` is the bridge's built-in interaction prompt. Resolved per call from `atlas:target`.
  </Tab>
</Tabs>

<Warning>
  Framework and inventory are detected **once at boot**. Auto-detection only sees resources that are already started, so your framework and inventory must start **before** `atlasBridge`. If you cannot control start order, force the provider with a convar.
</Warning>

## Supported providers

| Role          | Provider values                                                        |
| ------------- | ---------------------------------------------------------------------- |
| **Framework** | `esx` · `qb` · `qbx` · `default` · `custom`                            |
| **Inventory** | `ox` · `qb` · `qs` · `esx` (legacy) · `default` · `custom`             |
| **UI**        | `own` (default) · `ox` (opt-in) · `framework` (notify only) · `custom` |
| **Target**    | `ox` · `qb` · `own` · `custom`                                         |

For the exact convar names, values, and defaults, see the [Configuration](/atlas-bridge/convars) reference.

## UI defaults to the bridge's own NUI

The default UI provider is the bridge's **own** zero-dependency NUI. `ox_lib` is **opt-in** — set `atlas:ui "ox"` (and start `ox_lib`) to use it. UI is resolved one subsystem at a time, with a safety net: anything a provider does not implement falls back to the bridge's own NUI. That means you can mix providers — for example `ox_lib` progress bars with bridge-owned notifications — and never end up with a missing UI. The radial menu and interaction prompts are always the bridge's own.

## When to force a provider

Set a provider explicitly instead of `auto` when:

* **Start order is wrong.** A framework or inventory that starts after the bridge will be missed by detection.
* **You run more than one candidate.** During a migration you may have two frameworks or inventories installed; force the one you actually use.
* **You want `ox_lib` UI.** The bridge defaults to its own NUI; set `atlas:ui "ox"` (with `ox_lib` started) to use `ox_lib` instead.
* **Your stack is unsupported.** Use `custom` and fill the editable adapter — see [Custom Framework](/atlas-bridge/custom-framework) and [Custom Inventory](/atlas-bridge/custom-inventory).

Example — a QB-Core server using `ox_inventory` and forcing bridge-owned UI:

```cfg theme={null}
setr atlas:framework "qb"
setr atlas:inventory "ox"
setr atlas:ui        "own"
```

## Custom providers

When a provider is set to `custom`, the bridge loads your editable adapter instead of a shipped one:

* `atlas:framework "custom"` → `editable/framework/{server,client}.lua`
* `atlas:inventory "custom"` → `editable/inventory/{server,client}.lua`

If your `custom` adapter fails to load, the bridge falls back to the `_default` adapter so the server still starts. Each editable file lists every method with its expected parameters and return shape.

<CardGroup cols={2}>
  <Card title="Custom framework adapter" icon="https://mintcdn.com/atlasscripts/BwePy2Q7bMLnl0yQ/icons/plug-filled.svg?fit=max&auto=format&n=BwePy2Q7bMLnl0yQ&q=85&s=523bca8bdf53a69adf80f6699df734b4" href="/atlas-bridge/custom-framework" width="24" height="24" data-path="icons/plug-filled.svg">
    The full framework contract and a complete worked example.
  </Card>

  <Card title="Custom inventory adapter" icon="https://mintcdn.com/atlasscripts/BwePy2Q7bMLnl0yQ/icons/box-filled.svg?fit=max&auto=format&n=BwePy2Q7bMLnl0yQ&q=85&s=c228a3b89453b292c0cedb29c252b3ab" href="/atlas-bridge/custom-inventory" width="24" height="24" data-path="icons/box-filled.svg">
    Item shapes and the inventory method set.
  </Card>
</CardGroup>