Skip to main content
The Tightknit API follows designs of REST, using clear, resource-based URLs. It supports form-encoded request bodies, returns responses in JSON format, and uses standard HTTP methods, response codes, and authentication practices.

​
Endpoint

Tightknit’s REST API endpoint is:

​
Authentication

​
API Keys

To understand how to create and manage your API keys, see API Keys. To authenticate your requests, you need to pass the API key with header: Authorization: <YOUR_API_KEY>

​
Idempotency

The API supports idempotency for safely retrying mutating requests (e.g., PATCH, POST) without causing duplicate side effects. To use idempotency, include the Idempotency-Key header with a UUIDv4 value for each distinct operation:
  • If a request with the same key has already completed, the API returns the cached response with an X-Idempotent-Replayed: true header.
  • If a request with the same key is still being processed, the API returns 409 Conflict with a Retry-After header.
  • Cached responses expire after 1 hour.
  • The key must be a valid UUIDv4 (e.g., generated via crypto.randomUUID()). Invalid formats return 400 Bad Request.
  • The header is opt-in. Requests without it are processed normally.
  • Safe methods (GET, HEAD, OPTIONS) ignore the header.

​
Plan Requirements

Some endpoints require a higher plan than the API itself. Endpoints with plan restrictions note the minimum required plan in their description. If you call a plan-restricted endpoint without the required plan, the API returns 403 Forbidden.

​
Rate Limits

When authenticated using developer API keys, requests may not exceed 50 requests per second across all APIs.

​
Search Rate Limits

Search endpoints have additional per-caller rate limits: Requests that exceed these limits receive a 429 Too Many Requests response.

​
Abuse Protection

A separate ceiling applies per source IP address, before your API key is validated. It exists to bound credential brute-force attempts, and it sits well above the published 50 requests per second, so normal integrations never reach it. You only need to account for it if you route an unusually large number of API keys through a single outbound IP (for example, an iPaaS platform serving many workspaces from a shared egress pool). Unauthenticated requests count toward this ceiling, so a client looping on an invalid key is throttled even though it never authenticates.

​
Rate Limit Response Headers

A throttled request returns 429 Too Many Requests with these headers: These headers are sent only on a 429. Successful responses do not carry them, because the limiter does not report a running count that we could publish accurately. Pace your retries with Retry-After rather than tracking a remaining budget.
Retry-After reflects the window of the limit you actually hit, which differs by surface. Read the value rather than assuming a fixed backoff.