How the PulseMDT FiveM integration works

The request path

A Pulse resource runs on the FiveM server and sends authenticated requests to the PulseMDT API for its configured community. The API validates the key and guild scope before returning settings or accepting a write. The web dashboard and Discord bot use the same community records, which is why a call created in game can appear on the dispatch board and a dashboard setting can change resource behavior.

Client scripts should request gameplay actions from the server resource rather than calling PulseMDT directly. The server is the trust boundary: it owns the API key, validates player context, and decides which information is safe to return to a client.

Protect the community API key

Generate a separate key for the FiveM environment and store it only in a server-side configuration file or protected environment value. Do not place it in an NUI bundle, client Lua file, public repository, screenshot, or Discord support message. Anyone who obtains the key may be able to act as that connected server until it is revoked.

Use the smallest practical blast radius. Development and production servers should not share a key, and retired servers should have their keys revoked. When staff with infrastructure access leave, rotate the key along with other deployment secrets.

• Label keys by environment so the active server can be identified during rotation.
• Restrict filesystem access to the resource configuration.
• Redact authorization headers and query values from support logs.
• Revoke first and investigate second if exposure is suspected.

Install in a predictable startup order

Install the current release, set the PulseMDT API endpoint, community identifier, and API key, then ensure the shared/core resource before dependent features. Start with one resource and confirm a successful health or configuration request in the server console. Add dependent scripts only after the base connection is known to work.

A failed request should include enough context to locate the route and status code, but logs should never print the API key. Authentication failures usually point to the wrong community, a revoked key, an extra character copied into configuration, or an endpoint that does not match the deployed PulseMDT instance.

What happens when the CAD is temporarily unavailable

Connected resources cache the configuration and lookup data needed for ordinary operation. If the web service becomes unreachable, cached reads can keep common workflows moving and supported writes can wait for the connection to return. This protects a roleplay shift from a brief network interruption, but it is not a substitute for monitoring or backups.

During an outage, avoid repeatedly restarting resources or regenerating keys unless authentication is the confirmed problem. Record the first error time, preserve the server console, check the public status page, and allow queued work to synchronize after service returns. Repeated retries can hide the original failure and create duplicate roleplay actions in poorly controlled scripts.

Validate actions on the server

Treat every client event as untrusted. The server resource should verify the player, active character, distance, department, duty state, and requested action before reading or writing protected data. UI visibility alone is not authorization; a modified client can call events that are not visible on screen.

Keep roleplay records scoped to the selected community. Never accept a guild or character identifier from the client without checking it against the authenticated server and player session. Rate limits should slow repeated searches or writes without blocking a normal dispatcher or officer workflow.

Update with a rollback you have already tested

Read the release notes, back up the existing resource and configuration, and update a staging server first. Test character selection, one lookup, one call, and one write before moving the release to production. Keep the previous package until the first live shift completes successfully.

If a new version fails, restore the previous resource package without replacing the community key or production data. A code rollback and a credential rotation solve different problems; doing both at once makes diagnosis harder.

• Confirm the resource starts without stack traces or authentication errors.
• Check that configuration values were not renamed or reset.
• Test a denied action as well as an allowed action.
• Verify the web audit trail after the FiveM write.