> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.solvimon.com/platform-guides/for-developers/rate-limits/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.solvimon.com/_mcp/server.

# Rate limits

This page describes how much usage data you can send to the Event API and what happens when you exceed the limit. Read it before you size your ingestion pipeline or plan a backfill.

---

## Default limit

| API                                                                       | Environment | Default limit            | Scope        |
| ------------------------------------------------------------------------- | ----------- | ------------------------ | ------------ |
| Event ingestion (`POST /v1/events/ingest`, `POST /v1/events/ingest-list`) | Live        | 10,000 events per second | Per platform |
| Event ingestion (`POST /v1/events/ingest`, `POST /v1/events/ingest-list`) | Test        | 1,000 events per second  | Per platform |

The limit counts events, not requests. You can reach it with single-event requests: there is no need to batch events to stay within the limit. Batching through `POST /v1/events/ingest-list` is supported when it suits your pipeline; each event in a batch counts towards the limit.

A batch request holds at most (by default) 50 events. Larger batches are rejected; split them into several requests.

Test and live are separate environments with separate limits. Load testing in test does not consume your live capacity, but at 1,000 events per second it cannot reproduce live throughput either.

> **Note**
>
> Need more than 10,000 events per second sustained in live, or planning a large backfill? Contact Solvimon support with your expected peak and sustained volumes. Limits are raised per platform.

## Exceeding the limit

When you send events faster than your limit, the API answers with `429 Too Many Requests` and a `Retry-After` header that gives the number of seconds to wait. Events in a rejected request are not stored.

**`Throttled response`**

```http Throttled response
HTTP/1.1 429 Too Many Requests
Retry-After: 1
Content-Type: application/json
```

A throttled request is safe to resend unchanged. Event idempotency is based on the event `reference`, so a resent event is never counted twice. See [Idempotency](/platform-guides/for-developers/idempotency).

## Recommended client behaviour

* Store each event locally before you send it, and only mark it as delivered after a `201 Created`.
* On a `429`, wait for the number of seconds in `Retry-After`, then resend. Without the header, back off exponentially starting at one second.
* Spread traffic over time where you can. Sustained throughput below the limit is more reliable than short bursts at the limit.
* Log the `X-REQUEST-ID` response header on errors so Solvimon support can trace a request.

## Example

A single event per request, which is the recommended pattern:

**`Ingest one usage event`**

```bash Ingest one usage event
curl -X POST https://test.api.solvimon.com/v1/events/ingest \
  -H "X-API-KEY: <apiKey>" \
  -H "Content-Type: application/json" \
  -d '{
    "reference": "evt_00124578951",
    "meter_reference": "api_calls",
    "customer_reference": "acme-corp",
    "timestamp": "2026-10-06T10:50:00+02:00",
    "meter_values": [
      { "reference": "call_count", "number": "1" }
    ]
  }'
```

See [Event ingestion API](/platform-guides/meter-and-event-design/usage-events/event-ingestion-api) for the full event format and best practices.

---