Integration patterns

With your own backend

1. Payload ready: make an HTTP POST call to the Payload Local API - ready endpoint after the game server is ready for players. This is the only mandatory API call.
   note

   Check the Payload Local API documentation for how to connect to the API and best practices.

2. Reserve a payload for a game session: a payload must be reserved before players connecting to it, otherwise the payload could be removed by the autoscaler. You can reserve programmatically with CreateReservation API endpoint, or manually via the web console. You can set game session details, such as the game map, as metadata. For backend and CI authentication, see IMS service accounts.
   info

   A reservation is made against an allocation. The IMS Orchestration system will reserve the best payload matching your criteria. A reservation will fail if there are no payloads available to use. This can happen if you reach the payload limits of your allocation or during usage spikes.

3. [Optional] Set Payload Annotations: set annotations to your payloads in order to forward information from your backend directly to the game server. For example, map name, party size... Check the metadata documentation page to learn more about how to use it.
4. [Optional] Retrieve game session details: retrieve the payload details from within your game server using the Payload Local API - get payload endpoint. This includes the state the payload is in (useful to know if it is reserved) and its associated metadata (annotations, labels)
5. Clean up a game session: the payload will be unreserved and deleted upon exiting the root process of the game server.

If you have a different integration pattern, please feel free to reach out to your account manager for design verifications.

Calling IMS APIs from your backend

In order to call the IMS APIs from your backend, please see Using a service account to call IMS APIs

With session manager

See Integrating the session manager.