> ## Documentation Index
> Fetch the complete documentation index at: https://bundleup.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Requests & Usage

> What a request is, what gets logged about it, and how requests count toward your plan.

A **request** is one call your backend makes through BundleUp using a connection: a Proxy call, a Unified API call, or an MCP message. Requests are the unit BundleUp logs, rate-limits and bills.

## What gets logged

Every request is logged after the response is sent, so logging adds no latency. Each log entry records:

| Field | Example |
| - | - |
| Source | `PROXY`, `UNIFY` or `MCP` |
| Method and URL | `GET https://api.github.com/user/repos` |
| Status code | `200` |
| Duration | `184 ms` |
| Connection | The connection ID used |
| Integration | The integration the connection belongs to |
| API key | Which of your keys made the call |
| Error code | For example `rate_limit_exceeded`, when BundleUp rejected or failed the request |
| Time | When the request was made |

For requests that reach the provider, the URL logged is the **provider’s** URL that BundleUp called. For requests BundleUp rejected before that, it’s the BundleUp URL you called.

**Request and response bodies are never logged.** Neither are headers. What your users’ data contains stays out of BundleUp’s records.

You can browse and filter logs in the dashboard under **Logs**. See [Logs & observability](/docs/guides/operations/logs).

## Log retention

| Plan | Logs kept for |
| - | - |
| Free | 1 day |
| Pro | 14 days |

Older entries are deleted automatically. If you need a longer history, keep your own records of the calls you make.

## What counts toward usage

Your plan includes a number of requests per month (see [Pricing](/docs/platform/pricing)). A request counts each time BundleUp logs one, which includes:

* **Every Proxy, Unified API and MCP request**, successful or not.
* **Every retry attempt.** If BundleUp retries a `GET` twice before it succeeds, that’s three requests. Each attempt is a real call to the provider.
* **Every MCP message.** `initialize`, `tools/list`, `tools/call` and notifications each count as one.
* **Requests BundleUp rejects after identifying your workspace**, such as an invalid connection ID (`400`) or a rate-limited request (`429`).

These **don’t** count:

* Requests with a missing or invalid API key (`401`). BundleUp can’t tell whose they are.
* The authorization flow (users connecting accounts) and the code exchange.
* Platform API calls (`api.bundleup.io`) and anything you do in the dashboard.
* Webhooks BundleUp sends to you.

## Rate limits

Each connection can make **100 requests per 60 seconds**, counted across the Proxy, Unified API and MCP together. The limit is per connection, so one busy account never slows down another. See [Rate limits](/docs/guides/proxy/rate-limits).

## Keeping usage down

* **Cache what doesn’t change often**, like a user’s profile or a list of channels.
* **Use webhooks from the provider**, where available, rather than polling.
* **Ask for bigger pages.** One request for 100 items is cheaper than ten for 10. Unified API endpoints accept `limit` up to 100.
* **Avoid re-listing MCP tools every turn** if your MCP client can cache the list.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.