> For the complete documentation index, see [llms.txt](https://docs.lsports.eu/u/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lsports.eu/u/trade/integration/connection-setup.md).

# Connection Setup

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](/u/trade/integration/sdk/sdk-overview.md): capabilities and configuration
* [.NET SDK](/u/trade/integration/sdk/sdk-installation-guide-.net.md)
* [Java SDK](/u/trade/integration/sdk/sdk-installation-guide-java.md)
* [Node.js SDK](/u/trade/integration/sdk/sdk-installation-guide-nodejs.md)

The SDKs work with JSON messages only; you can check or update your package's message format on the [Package Configuration](/u/trade/user-guide/configuration/package.md#general) page. If your stack is covered by an SDK, start there and continue to [Reliability & Recovery](/u/trade/integration/reliability-and-recovery.md); 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#)

```csharp
// 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](/u/trade/integration/code-samples.md). For the full connection factory setup, see [Connection & Consumption Setup](/u/trade/integration/rmq-connection/connection-and-consumption-setup.md).

### 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](/u/trade/integration/message-structure/rabbitmq-header.md) 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](/u/trade/integration/apis/snapshot.md).

{% hint style="info" %}
Once your consumer is connected and routing correctly, the practices in [Reliability & Recovery](/u/trade/integration/reliability-and-recovery.md) are what keep it that way once you're live.
{% endhint %}

***

Next: [Reliability & Recovery](/u/trade/integration/reliability-and-recovery.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.lsports.eu/u/trade/integration/connection-setup.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.