Register of exportable data structures and formats — Markerra Studio

1. How to obtain the data

The organizer downloads their own data while the account is available, using the "Download my data (JSON)" button in the Studio panel, under "Your account". The panel saves the response as a file named markerra-studio-export-<YYYY-MM-DD>.json. Requesting the export by e-mail is not required — the e-mail route described in §15 of the Terms (a request to kontakt@markerra.app, answered within 14 days) remains available in parallel, as a supplement in case the row limit is exceeded (see section 5) or the panel is unavailable. After the transition period ends, we provide a separate period of at least 30 days to retrieve the data (§15 of the Terms). If the account was closed as part of switching, the operator arranges secure retrieval of the protected copy through the same e-mail route, after verifying identity.

2. Data format and standards used

• File format: JSON (JavaScript Object Notation), conforming to RFC 8259 (The JavaScript Object Notation (JSON) Data Interchange Format) — an open, widely used interoperability specification with no proprietary elements.
• Character encoding: UTF-8.
• Dates and timestamps: ISO 8601 (e.g. 2026-09-04T10:15:30.000Z), always in Coordinated Universal Time (UTC).
• Identifiers: Appwrite database document identifiers ($id) — strings assigned by the database platform, stable over time, also used as keys linking records across export sections (e.g. campaignId on a marker refers to the $id of the corresponding campaign).
• Geographic coordinates: latitude and longitude as decimal numbers (degrees), within the ranges -90…90 (latitude) and -180…180 (longitude) — the same ranges enforced when a game is created. These are standard decimal-degree geographic coordinates as used by mapping and GPS services (equivalent to the WGS 84 reference system); the code does not name the reference system explicitly, so this sentence is an inference from common industry practice, not a direct code citation.
• No proprietary formats: the export uses no format or library requiring a licence, specific software, or a closed specification. The entire document can be read by any JSON parser conforming to RFC 8259.

3. Response structure (envelope)

The export response is a single JSON object with the following fields:

4. Structure of each section

Besides the fields listed below, every row coming from the database carries three database system fields: $id (identifier), $createdAt and $updatedAt (ISO 8601 timestamps) — these three are kept in the export deliberately, since without them the data could not be unambiguously matched during a transfer or used as evidence in a complaint. Row permission and internal database address fields ($permissions, $databaseId, $collectionId) are removed from the export — these are technical details of the provider's infrastructure, not the client's data.

4.1 account (object, no system fields — account data, not a table row)

4.2 games — the organizer's game rows (studio_games table)

4.3 campaigns — published game configurations (campaigns table, addressed as studio-<game id>)

4.4 markers — points of published games (markers table)

Point secrets (QR/NFC token hashes from the marker_tokens table) are not included in the export — they are useless for a transfer, being one-way cryptographic hashes from which the physical marker cannot be reconstructed.

4.5 payments — the organizer's payments (studio_payments table, stripe* fields other than those listed below removed)

Internal payment-provider identifiers other than stripeSessionId and stripePaymentIntentId are removed from the export by a default-deny rule — any new field starting with stripe added to the table in the future drops out of the export by the mere fact that it is not on the allow-list, without any change to the export code being needed.

4.6 acceptances — rule acceptances the organizer made as a player (participant_rule_acceptances table)

This section carries only the organizer's own acceptances, filtered by their userId — not their players' acceptances. It includes acceptances from every game played with this account: the organizer's own games, the public Markerra demo and other organizers' games. A row from another organizer's game carries that game's identifier (campaignId); in a Studio game its organizerId is the identifier of the platform operator (Markerra), the same as in the demo — it does not identify that game's organizer. The notes.acceptances field describes the same scope in the file itself (see 4.7). Player data (including user_markers, reward_claims, and other people's analytics events) is not included in the export, in any section: this is data for which Markerra, not the organizer, is the controller with respect to players, so the organizer has no entitlement to receive it through this export.

4.7 notes — section descriptions (object, no system fields — a description attached to the file, not a table row)

The notes field explains the file and carries no database data. It is an additional field: a reader that does not know it reads all other fields and sections unchanged, which is why the format identifier remains markerra-studio-export-1 (see section 6).

5. Technical limits (Article 26(a))

The response has a combined ceiling of 5,000 rows across all sections. Once exceeded, the response carries truncated: true instead of silently cutting data — the organizer is shown, in the panel, information about completing the export via the e-mail route described in §15 of the Terms. Call frequency is limited by the same rate limiter as game publication; on excess, the response carries a 429 status with a retry-after header.

6. Export format version history

7. Nested structures

7.1 games[].pointsJson — game points as entered by the organizer in the builder

An array of point objects, as saved by the organizer, each with: pid (point identifier, string), title (name, up to 128 characters), type (how the point is completed: "gps", "qr", "nfc" or "code"), task (task description, up to 1024 characters, optional), lat/lng (coordinates, optional — required for type "gps", rules as in section 2), and token (for "qr"/"nfc") or code (for "code") — the point's secret as entered by the organizer. This is the raw working record from the game builder, not the contract issued to players (described in 7.3).

7.2 games[].settingsJson — game settings

An object with the fields: desc (game description, up to 1024 characters, optional), city (up to 120 characters, optional), time (estimated duration, up to 60 characters, optional), organizer (organizer data, structure as in 7.5), publishAck (evidence that the three acknowledgements required before publication were made: version, unmoderated, noThirdPartyData, lawfulAndSafe, at — an ISO 8601 timestamp), and gameplay (stage settings as saved by the panel).

The gameplay field is optional: null or no field means a game without stages. In a game with stages it is an object with the fields version (currently 1), order ("ordered" — stages in sequence, or "free" — in any order) and stages (an array of 1 to 25 stages in the order set in the panel, each with: id (stage identifier), title (stage name, up to 120 characters), kind ("points" or "area"), markerIds (identifiers of the stage's points — pid values from 7.1), requiredCount (for kind: "area" the number of points to find, or null — all points in the area; for kind: "points" always null) and, optionally, radiusMeters (the area radius in metres entered by the organizer, or null — fitted automatically; used only for kind: "area")). This is the raw working record from the panel (the server checks and converts it at publication) — the published form of the stages, with the computed search area, is described by routeJson.gameplay in 7.4.

7.3 campaigns[].markersJson — points issued to players

An array of objects: markerId (identifier), title (bilingual name, object {polish, english}), type (as in 7.1), task (task description), and optionally location: {latitude, longitude} for points with coordinates. This is the contract issued to the player app — derived from pointsJson, without the point's secrets (token/ code are not included here).

7.4 campaigns[].routeJson — game description issued to players

An object with bilingual fields ({polish, english} for each): title (game title), subtitle (description), city (location), difficulty, estimatedTime, rewardTitle, privacyNote (information on location use), safetyNote (safety information). In addition, host — the game organizer's details the game shows to players (structure in 7.5), and gameplay — the game's stages, optional, only in a game with stages: an object with the fields version (currently 1), order ("ordered" — stages in sequence, or "free" — in any order) and stages (an array of 1 to 25 stages, each with: id (stage identifier), title (stage name, up to 120 characters), kind ("points" or "area"), markerIds (identifiers of the stage's points, as markerId in 7.3), requiredCount (the number of points needed to complete the stage), and for kind: "area" additionally area: {center: {latitude, longitude}, radiusMeters} — the search area).

7.5 games[].settingsJson.organizer and campaigns[].routeJson.host — the game organizer's details

An object with the fields: kind ("person" or "company"), name (up to 80 characters), email (up to 120 characters), and for kind: "company" additionally legalName (full legal name, up to 160 characters), taxId (tax identification number, up to 40 characters) and address (up to 200 characters). settingsJson.organizer (as saved by the panel) also has confirmed (a boolean — the organizer's confirmation of responsibility for the game's content, rules and finale), and for kind: "person" the fields legalName, taxId and address may be empty. In routeJson.host (a copy made at publication) the email address is named contactEmail, there is no confirmed field, and the company fields appear only for kind: "company". These are the game organizer's details — not to be confused with organizerJson (see 7.6).

7.6 campaigns[].organizerJson — registration details of the platform operator

Registration details of the platform operator (Markerra) as the app provider, which the game provides to players with its participation rules. A Markerra Studio game receives them from the server as a copy of the public Markerra demo's details (at publication; the server may refresh them when a player joins), so they are the same in every Studio game and do not describe the game's organizer — the organizer's details are in routeJson.host (see 7.4 and 7.5). An object with the fields: organizerId (the operator's identifier — the same value goes into the organizerId field of acceptances, see 4.6), legalName (legal name), registeredAddress (registered address), registration (an object with the fields nip — tax identification number (NIP), 10 digits — and regon — statistical number (REGON), 9 digits), supportEmail (contact address), complaintsEmail (complaints address) and privacyUrls (an object with the fields polish and english — HTTPS addresses of the Privacy policy).