Runtime expectations

The connector translates your protocol, but the responsibilities on this page belong to your game server no matter what shape the protocol takes. They are the runtime half of the contract: what arrives at your systems, what must leave them, and how both sides stay fast and safe.

Two directions of traffic

Direction	Calls	Purpose
Aggregator.gg calls you	Launch and session calls	Create a game session and hand back its launch URL
You call Aggregator.gg	Bet, win, and refund legs	Settle money for the rounds your games play

Everything else on this page details one of these two directions.

Launch and session calls

When an operator creates a session, the platform calls your game API to create it and expects two things back: a session identifier and a working launch URL. That expectation is strict, and failures surface to operators under named codes from the error reference:

• A launch response without a URL fails as E1055 provider_launch_no_url: the provider returned a response but no launch URL.
• A URL that fails safety validation fails as E1056 provider_launch_unsafe_url: the provider returned a URL that failed safety validation. Return a well-formed HTTPS URL that opens the game directly.
• Launch calls authenticate: rejected credentials surface as E1050, and an answer that does not arrive in time surfaces as E1053. Answer launch calls quickly and validate auth without ceremony.

Agree launch-token lifetime and reuse rules in your connector contract. Treat URLs as session credentials and keep them out of logs; the operator API does not establish a universal single-use rule for every provider.

Bet and win to Aggregator.gg

Money settles because your server sends it. Every bet, win, and refund leg is a call from your systems to Aggregator.gg, and the platform verifies the signature on every one of them before anything moves.

The operator-facing wallet callback uses HMAC-SHA256 over the raw body. Provider authentication, signing, canonicalization and replay rules are specific to the agreed connector protocol. Confirm them with the integration team; do not copy the operator signature verifier into a provider protocol without that agreement.

• Amounts are integers in minor units. On normalized operator wallet callbacks each amount is an integer in the currency’s minor units: 500 means 5.00 EUR. There are no floats and no major-unit fields. If your protocol quotes amounts differently, the unit mapping is the first thing the connector contract pins down, in writing, before any money flows.
• Transaction identifiers are stable. Each leg carries a transaction identifier that never changes across retries. The operator side combines it with provider and trusted integration/organization context, so a retry that mints a new one is not a retry, it is a duplicate charge.
• A declined bet is a normal outcome. A bet the player cannot afford is declined and not placed; your game shows the player a balance problem, not a crash, and sends no win leg for a round that never happened.
• Close every round. Follow the agreed connector’s final-round signal. Some zero cash legs settle internally, while free-round zero wins can still reach the wallet. Do not suppress finality or free-round evidence using a blanket zero-amount rule.

Stability and latency

The money path is synchronous: the player is looking at a spinning reel while your bet call travels to the platform and on to the operator’s wallet. Operators are held to a 5 second response budget with an aim of under 2 seconds at p95, and the whole path only works when each hop spends a small share of it.

What that asks of your side, qualitatively:

• Answer fast, always. Launch answers and money-call handling should be quick enough that the platform’s and operator’s budgets are spent on the network, not on waiting for you.
• Retry transient failures with backoff, same identifier. A failed money call is retried against the platform with the same transaction identifier until it lands or is investigated; it is never silently dropped and never re-minted.
• Degrade loudly. When your side is unhealthy, failing fast beats queueing quietly: a timed-out launch is a recoverable error, a launch that hangs is a stuck player.

Egress IPs and allowlisting

Confirm the active egress list with the cabinet or support before changing your allowlist. Providers validate against staging before go-live. Deployment configuration can override these source defaults:

Environment	Egress IP (IPv4)
Production	116.202.36.242
Staging	46.224.211.29

Recheck the active list when configuration changes; the defaults are not a permanent or exhaustive live network contract. The allowlist is an additional network control, never a replacement for verifying signatures: signature verification stays mandatory on both sides regardless of source IP. The same table, with the operator-side guidance, lives in Environments.

When a provider is suspended

Suspension is a platform decision, and new launches are refused once the updated provider state is observed by the serving path, and operators see E1003 provider_suspended with the instruction to contact support. Nothing on your side needs special handling beyond the obvious: stop assuming new launches will succeed; already active sessions and outstanding settlement need separate operational handling, and the conversation about why happens with our team through the channel you already use, not through the API.