Lusha API Review 2026: Pricing, Features and Limits

Key takeaways:

• The Lusha API is at https://api.lusha.com/v3/, authenticating with an API key in a request header rather than a query string, and V3 introduces a search-then-enrich pattern with bulk operations and AI lookalikes.
• API access starts on the Pro plan. The Free and Starter tiers do not include it, which is the single most important thing to check before planning an integration.
• Rate limits are enforced per plan across per-minute, per-hour and per-day windows, and the Credit Usage API has its own separate limits.
• Billing is per row returned rather than per request, and a call that returns nothing is not charged.

Lusha’s API documentation is among the clearest in this category, and the product does something genuinely useful with credits: it only charges you when it finds something.

The catch is access. The API sits two tiers up the price list, so a team evaluating Lusha on the free plan cannot test the thing they intend to build on.

This review covers the endpoints, the authentication model, the credit mechanics, the rate limits and the plan gating, plus the MCP server Lusha now ships alongside the API. Our own platform bundles contact data inside an outbound subscription, which is a different product from a dedicated data API and worth keeping distinct as you read.

What the Lusha API Covers

Lusha holds a large B2B dataset, publicly described as more than 290 million verified contacts and 29 million companies. V3 organizes access to it around a search-then-enrich pattern rather than a single lookup call.

The search-then-enrich split is the design decision that shapes everything else. Prospecting endpoints find candidates cheaply; enrich endpoints return the contact details that cost credits. Piping the first into the second is the intended flow, and lookalike endpoints return paginated results built for exactly that.

Tables deserve a mention because they are unusual in an API of this kind. Rather than making you store results yourself, Lusha lets you pass a tableId on prospecting, enrich, signals or lookalike calls and persist the output automatically, with columns covering default fields, enrichment data, signals, AI insights, CRM fields and custom fields.

Webhooks close the loop on data decay. Subscribing to job-change and company events means a stored record can be corrected when the person moves, rather than quietly going stale until someone emails a dead address.

That last capability is the one worth designing around, because decay is the real cost of any purchased dataset. Contact records rot at the rate people change jobs, and a database you bought once is a database that is wrong within eighteen months. Vendors across the B2B data API category are converging on event subscriptions for this reason, and Lusha’s implementation is a first-class part of the API rather than an afterthought.

Discovery endpoints round out the picture. Before building a prospecting request you can list the available filter types and then fetch valid values for a specific one, which avoids the guesswork of constructing filters against undocumented enums.

Authentication and the Owner Field

Lusha authenticates with an API key linked to your account and plan, passed in the api_key request header on every call. Lusha’s documentation is explicit that the key should be stored securely and used only in server-side environments.

Putting the credential in a header rather than a query string is the right choice and worth crediting, since it keeps the secret out of URLs and therefore out of server logs, proxy logs and referrer chains.

One requirement catches almost everyone on their first integration. When you authenticate with an API key, owner.email is required on every call, and omitting it returns 400. It resolves to a user on your account and determines table ownership.

The mechanics differ by verb, which is the part worth writing down. It goes in the body as owner: { email } on POST and PATCH calls, and on DELETE .../entities, which carries a body. On other GET and DELETE calls, which have no body, it goes in as an ?email= query parameter. Callers authenticating with OAuth or a token skip it entirely, because the caller is already identified.

Rate Limits and Credits

Lusha enforces rate limits per plan, applied across multiple time windows: per minute, per hour and per day. The Credit Usage API has its own limits, separate from standard endpoints.

Responses carry rate-limit headers, so a well-built client can throttle itself before it runs into the wall. Crossing one returns 429 Too Many Requests, which is the status code IETF RFC 6585 defines for exactly this condition, specifying that the response “SHOULD include details explaining the condition” and may carry a Retry-After header telling the client how long to wait. A 401 means the key is missing or invalid.

The credit model is the genuinely good part, and it is more precise than most competitors.

Reading entities charges per row returned rather than per request, so a query is priced by what it actually gives you. A request that returns nothing is free. On the conversation-intelligence side, search charges one credit per block of up to 25 conversations returned, transcript analysis charges one credit per successful request, and a 404 is never charged.

That structure rewards specific queries and does not punish exploration, which is a meaningful difference from vendors who charge for the attempt.

Lusha API Pricing

This is where the article earns its keep, because the gating is not obvious from the pricing page at a glance.

Paying yearly saves 25% against monthly, and the Free plan needs no credit card. Scale adds 50% or more off the price per credit, which is the real lever at volume, along with SSO for teams that need it.

Two cautions about those figures. Lusha’s pricing page runs on a credit slider, so the headline number moves with the annual credit volume you select; the table above reflects the slider at 40,800 credits per year. And the jump from Pro to Premium is large in both directions, roughly six times the price for roughly six times the credits, so the tier you need is decided by consumption rather than by features.

Credit rollover is capped at twice your monthly amount on Pro and Premium, which softens a quiet month without letting an unused year accumulate.

Compare on price per credit rather than on plan price, since that is what actually differs. A tier that looks expensive can be cheaper per record than a smaller one, and Scale exists precisely because the unit price falls with volume. Our roundup of Lusha alternatives is the useful benchmark here, because coverage and price per record move independently and the cheapest vendor per credit is not automatically the cheapest per usable contact.

The Lusha MCP Server

Lusha ships an MCP server alongside the API, connecting Claude, ChatGPT and other MCP clients to the same dataset. It is listed in Claude’s connector directory, so setup is finding Lusha in a list rather than configuring an endpoint.

The access rule inverts the API’s. Lusha states that any plan qualifies for MCP, including Free, which makes the conversational surface available two tiers below the programmatic one. For a team evaluating the data before committing to a build, that is the cheaper door.

The two surfaces suit different work, and the split is the familiar one. MCP is for a person asking questions and pulling a list; the API is for scheduled jobs, bulk enrichment, webhooks and anything that has to run without someone in the chat window.

Both draw on the same credits, so a rep exploring in Claude is spending the same balance a nightly enrichment job depends on. That is the practical argument for setting expectations before you hand the connector to a team, since conversational access makes consumption much less predictable than a scheduled process. The pattern is now standard across contact enrichment APIs, where the conversational layer arrived after the billing model was already designed for machines.

Where the Lusha API Falls Short

The limits are mostly commercial, because the engineering is sound.

The Pro gate is the main one. A developer cannot evaluate the API on Free or Starter, so proof-of-concept work requires a paid annual commitment or a sales conversation. That is a real barrier for a team comparing several data APIs before choosing, and it is the kind of friction that quietly decides bake-offs in favor of whichever vendor let the engineer start on a Friday afternoon.

Rate limits are documented as a model but not published as numbers, which is a smaller problem than it sounds because the Account endpoint reports your own. Lusha documents the model clearly, including the windows and the separate Credit Usage limits, but the actual per-plan figures are not in the public docs, so capacity planning needs your own account’s Account endpoint or a conversation with Lusha.

The owner.email requirement is friction rather than a flaw, though it is the kind that costs an afternoon the first time. It applies only to API-key callers and moves between the body and the query string depending on the verb.

Coverage is the honest limit on any data vendor, including this one. A published contact count is a measure of a database, not of your segment, and the only meaningful test is a sample against your own ICP before you commit to a tier. That advice applies across every vendor in our AI prospecting API roundup, and it is the step teams most often skip when a headline number looks reassuring.

Phone coverage in particular deserves separate testing from email. The two are sourced differently and hit rates diverge sharply by region and seniority, so a sample that looks strong on email can disappoint on direct dials for the same list.

On compliance, Lusha is better documented than most. It publishes GDPR certification by ePrivacyseal, CCPA validation by TrustArc, and certification against ISO 31700, the international standard establishing high-level requirements for privacy by design across a consumer product’s lifecycle. That does not remove your own obligations as the party doing the outreach, but it does mean the diligence questions have published answers.

Using the Lusha API With Reply.io

Lusha finds and verifies the person. We run the conversation that follows. The division is clean because we do not do the first job at all.

Our contact model is the thing most worth understanding here, because it is easy to mistake for enrichment. Contact lookup on our side reads the records already stored in your workspace, matched on an exact email address or LinkedIn URL. It confirms whether we hold someone and returns what we know about them. It never reaches outside your account, and it will never turn a name and a company into an email address.

That is not a gap we are working around; it is a different job. Lusha’s database answers “who is this person and how do I reach them.” Ours answers “what has happened with this person and what should happen next.” Reading our lookup as a weak version of enrichment is the mistake, and it leads teams to expect a hit rate from a tool that is not searching anything.

The practical pattern is straightforward. Lusha enriches, your system writes the contact to us, and a sequence starts. Job-change webhooks make that loop continuous rather than one-off, which is where the pairing gets genuinely interesting: a contact who changes company is both a dead address and a warm new prospect, and only the first half is obvious from our side.

Teams building that join can work from our API directly. Our platform bundles a contact database too, and we should be plain that it ships inside the subscription with a modest credit allocation rather than being sold as a standalone data product, so it is not a replacement for a dedicated vendor at Lusha’s scale.

Who the Lusha API Is For

The Lusha API suits teams already on Pro or above who want enrichment inside their own systems, and it suits them well: the credit model is fair, the endpoints are coherent, and the compliance documentation is unusually complete.

Early evaluation is where it disappoints, because the tier including the API is the third one. Teams wanting to test data quality first should use the MCP server on a free account, then decide.

For the platform view rather than the API one, our Lusha AI review covers the workspace, extension and signal features that sit on the same dataset.

The decision usually comes down to one question: are you enriching continuously or in campaign-shaped bursts? Continuous enrichment justifies the annual commitment and rewards the webhook subscriptions. Bursty demand often does not, and a team in that position is better served by a vendor with genuine pay-as-you-go pricing than by buying a year of credits to use in two months.

Enriched the contact and need to run the outreach? Start a free trial and connect the two.