Technical Integration

Welcome! This guide explains how to integrate with LSports Engage Hyper LiveScore Feed and its complementary Fixtures Feed.

---

Access Credentials

Obtain the following from your Customer Success Manager (CSM):

• Username

• Password

• CustomerPackageId

These credentials are used for both RabbitMQ vhosts (Fixtures and Incidents) and all Customers API endpoints.

---

Critical: Steps 1 & 2 Must Be Performed Immediately

After receiving credentials, you must:

1. Establish your RabbitMQ consumers

2. Activate your package

These steps should be completed back-to-back.

If a queue accumulates 50,000 unprocessed messages, it will automatically deactivate. High-volume sports can reach this limit very quickly.

If deactivation occurs:

• Use the Get Package Status endpoint to verify the queue state

• Reactivate using the Activate Package endpoint (Customers API)

Failure to consume messages in time will result in interrupted delivery until the package is reactivated.

---

Step 1 – Establish RabbitMQ Connections

Host: hyper-livescore.lsports.eu Port: 5671 Protocol: AMQP 0-9-1 over TLS Encoding: UTF-8 JSON

Open two separate AMQP connections (one per vhost):

• Fixtures - For fixture metadata

• Incidents - For livescore incidents

Queue name (both vhosts): _{CustomerPackageId}_

Do not begin consuming until the package is activated (next step).

---

Step 2 – Activate Your Package

Call the Activate Package endpoint via the Customers API. This action:

• Provisions your queues

• Makes them available for consumption

• Enables message publishing to your vhosts

If your queue was deactivated due to 50,000 unprocessed messages, call Get Package Status first, then call Activate Package again.

---

Step 3 – Start Your Consumers

Once activated, start consuming from both:

• Fixtures queue

• Incidents queue

You should now begin receiving live messages.

---

Step 4 – Validate Message Flow

Before going live, confirm you are receiving:

• Fixture messages

• All expected Incident kinds

Ensure your system properly handles incident types including Score, Period, FixtureStatus, VAR lifecycle, and StatusDescription.

---

Step 5 – Trigger Initial Fixtures Snapshot (One-Time Only)

Call the Trigger Snapshot endpoint via the Customers API.

Fixtures are delta-based only — you will only receive updates when something changes. The snapshot ensures your local store is fully seeded with all upcoming fixtures so incidents can be properly correlated. This is required only during initial setup.

---

Step 6 – Store Fixtures Locally

Persist fixture messages locally using body.fixtureId. Your fixture store is required for incident correlation, display logic, and state tracking.

---

Step 7 – Correlate Incidents

For every incoming Incident message, join it with your stored fixture using body.fixtureId. Once correlation is working — your integration is fully operational.

┌─────────────────┐     ┌─────────────────┐
│  Fixtures Feed  │────▶│  Your Fixtures  │
│   (vhost)       │     │     Store       │
└─────────────────┘     └────────┬────────┘
                                 │
                                 │ Join by fixtureId
                                 ▼
┌─────────────────┐     ┌─────────────────┐
│  Incidents Feed │────▶│  Live Updates   │
│   (vhost)       │     │  (with context) │
└─────────────────┘     └─────────────────┘

---

Operational Best Practices

• Always keep consumers running

• Monitor queue depth continuously

• Never allow queues to approach 50,000 pending messages

• Implement auto-recovery logic

---

Next Steps

• Fixture Message Structure — Understand fixture data format

• Incidents Message Structure — Understand incident data format

• Code Samples — Implementation examples