# Browser, backend and mobile game integration

These are our reference adapters, not completed integrations into another game.
**Cologna** and **klick-game** remain future external consumers. No game-repository
URL or modification is required to use this documentation.

## Existing interfaces

1. Obtain an independently approved network/contract configuration; never derive it from the catalogue. Browse `/v1/listings` and `/v1/inventory/:account`; follow decimal cursors and
   compare canonical checkpoints. A read does not require a wallet key.
2. Hand off a chosen listing to the configured wallet, or use a connected signer
   with the SDK. Display the exact native price/fees; obtain explicit consent.
3. Reconcile receipt and actual ERC-1155 balance before granting final game utility.
   An address entered by a player does not prove wallet ownership.

Examples live in [browser/](../examples/browser/), [backend/](../examples/backend/)
and [mobile/](../examples/mobile/). Browser JavaScript using package imports must
be bundled. Backend samples are read-only and never request a player's private key.
The Godot sample compares the exact supplied network identity and contracts on public HTTP inventory reads; it is not a wallet signer.
Unity/mobile clients can use the same documented JSON contract; no compiled Unity
package or engine acceptance is claimed here.

## Separate game-event and reward services

Existing `grc-platform` SDKs (`sdks/web`, `sdks/server`, `sdks/godot`, `sdks/unreal`)
submit `grc.game-event/v1` events to `POST /v1/events`. A game's own backend issues
short-lived Ed25519 tickets bound to game/player/session and source. Client tickets
are transport credentials; authoritative server tickets stay on that backend.
Protected reward admission also requires the actual manifest authority/budget.
This service is not the marketplace read API and must be configured separately.

The existing reward feed exposes `/v1/index` and immutable artifact paths;
`POST /v1/claims` belongs to the separate budgeted reward relayer. Those are GRC
reward claims, not NFT purchases. Refer to the platform protocol documentation
rather than treating these routes as new marketplace endpoints.

## Explicitly unimplemented extensions

There is no generic wallet challenge/login/session API, OIDC account linking,
HTTP purchase signer, webhook registration/delivery or Unity purchase adapter.
Wallet transaction/claim signatures do not establish an authenticated HTTP session.
Define nonce/expiry/network binding, replay handling and account ownership before
adding wallet linking. Define canonicality, reorg, retry/idempotency and delivery
signatures before adding webhooks. Production accounts, scopes and hosting remain
separate decisions; the current public catalogue creates none of them.