# Limits and safe testing

Plan for Beacon request limits and test integrations without unintended provider effects.

Beacon applies one request limit to Agent API and hosted Model Context Protocol (MCP) traffic.

## Current request limit

Beacon permits 600 requests per hour for each agent key or OAuth connector.

Beacon uses a fixed one-hour window. Requests share the window when they use the same key or connector.

The limit controls abuse. Monthly post allowances and AI credit charges still apply separately.

## When Beacon limits requests

Beacon returns HTTP `429 Too Many Requests` after a key or connector exceeds the limit.

The `Retry-After` response header gives the remaining wait in whole seconds.

The problem response contains these values:

| Field                       | Value                                             |
| --------------------------- | ------------------------------------------------- |
| `type`                      | `urn:beacon:problem:agent_rate_limited`           |
| `status`                    | `429`                                             |
| `retryable`                 | `true`                                            |
| `details.retryAfterSeconds` | The same wait that `Retry-After` gives in seconds |

Wait for the full `Retry-After` duration. Then retry only when the selected operation permits a retry.

The TypeScript SDK exposes the wait as `BeaconError.retryAfterSeconds`.

## Test without provider effects

Beacon does not provide a public sandbox Agent API or a general dry-run route.

Use `POST /agent/v1/post-checks` to validate a complete post plan without creating a post. For MCP, run `beacon_check_post`. Both surfaces use the same check.

The check does not queue work, contact a provider, or create or use an approval.

Use a separate Beacon workspace and provider test accounts for end-to-end tests.

1. Use read routes to test authentication and data mapping.
2. Create drafts when a test must exercise a write.
3. Use one stable idempotency key for each test case.
4. Reuse the key only when the test repeats an unchanged request.
5. Use provider test accounts before a schedule or publication test.
6. Review the exact destination before any provider effect.

AI draft and image tests can use AI credits. Schedule and publication tests can use the monthly post allowance.

Read [Retry safely](/docs/developers/sdk/retry-safely) before you add automatic retries.