Sync Slot

Sync a slot through its account session.

Slot sync uses the same optimistic concurrency model as account/slot sync, but the account session token proves this client can access this account and slot.

Request

POST /api/v1/accounts/{accountId}/slots/{slotId}/sync

Send the runtime key as Bearer auth and the account session token in X-Persistly-Account-Session.

HTTP

POST https://api.persistly.app/api/v1/accounts/acc_01HXYZ/slots/autosave/sync
Authorization: Bearer ps_test_your_runtime_key
X-Persistly-Account-Session: pst_01HSESSION
Content-Type: application/json

{
  "baseVersion": 1,
  "slotInfo": {
    "label": "Autosave",
    "level": 6,
    "location": "Reactor"
  },
  "data": {
    "checkpoint": "reactor",
    "level": 6,
    "coins": 612
  }
}

Response

200 OK

Accepted writes return a lightweight status, version, timestamp, and restore-history retention flag. Conflict responses include cloud and local slot branches.

JAVASCRIPT

HTTP/1.1 200 OK
Content-Type: application/json

{
  "status": "accepted",
  "version": 2,
  "updatedAt": "2026-05-04T10:01:00Z",
  "historyRetained": true
}

Concurrency

Account-scoped slot sync still uses baseVersion conflict detection.

Persistly uses optimistic concurrency with baseVersion, the last cloud branch revision your client accepted.

The server returns explicit conflict semantics instead of silently overwriting data.

Conflict responses return product-shaped local/cloud branches so the game can retry from that version.