Connection Setup

Connect to RabbitMQ and configure how you consume messages

LSports uses RabbitMQ for real-time data delivery. This is where connection quality gets decided: how you consume and route messages shapes how your feed performs under real load.

Step 3: Establish a Connection

There are two ways to connect: through an LSports SDK (recommended), or with your own RabbitMQ implementation.

Recommended: connect with an SDK

The SDKs handle connection and consumption setup for you, and provide a simplified Snapshot API interface for recovery. They are the fastest way to a stable feed:

• SDK Overview: capabilities and configuration
• .NET SDK
• Java SDK
• Node.js SDK

The SDKs work with JSON messages only; you can check or update your package's message format on the Package Configuration page. If your stack is covered by an SDK, start there and continue to Reliability & Recovery; the recovery sequence described there still applies when using an SDK. The rest of this page shows the underlying RabbitMQ setup for stacks without an SDK.

Alternative: connect with your own RabbitMQ consumer

Connection details

Parameter	InPlay	PreMatch
Host	stm-inplay.lsports.eu	stm-prematch.lsports.eu
Virtual Host	StmInPlay	StmPreMatch

Parameter	Value
Port	5672
Queue	_YOUR_PACKAGE_ID_ (e.g. _102030_)
Protocol	AMQP 0.9.1

Connection setup (example, C#)

// 1. Create a connection
IConnection connection = _connectionFactory.CreateConnection();

// 2. Create a model
IModel model = connection.CreateModel();

// 3. Configure Quality of Service
model.BasicQos(prefetchSize: 0, prefetchCount: 100, global: false);

// 4. Consume messages
EventingBasicConsumer consumer = new EventingBasicConsumer(model);
consumer.Received += (sender, eventArgs) => {
    // Deserialize message, then handle it
};

// 5. Start consumption (replace with your Package ID)
model.BasicConsume(queue: "_YOUR_PACKAGE_ID_", noAck: true, consumer: consumer);

The snippet above is an excerpt showing the consumption sequence, not a complete runnable program. Full runnable samples in all supported languages are in Code Samples. For the full connection factory setup, see Connection & Consumption Setup.

Consumption best practices

• Use no-ack or auto-ack with a prefetch count around 100 for high-throughput consumption. Manual ack tends to create bottlenecks.
• Separate consumption from processing: keep a thin, fast consumer layer, and route messages to separate processing workers for business logic.
• Split by message type: route market updates, live scores, and heartbeats to different workers rather than one handler.
• Use RMQ headers (FixtureId, MarketId, MessageType, MessageSequence, timestamp_in_ms) for routing and to filter unwanted fixtures and markets before full deserialization. See RabbitMQ Header for the full list.

API rate limits

These are general defaults; endpoint-specific limits take precedence where documented.

• Stay within 5 concurrent API requests at a time.
• Limit repeat calls to the same request to once every 5 seconds.
• As a general rule, avoid more than 1 API call per second to the same endpoint.
• The Snapshot API has its own request limits (filtered vs. full requests): see Snapshot API limitations.

Once your consumer is connected and routing correctly, the practices in Reliability & Recovery are what keep it that way once you're live.

---

Next: Reliability & Recovery