Skip to main content
POST
Receive an inbound lead by webhook
Nexor has two inbound lead webhook contracts. They create leads through different configuration and authentication paths; do not combine their URLs or field-mapping formats.

Choose the right endpoint

Use a per-door webhook when one external source always sends leads to the same agent and you want door-level activity, pause/resume, deduplication, and dry-run validation. Use the generic route for a headerless system that already has a Nexor API key, or when each request must select its agent.
Both URLs contain or accept credentials. Never place a real URL or key in documentation, screenshots, analytics, or support messages. Rotate the credential if it is exposed.

Per-door webhook

Create and manage this door from Custom connection. Its field map uses incoming paths as keys and Nexor fields as values:
Dot paths can traverse nested objects and numeric array positions. If first_name is mapped but last_name is not, Nexor splits a multi-word mapped name after the first word. After mapping, the payload must contain at least one of first_name, last_name, email, or phone.

Validate without creating a lead

A valid test returns 200, dry_run: true, and the translated lead. It does not create a lead. Remove dry_run=true only after checking the translated identity and destination agent. The endpoint allows 120 requests per IP address per minute. A disabled door returns 403; an invalid token returns 404; a payload without an identity field returns 400. A new lead returns 201. When door deduplication is enabled, Nexor checks email when present, otherwise phone, and an existing lead returns 200 with duplicate: true.

Generic Public API webhook

The generic route uses the same single-lead processing as POST /leads. A workflow_id in the JSON body takes precedence over the query parameter.
If the sender supports headers, you can omit ?token= and send X-API-Key instead. With no intake map on the key, the body must already use Nexor’s canonical field names. With a per-key intake map, Nexor resolves configured aliases and can carry unconsumed fields into lead metadata. POST /api/public/leads/odoo remains an identical compatibility alias. It is not the native Odoo API-key integration and should not be used as the name of a new custom connection.
These endpoints are headless and have no request screen to capture in staging. The Custom connection guide shows the real dashboard surface used to manage doors.

Authorizations

token
string
query
required

API key passed in the query string for webhook senders that cannot set headers. Prefer X-API-Key when the sender supports custom headers.

Query Parameters

token
string

API key for senders that cannot set X-API-Key. Do not place it in logs or screenshots.

workflow_id
string<uuid>

Optional agent assignment. A workflow_id in the JSON body overrides this value.

Body

application/json

Inbound lead payload. If the API key has an intake field map, provider-specific keys are translated first and unrecognized fields may be preserved in metadata. Without a map, use the canonical fields below.

first_name
string

Lead's first name

last_name
string

Lead's last name

email
string<email>

Lead's email address

phone
string

Lead's phone number

company
string
title
string
city
string
date_of_birth
string<date>
external_id
string

Lead identifier in the source system

source
string

Source label. Defaults to api.

workflow_id
string<uuid>

Agent assignment. This body value overrides the query parameter.

campaign_id
string<uuid>
metadata
object
do_not_contact
boolean

Create or update the lead without starting outreach

Response

An existing lead was matched, or a configured source router intentionally skipped intake

success
boolean
required
Example:

true

lead
object
required
workflow_run
object
warning
string

Warning message if lead was created but workflow assignment failed

Last modified on September 7, 2026