Reference

Rate limits and request ids

60 requests per minute per API key, counted per endpoint group. Every authenticated response tells you where you are and which request it was.

#The limit

60 requests per minute per API key, counted per endpoint group: /posts and /webhooks each have their own bucket, and so does the MCP endpoint. Over the limit you get 429 with a body that has no message field:

429

{ "error": "too many requests" }

Back off and retry. The response tells you when to come back: read x-ratelimit-reset.

#The headers

Every authenticated /api/v2 response carries these, errors included. The two unauthenticated cases, OPTIONS preflights and GET /openapi.json, carry none of them.

x-request-idreq_48120533

This request's id. Quote it when you report a problem and we can find the request in our logs. Errors that carry a req_id in the body use the same value.

x-ratelimit-limit60

Requests allowed in the current window for this API key and endpoint group.

x-ratelimit-remaining58

Requests left in the current window after this one.

x-ratelimit-reset1787851260

Unix time in seconds when the window has room again. The window slides, so this is when the oldest request in it ages out.

bash

$ curl -i https://api.yeetpost.com/api/v2/connections -H "x-api-key: $YEETPOST_API_KEY"
HTTP/2 200
x-request-id: req_48120533
x-ratelimit-limit: 60
x-ratelimit-remaining: 58
x-ratelimit-reset: 1787851260

The window slides, so x-ratelimit-reset is when the oldest request in it ages out, not a fixed clock minute. It is always a second the window has room in, so sleeping until it is enough. All four headers are listed in Access-Control-Expose-Headers, so browser code can read them too.

#Request ids

Quote x-request-id when you report a problem and we can find that exact request in our logs. It is the same id that platform_rejected and internal_server_error bodies carry as req_id, and the one the Logs section of your dashboard lists next to each request.

One response carries the request id but no window state: a body that is not the JSON it claims to be is rejected with 400 invalid_request before the rate limit is ever checked.

#Handling a 429

Documented on all 10 authenticated endpoints. Treat it as a wait, not a failure.

Sleep until x-ratelimit-reset, then retry the same request.
On POST /posts, retry with the same Idempotency-Key so a retry that crosses with a slow first attempt cannot double-post.
Watch x-ratelimit-remaining and slow down before you hit zero, if you are fanning out in a loop.

Every other code is on the errors page.