Add “Continue with iBunnyApp” to your blockchain game

The flow

1. 1. Register your game in the studio dashboard and create an API key for it.
2. 2. Discover the authorization server from /.well-known/oauth-protected-resource, then send the player through the standard OAuth 2.0 authorization code flow with PKCE and the scopes openid email profile.
3. 3. The player approves your game on the iBunnyApp consent screen and you exchange the code for an access token.
4. 4. Call the iBunnyApp API from your server with your API key plus that player's access token to read their profile, friends, messages, wagers and Bunnycoin balance.

Already run your own accounts? Players can link an existing game account to their iBunnyApp profile instead and keep both — progress stays with you, the social layer syncs across the Capygram network.

API reference

Every request carries two headers: x-bunnycoin-key (which game is asking) and Authorization: Bearer <player access token> (who they are asking for). Reads run as the player, so they only ever see their own data.

GET  /api/public/v1/me                 → profile, username, avatar, Bunnycoin balance
GET  /api/public/v1/friends            → accepted friends + pending requests
GET  /api/public/v1/messages[?with=id] → inbox, or one conversation
POST /api/public/v1/messages           { recipient_id, body }
GET  /api/public/v1/wagers             → the player's wagers and their status
POST /api/public/v1/wagers             { action: "create", opponent_id, amount, note? }
                                       { action: "respond", wager_id, accept }
                                       { action: "cancel",  wager_id }
                                       { action: "report",  wager_id, winner_id }
GET  /api/public/v1/bunnycoin          → balance
POST /api/public/v1/bunnycoin          { delta, memo?, external_ref? }

Server-to-server jobs (leaderboard payouts, refunds) can skip the player token and pass user_id instead — that only works for players who connected your game. Always send a unique external_ref on balance changes so a retry is never applied twice. Errors come back as JSON: invalid_api_key, invalid_access_token, player_not_connected, insufficient_balance.

Wagers are escrowed by iBunnyApp and paid out to the winner once both players report the same result, so your game never has to hold funds.

Download the integration guides

Two free PDFs. Read the handbook yourself, then hand the AI guide to whichever coding assistant is building your game.