Integrate Otto crash games

01Overview

The integration has two directions. You call Otto to list games and to launch a player into one. Otto calls you whenever money has to move: reading a balance, taking a stake, paying a win and reversing a transaction that did not complete. Every request in either direction is signed with the same shared secret.

1. Otto registers your platform and gives you an API key and an API secret (Onboarding).
2. Your backend lists the games enabled for you with POST /api/platform/games and stores each game's code (Games list).
3. When a player opens a game, your backend calls POST /api/platform/launch and receives a launch_url (Launching a game).
4. Your page loads launch_url in an iframe. From then on the player's browser talks to ottogaming.io directly, over HTTPS and a WebSocket.
5. Each balance read, bet, cash-out and cancel becomes a signed call from Otto to your wallet (Wallet callbacks).

Garanti Zepline is built for betgaranti and opens only to betgaranti and to Otto's own test brand (see Environments). Other operators do not see it in their games list and cannot launch it.

02Environments and test brand

Otto runs one environment, production. There is no separate sandbox host. Every host below uses HTTPS.

Otto's test brand: otto-test

Otto keeps its own brand on production with the platform code otto-test. Its wallet is Otto's reference wallet, a small operator implementation that follows this guide to the letter. Nothing about it is simulated on Otto's side: each bet is a real round, a real ledger entry and a real signed wallet call. Only the money is play money, held in the reference wallet's memory and reset when that wallet restarts.

• Otto uses otto-test to check releases end to end, and can use it to show you a game before your own integration is ready. otto-test is operated by Otto only; demos on it are run by Otto.
• Brand-exclusive games, Garanti Zepline included, open to otto-test through an explicit production setting that applies only to platforms registered as Otto test brands. It changes nothing in betgaranti's own registration.
• There is one live round per game, shared by every brand that carries it. otto-test players therefore fly in the same rounds as betgaranti players and can appear, masked, in the live bets list.

A test registration for your own team

Otto can register a second platform for you, flagged as a test brand and pointed at your staging wallet. The flag is a label only: Otto calls that wallet exactly as it calls a live one, so the same rules apply. Brand-exclusive games stay closed to such a registration unless Otto opens them to it explicitly. Its credentials are delivered privately, like your production ones, and never appear in this guide.

03Onboarding

Before the first request, Otto registers your platform. The exchange below is all that is needed.

Wallet base URL

Give one base URL. For the base https://wallet.casino.example/otto, Otto calls https://wallet.casino.example/otto/debit and so on.

• No placeholder, and no reserved last segment. Operators often send a template such as …/{method}, so Otto removes a trailing / and a last path segment named method, action, endpoint, type, op, command or cmd, in any letter case, with or without {}, <> or a leading :. A real segment with one of these names is removed too: https://api.casino.example/wallet/op is saved as https://api.casino.example/wallet, and Otto would then call /wallet/debit. Choose a base whose last segment is none of these words, and check the URL Otto confirms back to you.
• No redirects. Point the base at the final address: the right scheme, host and path, with or without a trailing slash as your server expects. Otto follows a redirect, but a 301, 302 or 303 turns its POST into a GET with an empty body, which your wallet cannot verify or process, so every call fails.

IP allowlist

• Otto compares the source address of each operator API request with your list, as text. Addresses must match exactly: CIDR ranges are not supported, so list every address, IPv4 and IPv6 separately.
• Write IPv4 addresses in dotted form (203.0.113.10) and IPv6 addresses in their canonical compressed, lowercase form (RFC 5952): 2001:db8::1, not 2001:0DB8:0:0::1 or the expanded form. Otto compares against that canonical form, so any other spelling never matches and every call returns 401.
• An empty list means no IP restriction. We recommend a list for production.
• A request from an address that is not on the list gets the same 401 as a bad signature (see below).
• If your wallet only accepts known sources, ask your Otto contact for the address Otto's wallet calls come from.

You do not need to give Otto your site's domains. The game page and its WebSocket both run on ottogaming.io, inside your iframe.

Looking after the credentials

• Keep the API secret on your servers, in a secret store. It must never reach a browser, a mobile app, a log or a support ticket.
• Rotation replaces the API key and the API secret together, and the old pair stops working at once: for your calls to Otto and for the signatures on Otto's calls to your wallet. Agree a switch time with Otto so both sides change in the same minute.
• Otto rotates by re-issuing your whole registration, so confirm your wallet base URL and your IP allowlist with Otto at the same time, and check one call in each direction straight after the switch.

04Authentication and signing

One scheme covers both directions: your requests to Otto and Otto's wallet calls to you. Each request carries three headers.

message   = X-Timestamp + "." + raw request body
signature = lowercase_hex( HMAC-SHA256( key = API secret, data = message ) )

Rules

• Sign the raw bytes. Serialise your JSON once, sign that exact string and send that same string. Re-encoding the body after signing (key order, spacing, escaping) changes the bytes and breaks the signature.
• Whole seconds, digits only. Otto reads X-Timestamp as an integer and computes the signature over that integer, not over the header text. A millisecond timestamp always fails, and so does a fractional one such as 1791374400.123 (what Date.now() / 1000 or Python's str(time.time()) produce): it passes the time check, but the signatures never match. Truncate to an integer, then use that same string in the header and in the signed message.
• ±300 seconds. Otto accepts a timestamp up to five minutes either side of its own clock. Keep your servers on NTP.
• Empty body. Allowed: the message is then the timestamp followed by a dot, for example 1791374400.. For the games list we recommend sending {}.
• Content type. Send Content-Type: application/json with every body.
• Compare in constant time. When you verify Otto's signature, use hash_equals, crypto.timingSafeEqual or your language's equivalent.
• Replays. The timestamp window is the replay protection on the operator API; there is no nonce. Call Otto over HTTPS only and keep the secret server-side.

Worked example

These values are for checking your implementation. The secret is a dummy and works nowhere.

{"game_code":"48213","player_id":"p-100245","username":"lucky_ace","currency":"TRY","language":"en","device":"MOBILE","return_url":"https://casino.example/lobby"}

More test vectors with the same secret and timestamp:

Pseudo code

body      = json_encode(request)          // serialise once; this exact string is sent
timestamp = to_string(floor(unix_time_seconds()))  // whole seconds, digits only
signature = lowercase_hex(hmac_sha256(key = API_SECRET, data = timestamp + "." + body))

POST https://ottogaming.io/api/platform/launch
  Content-Type: application/json
  Accept:       application/json
  X-Api-Key:    API_KEY
  X-Timestamp:  timestamp
  X-Signature:  signature

  body

curl

# For a quick manual test only: a secret in a shell variable can end up in history.
OTTO_API_KEY='your API key'
OTTO_API_SECRET='your API secret'

BODY='{"game_code":"48213","player_id":"p-100245","username":"lucky_ace","currency":"TRY","language":"en","device":"MOBILE","return_url":"https://casino.example/lobby"}'
TS=$(date +%s)
SIG=$(printf '%s.%s' "$TS" "$BODY" | openssl dgst -sha256 -hmac "$OTTO_API_SECRET" | awk '{print $NF}')

curl -sS https://ottogaming.io/api/platform/launch \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json' \
  -H "X-Api-Key: $OTTO_API_KEY" \
  -H "X-Timestamp: $TS" \
  -H "X-Signature: $SIG" \
  --data-raw "$BODY"

Verifying Otto's wallet calls

Read the body as raw bytes before any JSON parsing, check the key, the time window and the signature, then decode.

<?php
$raw       = file_get_contents('php://input');      // raw bytes, before json_decode
$apiKey    = $_SERVER['HTTP_X_API_KEY'] ?? '';
$timestamp = $_SERVER['HTTP_X_TIMESTAMP'] ?? '';
$given     = $_SERVER['HTTP_X_SIGNATURE'] ?? '';

$expected = hash_hmac('sha256', $timestamp . '.' . $raw, OTTO_API_SECRET);

$valid = hash_equals(OTTO_API_KEY, $apiKey)
    && ctype_digit($timestamp)
    && abs(time() - (int) $timestamp) <= 300
    && hash_equals($expected, $given);

if (! $valid) {
    http_response_code(401);
    header('Content-Type: application/json');
    echo json_encode(['code' => 'UNAUTHORIZED', 'message' => 'Invalid signature.']);
    exit;
}

$call = json_decode($raw, true, 512, JSON_THROW_ON_ERROR);

import crypto from 'node:crypto';

// rawBody: the request body as a Buffer, exactly as received
// (for example from express.raw({ type: 'application/json' })).
export function isSignedByOtto(headers, rawBody) {
  const timestamp = String(headers['x-timestamp'] ?? '');
  const given = Buffer.from(String(headers['x-signature'] ?? ''));

  if (headers['x-api-key'] !== process.env.OTTO_API_KEY) return false;
  if (!/^\d+$/.test(timestamp)) return false;
  if (Math.abs(Date.now() / 1000 - Number(timestamp)) > 300) return false;

  const expected = Buffer.from(
    crypto
      .createHmac('sha256', process.env.OTTO_API_SECRET)
      .update(timestamp + '.')
      .update(rawBody)
      .digest('hex'),
  );

  // Compare byte lengths, not string lengths: Node decodes header values as
  // latin1, so a forged 64-character header can be longer in bytes, and
  // timingSafeEqual throws on buffers of different lengths.
  return given.length === expected.length
    && crypto.timingSafeEqual(given, expected);
}

When authentication fails

05Games list

Returns the games you may launch. The body can be anything, but it is signed like every other body; send {}.

[
  {
    "code": "48213",
    "name": "Garanti Zepline",
    "kind": "crash",
    "rtp": "0.9700",
    "version": 1,
    "is_active": true,
    "max_win_multiplier": 5000,
    "images": []
  }
]

• A game is listed when it is enabled for your platform, active, available on Otto, and allowed for your brand. Brand-exclusive games appear only to their owner. The list is sorted by name.
• Garanti Zepline is installed inactive and appears in betgaranti's list once Otto has activated it in production.
• Garanti Zepline returns "images": [] today, so the API supplies no lobby artwork for it. Ask your Otto contact for the artwork.

06Launching a game

Call this from your backend each time a player opens a game, and hand the returned launch_url to that player's browser.

Request

Optional means “leave the key out”. null and the empty string "" are not accepted for device, language or return_url: either returns 422. If your JSON serialiser writes absent values as null, drop those keys before you sign the body.

{
  "game_code": "48213",
  "player_id": "p-100245",
  "username": "lucky_ace",
  "currency": "TRY",
  "language": "en",
  "device": "MOBILE",
  "return_url": "https://casino.example/lobby"
}

Response

{
  "launch_url": "https://ottogaming.io/play/48213?token=<64-character token>",
  "session": {
    "id": 58231,
    "language": "en",
    "expires_at": "2026-10-07T20:00:00+00:00"
  },
  "game": {
    "code": "48213",
    "name": "Garanti Zepline"
  }
}

• Use launch_url exactly as returned. Otto chooses its host (https://ottogaming.io in this deployment); do not rebuild the URL from parts.
• session.id is the session_id that Otto's wallet calls carry for this player session.
• session.language echoes the normalised language you sent.
• session.expires_at is the first expiry, in UTC. It moves forward while the game is open (Sessions), so do not treat it as the end of the player's session.

What a launch does

1. Creates the player, or updates it: username and currency are overwritten on every launch.
2. Checks that the game is open to your brand and active, that it is enabled for your platform, and that it is available on Otto. A refusal returns 403 (Error reference) and leaves nothing behind: everything runs in one database transaction.
3. Ends the player's other sessions, except a session that still has a bet in play, which lives on until that bet settles.
4. Opens a new session that expires in 8 hours unless the game renews it, and returns its token, once, inside launch_url.

Sessions and the token

Embedding the game

<iframe
  src="LAUNCH_URL"
  title="Garanti Zepline"
  allow="fullscreen"
  style="border:0; width:100%; height:100%"></iframe>

• Otto sends no X-Frame-Options or frame-ancestors header, so any page may embed /play. If your own site sends a Content Security Policy, allow https://ottogaming.io in frame-src.
• Inside the iframe, the game opens a WebSocket to wss://ottogaming.io/app/…. That connection belongs to the game page, not to your site.
• allow="fullscreen" lets the game offer its fullscreen button where the browser supports it. Without it the button is hidden.
• When the game loads it calls /balance on your wallet to show the player's balance. If that call fails, the game shows the balance as unknown and reads it again a few times in the background.
• The game page is served with Referrer-Policy: strict-origin.

Exit and lobby

The game has no general exit button. return_url appears only on the session error screen, as a “Back to site” link that opens in the top window (target="_top"), for example after a session has expired or been replaced. Put your own close or back-to-lobby control around the iframe.

Languages

• The game is translated into English (en), Turkish (tr), Spanish (es) and Portuguese (pt).
• The region part is ignored: pt-BR and pt_BR both show Portuguese. Any other language shows English.
• Otto accepts any tag of up to 5 characters and stores it normalised. Longer tags fail with 422: send es, not es-419.
• Without a language, the game uses the language last used in that browser tab, otherwise English. Send language on every launch.

07Currencies and bet limits

Send currency as one of these 17 codes:

TRY USD EUR GBP ARS BOB BRL CLP COP CRC GTQ INR MXN PEN UYU VES ZAR

Garanti Zepline's limits are set in TRY (minimum 5, maximum 10,000) and scaled to other currencies with fixed product parities. The parities are not exchange rates and do not move with the market.

min bet = max(1, floor(5 × parity))
max bet = floor(10000 × parity)

• Stakes have up to 10 digits and up to 2 decimals. A stake outside the limits is refused with BET_OUT_OF_LIMITS before your wallet is called.
• A player can hold up to 2 bets per round.
• Payout = stake × cash-out multiplier, with the multiplier floored to 2 decimals and the result kept to 2 decimals.
• The win cap is 5,000× the stake, but crash points stop at 100.00×, so the largest possible payout is 100 × the stake: 1,000,000.00 TRY on a 10,000 TRY bet.

08Wallet callbacks

Your wallet holds the player's money. Otto reads the balance from it and calls it for every movement: taking a stake, paying a win, reversing a transaction.

Transport

How Otto reads your response

{
  "balance": "990.00",
  "reference": "op-904512"
}

{
  "code": "INSUFFICIENT_FUNDS",
  "message": "Insufficient funds."
}

Otto keeps your code and message for support. The player sees a translated notice for the outcome, not your message text. Otto reads reference but does not store it: reconcile on transaction_id.

Request fields

The field order in each body is fixed, and the signature covers those exact bytes.

/balance

Not a once-per-load call. Every session read by the game client asks your wallet for the balance:

• when the game loads or is reloaded;
• when the game renews its session (when 15 minutes or less remain);
• on every balance check: the game tab becomes visible again, the game window gets focus, or a bet card shows “not enough balance” or skips an automatic bet for a low balance. At most one check every 10 seconds per open game;
• while the balance is unknown (a failed read, or a money answer without balance): up to four more reads, after 3, 10, 30 and 60 seconds.

An active player can therefore cause about 6 calls a minute. Otto never sends more than 30 a minute for one session. Size and rate-limit /balance for that. A rejection or failure only means the game shows the balance as unknown.

{
  "player_id": "p-100245",
  "game_code": "48213",
  "session_id": 58231
}

{
  "balance": "1000.00"
}

/debit

Takes the stake when the player places a bet. Otto records the bet first, then calls you.

{"player_id":"p-100245","game_code":"48213","session_id":58231,"transaction_id":904512,"round_id":77120,"bet_id":310455,"amount":"10.00","currency":"TRY","type":"debit"}

{
  "balance": "990.00",
  "reference": "op-904512"
}

• Success: the bet is placed.
• Rejected (for example insufficient funds, a blocked player): the bet is discarded and the player sees a rejection. Do not move any money.
• Unknown: the bet is discarded, Otto sends a /rollback for this transaction_id straight away, and the game retries the bet as a new debit (automatic retries). The rollback can reach you even if the debit never did, and even before your wallet has finished applying the debit (see rollback).

/credit

Pays the win when the player cashes out during the flight. Same shape as the debit, with a new transaction_id, the same round_id and bet_id, and amount set to the payout. Example: a 10.00 stake cashed out at 2.35×.

{"player_id":"p-100245","game_code":"48213","session_id":58231,"transaction_id":904530,"round_id":77120,"bet_id":310455,"amount":"23.50","currency":"TRY","type":"credit"}

{
  "balance": "1013.50",
  "reference": "op-904530"
}

/rollback

Reverses an earlier debit or credit. transaction_id is the id of that original transaction; the body does not say whether it was a debit or a credit, so look up your own entry for that id.

• Original was a debit: refund the stake.
• Original was a credit: take the payout back.
• No entry for that id: answer 2xx as a no-op and keep a tombstone for that transaction_id (see below). This is normal; the original call may never have reached you.
• Already rolled back: answer 2xx as a no-op. The same rollback can arrive many times: inline during a cancel, then from the queue, where every answer that does not reach Otto as a 2xx is sent again.

Otto sends rollbacks in two ways:

{
  "player_id": "p-100245",
  "game_code": "48213",
  "session_id": 58231,
  "transaction_id": 904512,
  "round_id": 77120,
  "bet_id": 310455,
  "amount": "10.00",
  "currency": "TRY",
  "type": "rollback"
}

{
  "player_id": "p-100245",
  "game_code": "48213",
  "session_id": 58231,
  "transaction_id": 904512,
  "round_id": 77120,
  "bet_id": 310455,
  "amount": "10.00",
  "currency": "TRY",
  "type": "rollback",
  "reason": "Request completed with status 503."
}

• In both forms amount, round_id and bet_id are the original transaction's; they are left out when Otto cannot read the original. A queued rollback may also carry "session_id": null.
• Answer 2xx with JSON and the new balance. A rejected rollback during a cancel leaves the bet in play.
• Never reject a rollback. The queue retries 4xx answers too; it does not give up until its last attempt.

When each call happens

In addition, when a game request fails after a debit or credit, Otto queues a rollback for each debit or credit it could not complete. A cancel is the exception: its /rollback is never compensated. In the rare case that your wallet applied a cancel's rollback and Otto's request then failed, the bet stays in play on Otto's side, and a later /credit can arrive for a bet_id whose debit you already refunded. Accept that credit, and raise the case with Otto for reconciliation.

Automatic retries by the game

When a bet or a cash-out fails with an unknown outcome (“wallet unavailable”, a network error, a timeout or a server error) or finds another action still running, the game client repeats the player's action by itself, up to 3 more times, after 250, 750 and 1,500 ms. Otto rolled the failed attempt back, so each repeat reaches your wallet as a new debit or credit with a new transaction_id, and each failed attempt has its own queued rollback. One click can therefore produce up to 4 debits or credits, plus their rollbacks, within a few seconds.

• A repeated bet carries a new bet_id: the bet is created again.
• A repeated cash-out carries the same bet_id and a new amount: the multiplier is read again at each attempt, so the amount is usually higher.
• Never deduplicate, validate or reject on bet_id, or on a rule such as “one credit per bet”. Deduplicate on (transaction_id, type) only. Rejecting a valid repeated credit loses the player's win.

Idempotency and concurrency

• Deduplicate on (transaction_id, type). A repeat must not move money twice; answer it with the original result. A rollback reuses the original transaction's id with type: "rollback", so it never collides with the debit or credit it reverses.
• Otto never sends a debit or a credit twice under the same transaction_id. A repeat of the player's action is a new call with a new id (automatic retries), and the failed attempt is covered by its own rollback. Rollbacks are different: the same rollback can arrive many times.
• Otto runs one bet, cash-out or cancel at a time per player session, so two bets of one session never overlap. Calls for the same player still overlap in two ways: queued rollbacks run on Otto's background workers, outside that order, and typically overlap with the game's automatic retry a quarter of a second later; and an older session whose bet is still in play can overlap with a new session. Make balance changes atomic per player (a row lock or equivalent).

Amounts and precision

• Every amount is a string with exactly 2 decimals. Use decimal arithmetic, never binary floating point.
• Return balance on every 2xx, for /balance, /debit, /credit and /rollback alike, as a string with 2 decimals, for example "1013.50". A JSON number is accepted too; Otto normalises it to 2 decimals.
• Without a numeric balance (missing, null, or formatted like "1,000.00"), the call still succeeds, but the game marks the balance unknown and reads it again through /balance after 3, 10, 30 and 60 seconds: up to four extra signed calls to your wallet, each of which also renews the player's session.
• currency is the player's currency from the launch.

The rollback queue

• The first attempt starts at once, usually within a second of the failure. Up to 10 attempts in all; between them Otto waits 10 s, 30 s, 60 s, 120 s, 180 s, then 300 s four times. The waits add up to about 27 minutes.
• Each attempt allows 15 seconds and tries twice on a connection error or a 5xx. A 4xx is retried on the next attempt as well, and so is a 2xx that did not reach Otto in time.
• The same rollback can therefore reach you up to about 20 times, besides the inline try during a cancel. With slow answers the last attempt can start more than 30 minutes after the failure, and later still if Otto's queue is running behind: do not close your window at 27 minutes.
• Any 2xx completes the rollback; JSON is not required here.
• There is at most one rollback per original transaction_id, however many times it is delivered.
• If the last attempt fails, Otto stops sending it, marks it failed and reconciles the transaction with you by hand.

09Round lifecycle and timing

Each game runs one live round at a time, shared by every brand that carries the game. The engine advances in 250 ms ticks.

The multiplier

multiplier(t) = floor(1.06^t × 100) / 100        t = seconds since takeoff
flight time   = ln(crash point) / ln(1.06)       seconds

Timing rules

• A bet or a cancel is accepted only while the round is in BETTING and before its betting end time. Otto checks this twice, the second time under a database lock, so a request that arrives at the boundary is either fully in or refused: a bet with BETTING_CLOSED, a cancel with BET_NOT_CANCELLABLE.
• A cash-out is accepted only while the round is RUNNING and before the crash time. Otherwise it is refused with TOO_LATE or ROUND_NOT_RUNNING.
• A full cycle takes 6 s of betting, the flight, and 3 s: about 9 s for a crash at 1.00× and about 88 s for 100.00×.

10Provably fair

Each crash point is fixed by a secret seed that Otto commits to before any bet is placed, combined with a seed that comes from the bets themselves. After the crash, the secret is revealed and anyone can recompute the result.

1. Commit. When a round is created, Otto draws server_seed (32 random bytes, hex) and publishes server_seed_hash = sha256(server_seed) as betting starts.
2. Client seed. When betting closes, the round's client_seed is sha256("round:<round_id>|" + the entries "<bet_id>:<session_id>:<bet client seed>" joined with "|", in bet id order). A player may attach their own client seed of up to 255 characters to a bet; otherwise that part is empty. A round without bets gets a random client seed.
3. Crash point. Computed from server_seed, client_seed, the round's nonce (its sequence number) and the game's RTP, as below.
4. Reveal. After the crash, server_seed is revealed. client_seed and nonce are sent in the crash event to every open game.

assert sha256_hex(server_seed) == server_seed_hash   // hash of the 64-character hex text

// The key is server_seed as text (its 64 hex characters), not the decoded bytes.
// Arithmetic below is IEEE 754 double precision, as in JavaScript.
digest = hmac_sha256_hex(key = server_seed, data = client_seed + ":" + nonce)
h      = parse_int(digest[0:13], base 16)          // first 13 hex characters = 52 bits
m      = max(1, rtp × 2^52 / (2^52 − h))            // rtp = 0.97 for Garanti Zepline
m      = min(max(m, 1.00), 100.00)                  // clamp to the game's range
crash  = floor(m × 100) / 100

11Live bets and privacy

Garanti Zepline shows players a live list of the current round's bets inside the game.

• What it shows: the top 20 bets of the current round by stake, plus round totals, refreshed about once a second.
• Whose bets: bets from every brand in the round. Rounds are shared, so the list covers every brand that carries the game, Otto's test brand included.
• Privacy: usernames are masked. The list carries no player ids, no currencies and no balances. Stakes are converted to the base currency, TRY, before they are ranked.
• The masked name is derived from the username you send at launch and shows at most its first two and last two characters, for example lucky_ace as lu***ce. Send a nickname, never an e-mail address or a real name.

12Error reference

Operator API

Errors that Otto's application returns on /api/* are JSON with a message. Validation errors (422) also carry an errors object that lists the messages for each failing field.

Your wallet's answers

See How Otto reads your response. In short: a 2xx with JSON or an empty body is a success, a 4xx with JSON or an empty body is a rejection, everything else is unknown and leads to a rollback. The code you return is free text for Otto; the reference wallet uses INSUFFICIENT_FUNDS and UNAUTHORIZED.

Game client codes

The game client talks to Otto's player API, not to you. You will meet these codes only in support conversations. Responses use {"data": …, "server_time_ms": …} or {"error": {"code", "message"}, "server_time_ms": …}.

The player API can also answer 401 (session expired or replaced: launch again), 422 (validation) and 429 “Too Many Attempts.”.

13Rate limits and health

Over the limit, Otto answers 429 “Too Many Attempts.” with a Retry-After header in seconds; wait that long before you retry. Errors from the proxies in front of Otto are described under Error reference.

Health: GET https://ottogaming.io/up answers 200 while the application is up. It is a liveness check only and does not exercise wallets or games.

14Testing checklist

Work through these before asking for go-live. The boxes can be ticked in your browser; they are not sent anywhere.

Otto's reference wallet can simulate the failure cases on demand (slow answers, timeouts, server errors, insufficient funds, refused rollbacks, broken signatures). If you want to see the expected behaviour before testing your own wallet, ask your Otto contact for a demonstration on otto-test.

15Go-live checklist

16Support and diagnostics

When you contact Otto about a transaction, include:

• transaction_id, round_id, bet_id and player_id;
• the time in UTC, to the second;
• the HTTP status and body your wallet returned.

For every wallet call, Otto logs the endpoint, the HTTP status, the outcome and the duration. Your response body is kept only when the HTTP status was not 2xx or the call took 1 second or more, up to 5,000 characters. A fast 2xx is logged without its body even when Otto could not read it (for example an HTML page from a firewall), so keep your own log of what your wallet answered. Request bodies and headers are never stored. These logs are kept for 14 days, so report problems within that window.

17Changelog

The operator API has no version number in its paths. Changes to this contract are recorded here.