Skip to main content
Webhook subscriptions tell Lusha which entities to watch and where to send notifications when signals fire. Each subscription links one entity (a contact or company) to a webhook URL and a set of signal types. You can manage up to 25 subscriptions per request and monitor all deliveries through audit logs.

Setup flow

1

Generate your account secret

Call POST /api/account/secret/regenerate to create your account-level webhook secret. Store it securely - it is displayed only once and is required to verify every incoming delivery.
2

Create a subscription

Call POST /api/subscriptions with a defaults object (containing your webhook url and, optionally, a default entityType and signalTypes) and a subscriptions array with one entry per entity you want to watch. Each entry requires at least entityId, and can override entityType, signalTypes, or name.
3

Test the subscription

Call POST /api/subscriptions/{id}/test to send a test payload to your endpoint and confirm the full delivery pipeline works before going live.
4

Go live and monitor

Your endpoint will now receive real-time deliveries. Use GET /api/audit-logs to monitor delivery success rates, inspect failures, and reactivate any disabled subscriptions.

Create subscriptions

POST /api/subscriptions Creates one or more webhook subscriptions for real-time signal notifications.
You can create up to 25 subscriptions per request. Your account must have a webhook secret before deliveries can be received.

Delivery and reliability

Lusha retries failed deliveries automatically:
  • 3 retry attempts with exponential backoff
  • Auto-disable: a subscription is disabled after all retries are exhausted
  • All delivery attempts are recorded in audit logs

Webhook payload examples

When a signal fires, Lusha sends a POST request to your webhook URL with a JSON body. Below are examples for a contact promotion signal and a company news signal.

Required acknowledgment response

Your endpoint must respond within 10 seconds with an HTTP 2xx status and the following JSON body:
A non-2xx response triggers the retry mechanism. After 3 failed retries the subscription is automatically disabled.
Return the acknowledgment before performing any heavy processing. Queue the payload for async handling if needed:

List subscriptions

GET /api/subscriptions Returns all webhook subscriptions for your account with pagination support.
  • Results are sorted by createdAt in descending order (newest first)
  • Default page size: 10; maximum: 100
  • Use offset to paginate through large result sets
The webhook secret is never returned in list responses for security.

Get a subscription

GET /api/subscriptions/{id} Returns a single webhook subscription by its ID.

Update a subscription

PATCH /api/subscriptions/{id} Updates an existing subscription. All fields are optional - include only the fields you want to change.

Reactivating a disabled subscription

If a subscription was disabled after exhausting retries, set isActive: true to reactivate it. The system automatically:
  • Clears the blockReason field
  • Clears the blockedAt timestamp
  • Resets the retry counter

Regenerating your account secret

Set regenerateSecret: true in the request body to rotate your webhook secret. Keep in mind:
  • The new secret affects all subscriptions for your account
  • The secret is shown only once in the response - store it immediately
  • The old secret is immediately invalidated

Delete subscriptions

POST /api/subscriptions/delete Deletes one or more subscriptions in a single request.
Deletion is permanent and cannot be undone.
  • Up to 25 subscriptions can be deleted per request
  • Duplicate IDs in the request are automatically deduplicated
  • Each subscription is processed independently; the response includes a result for each item
  • Invalid ID formats are gracefully handled and reported as NOT_FOUND

Test a subscription

POST /api/subscriptions/{id}/test Sends a test payload to your webhook endpoint without consuming credits.
Run a test delivery before going live to confirm your endpoint handles signatures and acknowledgments correctly.
Choose a test mode using the mode query parameter, based on what you want to validate: Test payloads use mock data and do not trigger credit charges.