Event Feed

Unibo: Consumer

Introduction

By integrating with the Unibo Consumer, you'll be able to send events that will be processed by our system. This is a crucial step towards connecting your application to ours, and it's essential to get this part right.
The Unibo Consumer service is specifically designed to receive critical events in real-time, such as:
  • Bets: Player A bets for 0.20 EUR (cash) in Book of Ra at 2024-10-08T08:46:36.548362+00:00 (round_id: 120).
  • Wins: Player A wins 10 EUR (cash) in Book of Ra at 2024-10-08T08:46:37.548362+00:00 (round_id: 120, the bet above).
  • Deposits: Player A deposited 20 EUR
Additionally, the Unibo Consumer may also receive optional updates to:
  • Player: Player A registered at 2024-10-08T08:46:36.548362+00:00 (country, tags, currency to payout prizes with, etc.)
  • Game: There's a new Game 1 (Book of Ra) with category video-slots from NOVOMATIC (themes, has_freespins, etc.)
Both Players and Games might also be exposed in a different way, Unibo needs it to properly target our campaigns based on segmentation configured by Casino Operators.
Read more about it in  🗒️⁠⁠Meta Data⁠  section.

Technical documentation

For the most up-to-date and detailed information please refer directly to the service itself at  https://consumer.unibo.io . It provides human-readable documentation in the form of a Swagger interface. For convenience, we also provide an OpenAPI specification ( openapi.json ).
The primary endpoint for sending events is:
  • POST /api/v1/events
Please note that this endpoint is specifically designed to receive batches of events in JSON format. We recommend using our interactive documentation as your primary source for understanding the API's requirements and capabilities.
There's few more topics worth highlighting:

Idempotency and timestamps

To ensure accurate processing of events, please ensure the following:
  • Idempotency : Our service deduplicates events based on their unique unique_id field. Make sure this field is correctly populated with a unique identifier for each event. This prevents duplicates if there's some kind of network connection issue, so you can easily retry sending us a whole batch of events, even if we managed to receive it already or just processed half and crashed for some reason.
  • Correct timestamp : Attach a timestamp to each event itself that reflects when the event took place. For example, if sending an event related to a bet being made, include the timestamp of when the bet was actually placed. This is crucial for processing our campaigns and also for latency monitoring. We get alerted when the events we receive are delayed and we can act on it accordingly.
For instance:
{
  "data": {
    "unique_id": "9cd823d3fe", // deduplication/idempotency
    "timestamp": "2024-12-12T12:17:53.988Z", // Timestamp of when the bet was made
    "player_id": "StQ-1",
    "game_id": "GD8",
    "round_id": "f7ltidMBAwexDojlJBY",
    "amount": 0.5,
    "currency": "EUR",
    "is_win": false,
    "is_bonus": false
  },
  "event": "gameround"
}

Sending events with low latency in batches

To ensure timely processing of events, it's essential to send them to our service with minimal delay. We recommend collecting events in batches based on time and event-count:
  • Time-Based Batching:
  • Collect events for up to 500ms before sending the batch.
  • Event-Count-Based Batching:
  • Collect up to 10,000 events before sending the batch. If more than 10,000 events are collected within the 500ms time frame, the excess events will be sent as separate batches.
This approach ensures that events are not delayed unnecessarily while also preventing an excessive number of small batches from being sent.

Additional Considerations

If the tenant (both your infrastructure and casino itself) is located in a different geographical place than the main instance (Ireland), we can spin up an infrastructure instance there to reduce latency. Please reach out to us for more information on this aspect of our services.