> For the complete documentation index, see [llms.txt](https://docs.odds88.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.odds88.io/odds88-client-api/odds88-feeds/metadata-feed.md).

# Metadata Feed

```
/feed/metadata?revision={lastUpdatedTime}
```

`revision` - Unix time stamp seconds of the moment, from which you want to get recovery. Can be `0` for initial connection. Max value - 3 days from current time.

The feed contains metadata updates for events.

{% hint style="warning" %}
The stream connection is rate-limited and there can be only 1 active connection at a time.
{% endhint %}

Rate limit configuration is the following:

* Connection attempt without revision - 5 connections per 30 minutes
* Connection attempt with too small revision - 5 connections per 30 minutes
* Connection attempt with proper revision - 5 connections per 5 minutes

**Two additional** rate limits apply to all feeds that use a timestamp as the `revision` parameter. These limits apply specifically to **recovery requests made on reconnection**.

#### 1. Large recoveries (timestamp older than 1 hour)

If a client reconnects and requests recovery from a timestamp more than **1 hour** in the past, the request is subject to a hard limit:

> **Limit:** 5 requests per 30 minutes

#### 2. Small recoveries (timestamp within the last 1 hour)

If a client reconnects and requests recovery from a timestamp within the last hour, the length of the requested recovery period is added to a **leaking bucket**:

| Parameter       | Value                                       |
| --------------- | ------------------------------------------- |
| Bucket capacity | 1 hour (3,600 seconds)                      |
| Leak rate       | 4 seconds drained per 1 second of real time |

Once the bucket is full, further recovery requests are blocked until enough has drained.

#### Practical examples

**✅ Within limits** A client that drops and reconnects every **5 minutes** requesting a **10-minute** recovery will operate well under the limit and notice no impact.

**❌ Will be blocked** A client that reconnects every **5 minutes** requesting a **30-minute** recovery will fill the bucket faster than it can drain, and will eventually be blocked.

#### Summary

Frequent reconnects are fine — as long as the requested recovery window stays **proportionate to the reconnect interval**.

## Message Format