Performance & timeouts

Most Fiber calls answer in seconds, and a few do enough work per request that they need a longer leash. We publish a recommended client timeout for every endpoint that can run long, so your HTTP client waits as long as the work actually takes and no longer.

Recommended client timeouts

Set your client timeout to at least these values. Most of them are also published in the OpenAPI spec as x-recommended-timeout, so generated clients can read them directly.

Typeaheads, counts, reference lists, and starting or polling an async job return quickly. Search pages usually do too, but a large page with every option on can run long; give people and company search at least 60 seconds when you ask for big pages, and see Large pulls and slow pages. Hotel searches and property lookups are live, so budget up to 60 seconds for them too (see Hotels).

A call that times out on your side may still finish, and be billed, on ours. For slow lookups, raise the timeout rather than retrying, so you don't pay for the same lookup twice.

Measure your own latency

API request history records how long every call took (durationMs), along with its path and status, so you can measure your real latency per endpoint instead of guessing.

Keep large jobs fast

• Search: use smaller pages, leave detailed education and work history off unless you need them, scope keyword filters to specific fields, and split huge queries into slices you page in parallel. See Large pulls and slow pages.
• Many records: send them to a batch or async endpoint instead of looping single calls. One batch request covers up to 2,000 people for contact reveal. See Sync vs async.
• Waiting on jobs: subscribe to webhooks rather than polling in a tight loop.
• Parallelism: run requests concurrently up to your rate limit, spread evenly across the minute.

Related

• Sync vs async — which calls return inline and which run in the background.
• Billing & credits — what each call costs.