Limits, usage and observability

Monthly request allowances#

The request allowance is shared by the workspace and resets monthly in UTC. Consult /me, response headers and Settings → API → Usage for the effective limits, including any workspace overrides.

Pace requests across your workers#

Default limits are 120 requests/minute and 5,000/hour per key, plus 600/minute per workspace. Limits can be configured by the operator. Sharing load across keys does not bypass the workspace limit. Invalid keys have a separate IP-based abuse budget.

• X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset describe the tightest enabled bucket.
• X-RateLimit-Reset is seconds until that window resets, not a Unix timestamp.
• X-Quota-Limit, X-Quota-Remaining and X-Quota-Reset describe the monthly allowance. The reset is an ISO timestamp.
• Unlimited quotas omit the limit and remaining headers. Rate headers are omitted when all rate buckets are disabled.
• 429 responses provide Retry-After. Use it rather than busy-polling.

What counts as a request#

An admitted authenticated request counts, including one whose handler later rejects invalid input, an idempotent replay or a failure. Admission refusals for invalid keys, permissions, scopes, rate limits and quota do not count. A release-gate refusal happens after admission and does count. Public metadata and OpenAPI calls do not count. Concurrent requests can slightly exceed the monthly boundary; do not build around that overshoot.

Inspect usage and changes#

Settings → API contains Keys, Usage and Request log. Inspect request identifiers, methods, paths, statuses and timings; request-log entries are retained for 14 days. Members see their own key activity, while administrators with api.manage can inspect workspace-wide activity.

• API writes appear in the workspace audit trail as API · <key name>, attributed to the key’s owner.
• Keep X-Request-Id in your own operational logs, without logging the bearer secret.
• Raw request-log paths and timing help diagnose a call; audit entries explain the actual record changes.

Send changes to another system#

There is no REST webhook-subscription endpoint. Configure a record-triggered automation with a webhook action in Squario to notify your HTTPS receiver. The receiver can use this API to fetch the records it needs. Follow the automation’s configuration for the outgoing payload and credentials.