Skip to main content
Limits apply per workspace, all keys together. A normal sync uses a small fraction of them. There is no limit on the number of profiles you track. Two more limits apply per IP address, before any key is read:
  • 600 requests per minute from one address.
  • 20 unknown keys in 10 minutes from one address, then every request from it is refused for 10 minutes (failed_keys_per_ip, Retry-After: 600).

​
When a limit is reached

The API answers 429 with the code trop_de_requetes, the limit in details.limit, and a Retry-After header: the number of seconds to wait. Nothing was done. Wait, then send the same request again.

​
Know where you stand

Every answer carries three headers for the per-minute limit of its kind (reads or writes): GET /v1/limits returns all your workspace’s limits, what remains of the reads this minute, and the calls made today.

​
Sync what changed, not everything

Reading every lead every five minutes wastes your limits and finds nothing new. Instead:
  • Let TIKT call you. A webhook sends each new lead as it is found: nothing to poll.
  • Ask for what’s new. GET /v1/events?after=<last event id> returns only what happened since your last call; GET /v1/leads?first_seen_after=… only the leads found since a date; status_changed_after the ones discarded or restored since. See Syncing changes.
  • Use the biggest pages. limit=100 reads 100 leads for one call.
  • Batch your changes. POST /v1/leads/batch and POST /v1/lists/{id}/leads act on up to 100 leads in one call.