FiveM
The FiveM integration connects your Discord server to your own FiveM game server, so staff can run in-game actions from Discord, players' money and jobs sync back into the bot, and your community sees a live status embed and restart alerts. It has three moving parts: the bridge resource you install on your game server, txAdmin credentials, and the settings on this page.
Where: Dashboard → Roleplay → FiveM · In Discord: /setup → FiveM Bridge
#How it works
FiveUnity hosts the bot and the website; you host the FiveM server. Two connections run between them:
- Bot → your server (inbound). When a staff member runs a command like
/fivem-weather, the bot sends a request and the bridge resource carries out the action in-game. Authenticated with the inbound bridge key. - Your server → the bot (outbound). The resource pushes player stats (name, identifiers, cash, bank, job, grade and minutes played) and in-game log entries back to the bot. Authenticated with the outbound key.
txAdmin is a separate, optional connection used for bans, kicks by server ID and the /dashboard embed. Nothing works until the resource is installed and running, so start with Install the bridge resource.
#FiveM bridge
The top section of the page. Turn Integration on, fill in your address, then press Save.
| Setting | What it does |
|---|---|
| Integration | Master switch. While it is off, your server's log and stats pushes are rejected, and if you use the Discord whitelist, it stops being enforced (see Whitelist & restarts). |
| Server IP | Your public game address and port, for example 203.0.113.10:30120, or [2001:db8::1]:30120 for an IPv6 host. Use https:// only if your bridge sits behind a TLS reverse proxy. |
| Allow private / LAN addresses | Lets you save an address that resolves to a private or loopback range. Leave it off unless your server really is on a private network the bot can reach. Link-local and cloud metadata addresses stay blocked either way. |
Three buttons sit in the section header. Save writes the settings on the page, Test bridge sends a test request and reports back ("Bridge v2.4.0. Framework: QBCore." (or Qbox, ESX, or None)) and Rotate keys replaces both keys.
If the test reports bridge v1 (update available), the resource on your server predates the signed-request release. It still works, but it does not sign-check requests, does not enforce Discord-only bridge provenance, does not report player identifiers (so /fivem-ban has only the Discord id to ban) and does not report playtime. Ask FiveUnity support for the current copy and replace the folder.
#Bridge keys
The line under Server IP shows API key: set · Outbound key: set so you can tell at a glance whether both exist.
| Key | What it is for |
|---|---|
| Inbound bridge key | The bot presents this on every request to your server. Your resource stores it as bridge_token. |
| Outbound key | Your server presents this when it pushes logs and player stats to FiveUnity. Your resource stores it as bridge_outbound_key. |
Both keys are write-only: they are shown once when they are created and never returned to the dashboard, so reloading the page will never reveal them. If you lose them, rotate and re-paste.
Rotate keys asks you to confirm ("Rotate FiveM bridge keys? Existing keys stop working immediately.") then shows a fresh pair in a Copy keys now panel. The old pair stops working the moment you rotate, so your server fails with unauthorised errors until you paste the new values into server.cfg and restart the resource.
If your resource already has keys you want to keep, use Paste inbound bridge key and Paste outbound key instead, then press Save pasted keys. A pasted key must be at least 24 printable characters with no spaces, and must not be something guessable such as aaaaaaaa…: a bridge key is a full admin credential, and it is also what identifies your server to FiveUnity, so two servers must never share one. Leaving the outbound field empty makes it match the inbound key. Keys saved before this rule existed keep working; they are only checked when you save a new one.
Treat both keys like passwords. Anyone holding the inbound key can give items and money on your server.
From bridge version 2.0.0 the bot no longer sends the inbound key over the network. It sends a signature computed with it, which proves the request came from FiveUnity and cannot be replayed. Bridge 2.1.0 goes further: every endpoint except the health test must carry Discord command provenance. Replies from your server (player names, inventories) are still plain HTTP unless you put a TLS reverse proxy in front of the FiveM HTTP port.
#FiveM log channels
Per-type in-game logs posted by the bridge. Each picker takes a text channel the bot can post in.
| Setting | What it does |
|---|---|
| General FiveM log | The security audit channel. Every bridge command that changes something writes a pending audit entry here before it runs, then updates it with the outcome. |
| Inventory log | Receives inventory entries and a pending/completed entry for every Discord /giveitem. Optional: without it, /giveitem grants are recorded in the General FiveM log only. Your own server scripts can also push entries through the fiveunity:logInventory hook (see the resource README). |
| Money log | Receives money entries: every /giveitem grant of money, cash or bank, plus anything your scripts push through fiveunity:logMoney. Framework money events (paychecks, purchases) are included only if you set bridge_money_events "1" in server.cfg. |
| Admin log | Receives one entry for every in-game action the bot performs (give item, revive, heal, clothing menu, weather, time, drop) naming the staff member who ran the command. Your scripts can add their own with fiveunity:logAdmin. |
| Death log | Receives player deaths: victim, killer and weapon. Captured automatically from baseevents while bridge_death_events "1" (the default) is set, or pushed by your own scripts through fiveunity:logDeath. |
| Transaction log | Receives the structured money ledger your scripts push through fiveunity:logTransaction: sender, receiver, account, amount, reason. This is the channel the Money trace search in Log Lookup reads, so point it at your economy's real movements. |
| Job log | Receives hires, promotions, duty shifts and paychecks pushed through fiveunity:logJob. Framework job and duty changes (QBCore OnJobUpdate / SetDuty, ESX esx:setJob) are captured automatically when bridge_money_events "1" is set. |
| Crime log | Receives robberies, heists, drug runs and bounties your scripts push through fiveunity:logCrime, with an optional payout amount. |
Every one of these channels is indexed into Log Lookup when Log Lookup is enabled, so /logs find and Money trace can search them even though they are configured here rather than on the Log Lookup page. There is nothing extra to set up.
The General FiveM log is not optional. If it is unset, or the bot cannot post in it, every action command is refused with "Security Audit Failed: No Audit Log Channel configured. Integration blocked." Read-only commands such as /player-info and /inventory still work. FiveUnity creates a private fivem-audit-logs channel for you the first time you enable the integration, set your server IP, or save keys.
Each audit entry names the staff member, the action and the details, then turns green on success or red with the reason on failure.
For /giveitem, FiveUnity first writes a durable ItemGrantLog record with the target, item, amount, request ID and Discord executor. It then posts the pending audit embed (and a separate pending entry in the Inventory log, if you set one that is a different channel) and only after all of them succeed does it call the bridge. The game-side endpoint refuses grants that do not carry that Discord provenance, so there is no in-game entry point that can bypass the ledger or audit trail.
If a log channel /giveitem needs is unset or unwritable, FiveUnity writes the attempt as failed in MongoDB but never sends the grant to FiveM. The General FiveM log is always needed; the Inventory log only when you have set one.
#Vouch
Vouch lets trusted members bring other members in: one member runs /vouch on another, and the bot grants a role.
| Setting | What it does |
|---|---|
| Vouch enabled | Turns the /vouch command on. While it is off, /vouch replies that vouch verification is not enabled. |
| Role required to vouch | Only members with this role may run /vouch. Leave it empty and vouching falls back to staff only: a server that never configured this cannot have every member whitelisting people. /vouch itself is open to all members, so this setting is the whole gate. |
| Role granted when vouched | The role added to the person being vouched for. |
| Vouch log channel | Where a 🤝 New Vouch Verified embed is posted, naming the voucher and the vouched member. |
/vouch user:@Name refuses to vouch for yourself, for someone who is not in the server, and for someone who already has the granted role. Each member can only be vouched once: a second attempt names whoever vouched for them first.
Administrators can configure the same thing in Discord with /vouch-setup enable:true required_role:@Whitelisted given_role:@Whitelisted log_channel:#vouch-logs, or from the Configure Vouch System button on the /setup → FiveM Bridge panel.
#txAdmin
Fill in txAdmin URL, txAdmin username and txAdmin password to enable /dashboard and /fivem-ban. /kick-id uses txAdmin too, and falls back to the bridge resource when txAdmin is not configured. The password is write-only and shows Stored (type to replace) once set. Full details and troubleshooting are on txAdmin.
#Whitelist & restarts
| Setting | What it does |
|---|---|
| Whitelist enabled | Turns the Discord whitelist on. With it on and a role picked, the bridge asks FiveUnity about every player who connects. |
| Whitelist role | The Discord role a player must hold to be let in. |
| Status channel | Where the live status embed lives. |
| Restart channel | Where restart alerts are posted. |
| Restart ping role | Mentioned when the server comes back online. |
| Restart announcements | Turns the restart alerts on and off. |
#How the whitelist decides
With Whitelist enabled on and a Whitelist role picked, the bridge resource holds every connecting player at the loading screen for a moment and asks the bot about them. They are let in only if their FiveM identifiers include a linked Discord account, that account is in your Discord, and it holds the whitelist role. Answers are cached for a minute, so a reconnect storm is not an API storm. Use Vouch or your normal role flow to hand the role out.
Refused players see one of:
- "This server is whitelisted through Discord. Link Discord to FiveM (Settings > Connected accounts) and reconnect."
- "This server is whitelisted through Discord. Join the community Discord first, then reconnect."
- "You are not whitelisted yet. Ask the community staff for the whitelist role."
If FiveUnity cannot be reached, if you switch Integration off, or if your subscription lapses, the whitelist stops being enforced and everyone can connect. Your server console says so, naming the reason. To fail closed instead (refusing joins whenever the check cannot be made) set set bridge_whitelist_strict "1" in server.cfg. That is the right setting for a strictly whitelisted server; the default keeps your server playable during an outage.
#The live status embed
Pick a Status channel, then press Post status embed. The bot posts a 📊 Server Status message there: a placeholder at first, filled in on the next refresh. The line at the bottom of the section shows whether it has been posted yet.
From then on the bot rewrites that same message every 60 seconds:
- Online: green, "Server is currently online!", with Players (
current / max) and Connect (your server address). - Offline: red, "Server is currently offline.", with the Last Known IP.
The footer reads Five Unity | Last Updated. Pressing Post status embed again reuses the existing message when the channel has not changed, so you never end up with duplicates.
#Restart alerts
With Restart announcements on and a Restart channel picked, the bot checks your server every 60 seconds and posts when the state changes:
- Going offline: a red ⚠️ Server Restarting embed reading "The server appears to be offline. A restart might be in progress."
- Coming back: a green ✅ Server is Back Online! embed reading "The server is up and ready to join.", mentioning your Restart ping role.
Only changes are announced, so a server that stays up posts nothing.
#Restart schedule
The last section holds your weekly restart times. Press Add time, then set Day, Hour (0-23) and Minute (0-59); Remove time deletes a row. Up to 14 times can be stored.
With Restart announcements on and a Restart channel picked, the bot posts a ⏰ Scheduled restart warning in that channel 10 minutes before each time on the list, mentioning your Restart ping role. It is a heads-up only: FiveUnity does not restart your game server; schedule the restart itself on the server, and keep this list matching it.
The times are read in the timezone set under Dashboard → Roleplay → Log Lookup → Timezone (UTC unless you change it), so a 06:00 row means 06:00 for your staff, not 06:00 UTC. See Log Lookup.
This is separate from the online/offline alerts above. If the server does go down at the scheduled time, you will also see the ⚠️ Server Restarting and ✅ Server is Back Online! embeds from the live check.
#Plans
The FiveM bridge, txAdmin, Vouch, the status embed and restart alerts are included in both Premium and Pro. The current Pro-exclusive features are the AI Assistant ones and the dashboard Log Builder.
Without an active subscription the integration is refused outright: commands reply "This server does not have an active FiveUnity subscription", and your server's log and stats pushes are rejected. See Plans and billing.