Lusha API: Rate Limits by Plan, Three Generations, and What a Call Actually Costs

Lusha publishes its API rate limits by plan, which almost nobody in this category does, and the table is the first thing worth reading. A Free or Starter key is capped at 40 requests a minute and 100 requests a day. A Scale key is capped at 300 a minute, 5,000 an hour and 50,000 a day. Fetched from the vendor's user guide on 16 August 2026.

That is a five-hundred-fold spread in daily throughput between the bottom and the top of the same product. Any integration design that does not start from which row you are on is guesswork, because a nightly enrichment job that is trivial on Scale is mathematically impossible on Starter.

Which generation you are looking at

Three versions of this API are visible in Lusha's own documentation at once, and they do not all do the same things.

Person API V1 was deprecated, with the vendor's own tutorial giving a date of 14 January 2025 and instructing callers to move to GET https://api.lusha.com/v2/person. V2 widened the input options: where V1 wanted a name plus a company name or domain, V2 also accepts an email address or a LinkedIn URL, and it returns richer metadata including a type for each email and phone, confidence levels, and do-not-call flags.

The enrichment surface documented for the newest work is different again. Waterfall Reveal, described below, is documented as running on POST /v3/contacts/enrich, and the user guide's endpoint list is organised around named products rather than versions: Person, Company, Prospecting, Lookalike, Signals, plus a Credit Usage endpoint.

The practical instruction is the same one that applies to the Apollo.io API and every other vendor running two generations in parallel: before writing a line of code, confirm which version the documentation page you are reading describes, and confirm it again against the response shape you actually get back. Sample code found in a blog post is the least reliable artefact in this whole category.

Getting a key, and who is allowed to

Authentication is a header-passed API key, generated in the API Hub inside the product. Two details in the documentation matter for how you design around it.

The key is shared at account level rather than issued per user, and several keys can be created. Access to create them is restricted to Admins and Managers, which the guide states is available on all plans, so an API key is not a paid upgrade in itself.

Multiple keys are the feature to use deliberately. Because limits and caps are enforced per key, giving each integration its own key is what stops a runaway Zapier automation from consuming the throughput your production enrichment job needs.

What a call costs, on two meters at once

Lusha charges by data point and by result, and the two combine.

The data points, as published: an email is 1 credit, a phone number is 5, and company information is 1. The request charge sits on top: a single request costs 1 credit per result returned, while a bulk request costs 1 credit per 1 to 25 results. A minimum of 1 credit applies per request even when nothing comes back, and re-querying a contact does not recharge for data points already revealed.

The vendor's worked example is a good one to internalise: revealing an email and a phone for one contact costs 7 credits, being 5 for the phone, 1 for the email and 1 for the request. Signals carry their own prices, with a hiring surge or headcount growth signal at 1 credit per company and a job change signal at 1 credit per contact.

The full credit model, including what that does to a thousand-contact wave and how seats and top-ups behave, is a pricing question rather than an API one, and this page deliberately does not rebuild it. What the API adds to that picture is the batching rule, and it is worth an explicit note: at 1 credit per 1 to 25 results, a bulk request returning 25 rows costs the same request charge as one returning a single row. Batching to the 25-result boundary is free efficiency, and the hard ceiling is 100 contacts or companies per request.

100 / dayFree and Starter daily cap

Against 50,000 a day on Scale

100Maximum records per request

Bulk Person and Bulk Company

5 / minCredit Usage endpoint limit

Its own limit, far below the others

That last figure catches people out. The endpoint that tells you how many credits you have left is itself rate-limited to 5 requests a minute, so a design that checks the balance before every enrichment call will hit a limit on the accounting endpoint long before it hits one on the data endpoints. Poll it on a schedule, not per call.

The per-key credit cap, and the error it generates

Admins can set a monthly credit limit on each individual API key, with the sum of all key limits capped at the account's total allowance, resetting at the start of each billing cycle.

This is genuinely useful governance. It is also the source of the single most confusing failure mode in the documentation, which Lusha writes up explicitly: calls rejected with a credit limit reached error while the dashboard still shows credits available. The cause is nearly always the per-key cap rather than the account balance, and only an Admin can see or change it.

Build for that. An integration that surfaces "out of credits" to its users without distinguishing the two cases will generate support tickets that go to the wrong team.

1. Step 1Request

   Up to 100 records per call, keyed and rate-limited per API key

2. Step 2Lusha match

   Native data points billed at 1 credit for an email, 5 for a phone

3. Step 3Waterfall fall-through

   Only for requested fields Lusha cannot fill, if Data Waterfall is enabled

4. Step 4Charge

   2 credits per work email or 8 per phone from a third party, on a match only

Waterfall Reveal, and the part you do not control

The newest and most consequential feature for anyone building a serious pipeline is Waterfall Reveal. When Lusha's own data has no match for a field you asked to reveal, the request falls through to third-party providers you have enabled, and fills the gap.

The mechanics, as documented: an Admin turns Data Waterfall on and manages individual vendors under Account Settings, after which it runs automatically on every enrich call for the fields you requested, with no extra parameter needed to trigger it. To opt a specific call out, pass waterfallEnabled: false alongside the reveal. Pricing is flat across every vendor at 2 credits per work email and 8 credits per phone, charged only on a match. The guide also records that rollout is staged and that vendor coverage starts with two providers covering the US.

One line in that documentation deserves more attention than it gets: Lusha determines the provider query order, and it is not caller-configurable.

For most buyers that is a convenience. For anyone who has built a provider waterfall deliberately, it is the whole argument. Provider order is the lever that decides both cost and hit rate, because the cheap high-coverage provider should be asked first and the expensive specialist last. Handing that ordering to the vendor whose own data sits at position one is a reasonable trade for simplicity and a poor one for anybody optimising cost per usable record. The 8-credit phone fall-through, against 5 credits for a native phone reveal, is the same trade expressed as a number.

Note also what the fall-through costs when it fails: nothing, because it is charged on a match only. That makes it cheap to test and hard to reason about in advance, since your bill moves with the coverage gaps in your specific market rather than with your volume.

Before you build

Pre-build checks

• ✓Yes: Confirm your plan's per-minute, per-hour and per-day limits, since they differ by a factor of hundreds
• ✓Yes: Issue a separate API key per integration so one runaway job cannot starve another
• ✓Yes: Batch to the 25-result billing boundary, and never exceed 100 records per request
• ✓Yes: Implement exponential backoff on a 429 rather than a fixed retry
• ✓Yes: Check whether a per-key credit cap is set before debugging a credit error
• ✓Yes: Decide explicitly whether Data Waterfall should be on, since provider order is not yours
• ✕No: Poll the Credit Usage endpoint before every call

Two more things the documentation is clear about and integrators still get wrong. Exceeding a limit returns a 429, and the guide asks for exponential backoff rather than an immediate retry, which is the difference between a brief pause and a key that spends the hour in a rejection loop. And legacy accounts keep their old limits of 300 a minute, 600 an hour and 6,000 a day, so an inherited integration may be operating under numbers that appear nowhere on the current table.

Where it sits

As an API, Lusha is unusually well documented on exactly the things that decide an integration: published per-plan rate limits, an explicit batching rule, a per-key governance model and a documented failure mode. That is a better starting position than most of this category offers, and it compares well against the other European vendors, which solve the same problems with different tradeoffs on the compliance side.

The constraints are equally clear. The daily caps on the lower plans rule out bulk work entirely, provider order in the waterfall is the vendor's decision rather than yours, and the phone reveal is expensive on both the native and the fall-through meters. For an email-and-LinkedIn motion like ours, that last point is mostly academic, since the phone line item never gets touched and the useful half of the product is the 1-credit email reveal with an independent verification pass behind it. The compliance half of that decision, including the lawful basis the addresses rest on, follows the GDPR position for B2B outbound rather than anything in the API documentation.

If you would rather not build and maintain any of it, we run sourcing and outbound on a pay-per-qualified-meeting basis and carry the integration work ourselves.

Pricing and features verified as of August 2026. Verify current terms with the vendor before relying on them.

Sources: All there is to know about Lusha's API, Person API V1 Deprecation