Connect to a backend service

Fill in the Backend Service fields

A backend service stores your save inside an envelope of its own, and the Backend Service fields of the Server (HTTP) manager describe that envelope. The address and body templates carry the following placeholders.

Response Payload Path is the dotted route to your save inside the service's answer, with numbers for positions in an array. Leave the load and clear bodies empty for a REST backend, and fill them in for an RPC, the way PlayFab and Nakama need.

Sign-in is your game's job. As soon as it returns, set HttpPersistenceManager.DefaultAuthorization to the session token, which is what {token} stands for.

What {slot} is free to hold depends on whether the service can name the player itself:

• It takes the player from the token, the way PlayFab and LootLocker do. The address names the save alone, so slots are yours and work as they do anywhere else.
• The address has to name the player, which is what the other recipes here do. Turn on Use Slot and set Slots.GlobalSlot to the player id, so {slot} carries it. That asset then holds one save per player.

To have both on a service of the second kind, put an endpoint of your own in front of it: it reads the player from the token, which leaves the slot to you.

PlayFab

The session ticket names the player, so the slot names the save file rather than the player. To give a player several slots, vary the key and the response path together.

Firebase Firestore

Supabase

Supabase serves a table through PostgREST. Create a saves table with an owner uuid primary key defaulting to auth.uid(), a save text column, and a row-level policy for the owner.

Firebase Realtime Database

Nakama

LootLocker

PocketBase

Appwrite

Any GraphQL endpoint

Any other REST backend

To fill in the fields for a service this page doesn't list, find four things in its own documentation:

1. Which endpoint reads, writes and deletes one record, and with which verb.
2. What a write body looks like, with the data in their example replaced by {payload} and nothing escaped.
3. Where the data sits in a read answer, written with dots, and numbers for positions in an array.
4. How the service wants the token. A standard Authorization header needs nothing extra.

Use your own database

Put an endpoint of your own in front of the database. The game never reaches MySQL, Postgres or anything else directly: a connection string in a build is in your players' hands, and WebGL and consoles can't open one at all.

Leave every Backend Service field empty, and the manager sends the payload verbatim to url/slot/id. Your endpoint then needs the three routes Server (HTTP) lists, keyed by the player, the asset and the slot. Verify the token on each of them, and take the player from the token, never from the request body.

Other services

Xano, Directus, Strapi, Parse Server, Back4App and Convex take the Appwrite shape; Hasura, Nhost and AWS AppSync take the GraphQL one. Steam and Unity Cloud Save have a manager of their own.

What an absent save looks like

Two settings decide how the manager reads an answer that carries no save. The first, Empty Answer Means, covers an answer that parsed but holds nothing at the payload path:

A 404 means both "the address is right and holds nothing" and "unknown route, rejected token". The second setting, Not Found Means, settles which one applies: