Game API keys
Documentation · Example configuration
Register a game
Open the online-games section of your CanoFlash dashboard, register a game and copy its API key without spaces or edits.
cf_config_t config;
cf_config_init(&config);
config.api_key = "cfn_REPLACE_WITH_YOUR_GAME_KEY";
Treat the key as an opaque string generated by the dashboard. Do not generate your own key or derive it from the game title. The SDK's current field holds at most 63 bytes plus NUL; validate that a copied key fits.
Both development and published games can be admitted by the current registry. Disabled, unknown or malformed keys are rejected when the registry supplies a conclusive response.
Game identity and player authentication
| Value | Purpose | Where it belongs |
|---|---|---|
| Game API key | Identifies the game's room namespace | Compiled into the ROM |
| Device credential | Authenticates the device/account to the service | Managed by CanoFlash firmware |
| Room code | Lets players find a specific room | Shared between participants |
| Seat resume token | Proves possession of a reserved seat during recovery | Managed by firmware |
The game key is public by design: it can be extracted from a ROM. It does not prove a client is an unmodified copy of your game and must not be used as an anti-cheat secret. Games never need account passwords or device JWTs.
The device sends its credential to the service over TLS; the SDK does not receive or expose it.
Keep released ROMs compatible
A shipped cartridge contains its key permanently. The current dashboard does not offer key editing. Disabling or deleting its game registration can prevent future sessions with that ROM.
Use the same key for compatible builds that should play together. Include an
application wire version in matchmaking parameters, for example
"wire=2;mode=coop", and exchange compatibility information after joining.
Parameters only filter matchmaking. A code join can bypass that filter within the same game key. Use a separate registered game/key if incompatible releases need complete room-namespace separation.
Registry availability
The current relay validates game keys through a configurable registry. Conclusive positive/negative results can be cached. If the registry times out, fails or returns an unusable response, the relay currently allows an authenticated session as unverified and does not cache that fallback.
This availability policy does not bypass device authentication. It also means a registry outage is not a dependable way to test whether a game key is valid.
Custom services
The C API does not expose a relay URL or TLS configuration. A custom deployment requires compatible device firmware, routing, trust/authentication and a relay. This SDK checkout does not contain the backend or deployment tooling. The wire protocol documents the integration boundary.