How to Configure and Test a FiveM Whitelist

A FiveM whitelist admits approved players and rejects others during connection. Choose one documented admission mechanism and test approval, rejection and revocation before enabling it publicly. A Discord membership check and a reviewed player application serve different purposes.

Choose the authority

For txAdmin, use the whitelist modes offered by your installed version. License approval, Discord membership and Discord role checks have different requirements. Selecting one mode does not automatically combine it with another.

Use the official txAdmin project and your installed settings for the current options. If you need multiple conditions, implement a deliberate, reviewed policy rather than running overlapping resources with unclear failure behavior.

Configure the admission flow

1. Back up the active txAdmin profile/configuration and record the current access policy. Keep a verified administrator recovery path.
2. Select the desired whitelist mode in that profile’s settings. For Discord modes, configure the documented bot integration and exact guild/role identifiers first.
3. Write a rejection message with the real application/support route and expected next step. Do not expose private identifiers or bot errors to joining players.
4. Approve a test player using the identifier format accepted by the chosen mode. Obtain it from the actual player record, not an invented example.
5. Join with approved and unapproved accounts, revoke approval and try again. Verify that the change reaches the actual active server profile.

Test dependency failures

For Discord-backed admission, test a missing account identifier, removed role, departed guild member and unavailable Discord integration on staging. Decide whether an unavailable dependency should deny entry with a useful retry message. Do not silently grant access when a check fails.

Keep staff approval permissions limited and record who approved or revoked access. Define how long application and identity records are retained.

When custom code is justified

Use a custom resource only for a requirement the maintained admission system cannot meet. In playerConnecting deferrals, respect the documented tick waits between deferral calls and always reach a controlled completion path.

Validate identifiers, use parameterized queries with the database adapter’s actual API and handle timeouts/errors. Test restarts and revocation before adding caches. An IP address is not a durable player identity, and a static allowlist example is not a complete production admission system.