> For the complete documentation index, see [llms.txt](https://mango-5m.gitbook.io/mango5m-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mango-5m.gitbook.io/mango5m-docs/resources/mango-mdt/configuration/dispatch-integration.md).

# Dispatch Integration

Choose who raises the on-screen alert for new calls — the MDT's own HUD card, or your dispatch resource.

When a new call comes in (a `/911`, a demo call, or another resource using the `CreateDispatchCall` export), **something** pops an alert on officers' screens. The dispatch bridge decides *what*:

```lua
Config.Bridge = {
    -- ...
    Dispatch = 'mdt',   -- mdt | ps-dispatch | custom | auto
}
```

{% hint style="info" %}
This is an **either/or, not an add-on**: whichever provider is active is the *only* one that alerts, so officers never get the same call twice. The MDT's own Dispatch map and Active Calls board keep working no matter what this is set to — only the transient pop-up alert moves.
{% endhint %}

## `'mdt'` — the built-in alert (default)

The MDT raises its own HUD alert card (with the call details, `Y`/`N` accept/decline prompts, an alert sound) and drops a GPS blip. This is the safe, always-working choice — no extra resources needed. Tuning (display time, sound, blip) lives in `config/dispatch.lua`.

## `'ps-dispatch'` — route alerts through ps-dispatch

The MDT stays quiet and hands each call to ps-dispatch, which raises it in your server's usual HUD style — reaching officers who never opened the tablet.

{% hint style="warning" %}
**ps-dispatch is a QBCore-native resource.** On **QBCore** (and **Qbox** with the qb-core compatibility shim) it works as expected. On a **pure-ESX server** its client begins with `exports['qb-core']:GetCoreObject()`, never initialises, and **no alerts will ever show** even though the resource appears started — use an ESX-compatible fork there, or keep `Dispatch = 'mdt'`.
{% endhint %}

Also check, in ps-dispatch's own config:

* your officers' **job names** are in its valid-jobs list (the MDT forwards the jobs from `Config.Bridge.DispatchOptions.jobs`),
* its **on-duty-only** setting matches how your server tracks duty.

## `'auto'`

Probes for ps-dispatch and falls back to `'mdt'` if it isn't running.

## Which jobs get alerted

```lua
Config.Bridge.DispatchOptions = {
    jobs = { 'police' },
}
```

Most dispatch resources scope alerts by job name; this list is what the MDT passes them. Add every job that should receive MDT calls.

## Adding a different dispatch resource

Copy `bridge/dispatch/template.lua`, implement its one alert function for your dispatch's API, and set `Config.Bridge.Dispatch` to your provider's name. The template documents the exact payload the MDT hands over (coords, street, code, description, blip settings).
