How to send player events from your gaming platform to Revvvs.

Server-to-Server Integration

Revvvs uses a server-to-server (S2S) event model. Your gaming platform's backend sends player lifecycle events directly to our API: no client-side JavaScript, no cookies, no pixels.

This is the most reliable tracking method for iGaming because it doesn't depend on the player's browser and can't be blocked by ad blockers or privacy tools.

Architecture overview#

Your Gaming Platform          Revvvs
┌──────────────────┐          ┌─────────────────┐
│                  │  events  │                 │
│  Player action   │ ──────→  │  Event API      │
│  (register,      │  (S2S)   │  /api/v1/events │
│   deposit, etc.) │          │                 │
│                  │          │  Attribution ──→ Commission ──→ Affiliate Portal
└──────────────────┘          └─────────────────┘

What to send#

Your platform sends events as they happen in your system. The core events are:

There are additional event types for deeper analytics. See the Event Reference for the complete list.

Important: NGR and commission data#

For RevShare commission calculation, send ngr_update events with the aggregated NGR figure for a player. You do not need to send individual bet-level data. Revvvs calculates RevShare from the NGR total you provide.

For example, if a player has generated EUR 500 in NGR this month, send:

{
  "event_type": "ngr_update",
  "event_time": "2026-03-15T23:59:00Z",
  "brand_id": "your-brand-uuid",
  "player_external_ref": "player_001",
  "idempotency_key": "ngr_player_001_20260315",
  "currency": "EUR",
  "amount": 500.00
}

The wager_placed and wager_settled event types are optional. They provide enrichment data for product-level analytics (e.g., casino vs sportsbook breakdown) but are not required for commission calculation.

Single event vs batch#

Single event:

POST /api/v1/events
Content-Type: application/json
X-API-Key: rv_your_key

{
  "event_type": "registration",
  "event_time": "2026-03-15T10:00:00Z",
  "brand_id": "your-brand-uuid",
  "player_external_ref": "player_001",
  "idempotency_key": "reg_player_001_20260315"
}

Batch (up to 100 events):

{
  "events": [
    {
      "event_type": "registration",
      "event_time": "2026-03-15T10:00:00Z",
      "brand_id": "your-brand-uuid",
      "player_external_ref": "player_001",
      "idempotency_key": "reg_player_001"
    },
    {
      "event_type": "first_deposit",
      "event_time": "2026-03-15T10:30:00Z",
      "brand_id": "your-brand-uuid",
      "player_external_ref": "player_001",
      "idempotency_key": "ftd_player_001",
      "currency": "EUR",
      "amount": 50.00
    }
  ]
}

Batch responses include a summary and per-event status:

{
  "summary": { "total": 2, "accepted": 2, "duplicates": 0, "errors": 0 },
  "results": [
    { "event_id": "...", "idempotency_key": "reg_player_001", "status": "accepted" },
    { "event_id": "...", "idempotency_key": "ftd_player_001", "status": "accepted" }
  ]
}

Idempotency#

Every event requires an idempotency_key: a unique string that identifies this specific event. If you send the same key twice, the second request returns "status": "duplicate" without creating a duplicate record.

This means your integration can safely retry failed requests without risking double-counted commissions.

Best practices for idempotency keys:

• Use a deterministic format: {event_type}_{player_ref}_{date} or {event_type}_{your_internal_event_id}
• Keys must be unique per operator. Two different operators can use the same key.
• Keys are permanent. A used key can never be reused, even if the original event is old.

Click ID passthrough#

When a player arrives at your site via an affiliate tracking link, the URL contains a click_id parameter:

https://your-casino.com/welcome?click_id=abc-123-def&sub1=google&sub2=uk

Capture this click_id and include it in the player's registration event:

{
  "event_type": "registration",
  "event_time": "2026-03-15T10:00:00Z",
  "brand_id": "your-brand-uuid",
  "player_external_ref": "player_001",
  "idempotency_key": "reg_player_001",
  "click_id": "abc-123-def",
  "country": "GB"
}

The click_id enables direct attribution: Revvvs matches the player to the exact click and affiliate immediately. Without it, Revvvs falls back to last-click attribution within the configured window (typically 30 days), which is less precise.

Recommendation: Always capture and send the click_id. Store it in your database alongside the player record so it's available for the registration event.