Skip to main content
The Lusha API uses standard HTTP status codes to indicate whether a request succeeded or failed. When a request fails, the response body always includes a JSON object with a statusCode, a human-readable message, and an optional errors array with more detail.

Standard error response format

All error responses follow this structure:
The errors array is most commonly populated on 400 and 403 responses, where it names the specific parameter or restriction that caused the failure. For other status codes it may be empty.

HTTP status codes

403 responses use the same response shape as other errors but the errors array will name the specific restriction - for example, "excludeDnc is not available on your current plan".

Contact-level errors

A 200 response does not always mean data was found. When a contact cannot be located, the API returns HTTP 200 with an error object inside the contact field:
Check contact.isCreditCharged to confirm whether a credit was consumed for the call.

Unified Credits plan restriction

The revealEmails and revealPhones parameters on enrichment endpoints - including GET /v2/person, POST /v2/person, and POST /prospecting/contact/enrich - are available only to accounts on the Unified Credits pricing plan.
If you pass revealEmails=true or revealPhones=true on a plan that does not include Unified Credits, the API returns 403 Forbidden. Contact your Lusha account manager to upgrade your plan.
When neither parameter is used, the API returns all available email addresses and phone numbers by default. Similarly, excludeDnc (DNC filtering on prospecting search) returns 403 Forbidden on plans that don’t support it.

Debugging tips

  • Start with the status code. A 4xx error is always a client-side problem; a 5xx error is server-side.
  • Read the message and errors fields. Validation errors (400) list exactly which parameters failed and why.
  • Check your API key first on 401. Confirm the api_key header is present and the value matches what is shown in your API settings.
  • Check your credit balance on 402. Use the account usage endpoint to confirm you have credits remaining before retrying.
  • Do not retry 400, 401, 402, or 403 without fixing the request. These errors will repeat until you correct the underlying issue - a bad parameter, a bad key, an empty credit balance, or a plan restriction.
  • Retry 500 and 499 with exponential backoff. Transient server errors and timeouts usually resolve quickly.
  • Log the full response body. The errors array often contains the information you need to fix the request immediately.