Read API usage, limits, and errors

Customer integrations need an active Pro plan, and you need to be an owner or admin of the Locker. Open Admin, then Settings, then Integrations. Every panel in this article sits on that one page.

Under Connection check, select Test the connection. Lockers makes a single request with the key and reports the connection's name, its environment, the permissions and course restrictions it carries, when it expires, and its current quota windows. The panel also shows the Base URL and the Budget that key draws on.

Run this first whenever a tool starts behaving oddly. It separates two questions that look identical from the outside: whether the key still works, and whether the tool is sending what you think it is sending.

The base URL is always https://lockers.social/api/v1. API requests never go to a community's custom domain, so a tool pointed at the community's own address will fail no matter how good the key is.

Requests per minute is set when the key is created, anywhere from 1 to 600, and 60 unless you change it. That ceiling belongs to that key and nothing else.

Writes and other costly work draw on a second set of limits: a budget for the key and a budget for the community, both shown under Budget. The community budget is shared, so adding a second key does not add capacity. It divides what is already there. That matters when a nightly sync and a live automation run against the same community, because the sync can consume what the automation needs during the day.

Recent API activity lists recent requests against your community. Before any traffic arrives it reads No API requests recorded yet., and the usage windows read No usage in the visible windows.

If a tool reports that it is connected and this panel stays empty, the requests are not reaching Lockers at all. Check the base URL in the tool, and check that the key was pasted in full.

When a key goes past its window, requests come back with rate_limited and a Retry-After value in seconds. Wait that long before trying again. Most integration tools back off on their own, and a burst that hits the limit for a few seconds usually settles without anyone touching it.

A limit that gets hit constantly is a sign the tool is polling for changes it could be told about instead. Webhooks push the change to your system when it happens, which removes most of the polling traffic. See Receive webhooks from your Locker.

Every error response carries a request ID, which also arrives in the X-Request-Id header and usually shows up in the connected tool's own logs. Write to support@lockers.social with that ID, the time, and which tool made the request. With the ID we can look at the exact request rather than guessing from a description.

Request logs hold metadata only, and they are kept for 30 days. Keys and response bodies are never logged. So report a problem inside that window, and never paste a key into a support message.

Each error response also says whether a retry can help. These are the codes an owner is most likely to see in a tool's logs.

The panels above cover requests your tool makes to Lockers. Deliveries Lockers sends out are tracked separately under Failed operations, with Replay failed row on each one. A failing endpoint shows up there and not in Recent API activity.