FiveM Exports and Events: Inter-Resource Communication

Events vs Exports: When to Use Which

FiveM provides two primary mechanisms for inter-resource communication: events and exports. Events are asynchronous and fire-and-forget by nature, making them ideal for notifications, logging, and triggering side effects across resources. Exports, on the other hand, are synchronous function calls that return values immediately, making them perfect for data retrieval and utility functions. Choosing the right mechanism for each use case is fundamental to writing clean, maintainable FiveM code.

Server and Client Events

Events in FiveM flow in specific directions. TriggerServerEvent sends data from the client to the server, where it can be handled securely. TriggerClientEvent sends data from the server to one or all clients using a player source identifier or -1 for broadcast. Local events triggered with TriggerEvent stay within the same execution context. Always register network events with RegisterNetEvent before adding handlers, and remember that any event registered on the client can potentially be triggered by cheaters using injectors.

Securing Your Events

Server-side event handlers should always validate incoming data. Check that the source player exists, verify that the data types match expectations, and apply rate limiting to prevent spam. Never pass sensitive information like database IDs through client events without verification. A common pattern is to use server-side callbacks where the client requests data, the server validates the request and fetches the information, then triggers a response event back to that specific client.

Working with Exports

Exports allow one resource to expose functions that other resources can call directly. You define exports in your fxmanifest.lua and implement them in your script files. When another resource calls exports['your-resource']:YourFunction(args), it executes synchronously and returns the result. This is particularly useful for framework bridges, shared utility libraries, and accessing data from phone scripts, inventory systems, or job managers without coupling resources tightly through events.

Callbacks and Async Patterns

Many FiveM frameworks implement callback systems that combine events with response handling. QBCore uses QBCore.Functions.CreateCallback on the server and QBCore.Functions.TriggerCallback on the client. ESX has a similar pattern with ESX.RegisterServerCallback. These callbacks let the client request data from the server and receive it in a callback function, bridging the gap between asynchronous events and synchronous-feeling code. Understanding these patterns is essential when working with database queries or inventory checks that require server authority.

Best Practices for Resource Communication

Keep your event names namespaced to avoid collisions, using a pattern like resourceName:eventAction. Document your exports clearly so other developers can integrate with your resource. Avoid creating circular dependencies where two resources export to each other, as this can cause load-order issues. When designing APIs for your scripts, prefer exports for simple data access and events for complex workflows that involve multiple steps or side effects across different parts of your server.