TwinToneTwinToneAPI Docs

Get started

iGaming guide

How to run casino-style AI-hosted streams on the TwinTone API. This guide covers the igaming vertical, what it changes, and how to integrate it responsibly.


What vertical: "igaming" means

When you start a stream you can pass a vertical field:

{ "creator_id": "dealer-eva", "product_name": "Evening Blackjack", "platform": "youtube", "vertical": "igaming" }

Two things change versus the default live-commerce vertical:

live-commerce (default)igaming
RateTier rate ($0.50 → $0.15 / min)Tier rate + $0.10 / min
BillingPer second, from liveendedSame, on top of the tier rate
Allowed contentProduct demos, live sellingCasino-style lobbies & promotions

Brand vertical lock. Each brand is assigned a single vertical. If the vertical you send doesn't match your brand's vertical, the request fails with 403 { "error": { "code": "vertical_mismatch" } } — so an iGaming brand cannot accidentally (or intentionally) run streams at the cheaper rate, and a live-commerce brand cannot run igaming streams at all. You can simply omit the field and your brand's vertical is used.

The surcharge exists because iGaming streams carry higher moderation, compliance, and platform-risk overhead. It applies to every streamed minute, on top of the tier rate — see API pricing.


Casino livestream use case

The most common pattern is a dealer-style host for game lobbies and promotions: an AI avatar that carries the room between gameplay, announces promos, and keeps viewers engaged — not an automated betting system.

Typical flows:

  • Game lobbies — a host avatar welcomes players, explains the game format, and moderates the room during tournament-style sessions.
  • Promos & giveaways — scheduled hosts announcing time-limited offers, bonus drops, or event schedules.
  • Recap & pre-show — "last night's winners" segments between live game sessions.

The API works exactly as described in Streams — start a stream with vertical: "igaming", watch for stream.started, then stream.ended via Webhooks, and pull engagement numbers from Analytics.

Platform notes

  • Supported platforms are the same as live-commerce: youtube, tiktok, twitch, kick, facebook, instagram.
  • Some platforms have specific policies for gambling-adjacent content — verify that your content type (and the jurisdiction it's shown in) is permitted on each platform you target before going live.
  • Keep stream titles and product_name descriptive of the actual content — vague or misleading labels are the fastest way to get flagged.

Responsible-gambling compliance pointers

These are general integration pointers, not legal advice. Compliance requirements vary by jurisdiction, platform, and your license. Work with your legal team before launching.

Treat every stream as potentially visible in any jurisdiction:

  • Age gates. Verify the age of end viewers before they can interact with your stream or follow any call-to-action. Don't rely on platform settings alone — gate at your app layer where you control it.
  • Jurisdiction & ToS. Your content and offers must comply with the laws and licensing of every jurisdiction you stream into, and with each platform's terms of service. When in doubt, geo-restrict the stream.
  • No real-money calls to action from the host avatar. Keep the avatar in an informational/entertainment role; route any wagering flow through your own age-verified, licensed surfaces.
  • Self-exclusion and limits. If your product supports player limits or self-exclusion, reflect them in what the stream promotes — never market to excluded users.
  • Clear labeling. If a stream is promotional or sponsored, say so plainly on stream and in the description.

Test-key workflow for casino integration teams

Use a test key (tt_test_…) for all development — it simulates the full stream lifecycle with no agent dispatch and no billing, so your integration team can iterate without spending credits or touching production platforms.

Recommended flow:

  1. Create a test key in Billing → API keys with scopes streams:write, streams:read, webhooks:write, analytics:read.
  2. Start a stream with vertical: "igaming" (or omit it — the brand vertical is applied automatically).
  3. Verify the 403 path too — if your brand is locked to live-commerce, confirm that sending "vertical": "igaming" returns 403 vertical_mismatch. Your code should treat that as a configuration error, not a retryable failure.
  4. Test webhook delivery locally with ngrok http 3000 and register the public URL — see Testing locally. Confirm signature verification and the stream.started / stream.ended / stream.error transitions.
  5. Swap to a live key (tt_live_…) only for the final smoke test before launch. Test and live responses are identical, so this is the entire go-live step.
  6. Confirm pricing expectations with your team: with a test key nothing is billed; the first live minutes land at the iGaming rate (tier rate + $0.10/min) from your credit wallet.

Do not share a live key with the integration team during development — anyone holding a live key can start billable streams. A test key costs nothing and behaves identically.

Was this page helpful?