Retry commands safely
Commands require an Idempotency-Key header containing 1–200 characters. Generate one unique value for each logical action and reuse that value with the same operation and input when retrying that action.
curl 'https://api.brigg.app/v1/operations/apps.your_app.YourCommand' \
-H "Authorization: Bearer $BRIGG_API_KEY" \
-H 'Content-Type: application/json' \
-H 'Idempotency-Key: integration-action-unique-id' \
--data '{"replace_with":"the_declared_input"}'This command is a template: choose a released operation and supply the exact input from its schema. A timeout is not proof that the action failed. Reconcile or retry with the same idempotency key; do not generate a new key merely because the response was lost.
Command receipts are retained for 30 days. Do not rely on an old key to prevent duplicate work after that window. Keep your own durable integration identifiers for actions that may be replayed much later.
Retry identities belong to the credential that started the action. Reconcile pending actions with the original credential before rotating a key or reconnecting MCP. Reusing the same retry value under a new credential does not replay the original action.
Rate limits
Each credential has a budget of 600 requests per minute. Each workspace has a combined budget of 1,200 requests per minute across HTTP and MCP. Creating additional keys or switching transports does not multiply the workspace budget. All authenticated MCP requests retain an additional limit of 120 requests per connection per minute, including discovery and operation calls.
When Brigg returns 429, inspect the error details and wait at least the Retry-After interval before retrying. Use exponential backoff with jitter for repeated transient failures. Avoid synchronized polling across credentials.
Resource and cost controls
Some operations have additional page-size, upload, bulk-input, concurrency, or spending limits. Their schemas and error details describe the applicable constraint. Permission to invoke an operation does not promise unlimited background work or unlimited credits.
Process paginated lists one page at a time and keep only the concurrency needed for your workflow. Some lists return all allowed items in one response and omit next_cursor. For longer work, use the operation's returned job identifier and its documented status operation. Resource webhooks can notify you when published shared records change.
Diagnose an integration
Keep the operation name, X-Request-Id, HTTP status, stable error code, and timing in your logs. Keep credentials and sensitive request/response bodies out of diagnostic logs. Brigg records customer adoption and operation outcomes across both HTTP and MCP for support and compatibility planning.