Lead capture integrations

A lead capture API for the systems your team built

Our lead capture API is for enquiries that arrive through a portal with no connector, your own app or a partner's system: send each one to DigiPix Flow in one signed request as it happens. The lead lands in the same inbox as every other source, checked for duplicates, scored and assigned to a rep, and a retried request never becomes a second lead.

  • One endpoint for every system you run
  • A retried request never makes a second lead
  • Duplicates flagged, scored and assigned on arrival
An example of leads arriving in DigiPix Flow from a business's own booking portal through the lead API. The portal sends a signed request and gets 202 Accepted, and Sneha Nair's lead appears in the Leads list tagged booking-portal. The same request is retried with its Idempotency-Key and is recognised, so there is still only one lead. Intake flags the lead as a possible duplicate of an earlier lead for review, and assignment rules give it to Priya Sharma.
endpoint that creates a lead
1
requests a minute for each workspace
120
window a signed request stays valid
5 min

What a lead API request carries

  • EmailThe one field every request must carry
  • NameFirst and last name, when you have them
  • CompanyThe business the person works for
  • Source codeWhich of your systems sent the lead
  • ConsentWhat the person agreed to, with the notice
  • Idempotency keyYour own id, so a retry is recognised
THE PROBLEM

Where leads from your own systems get stuck

See how it's fixed
  1. A nightly export nobody owns

    Your booking portal saves enquiries in its own database, and someone downloads a file each evening to import by hand. On the nights they forget, a day of buyers waits until morning, and by then several have already spoken to a competitor.

  2. Leads forwarded by email and retyped

    A partner emails over the enquiries they collect for you, and a coordinator copies names and addresses into the CRM between other jobs. Typos creep in, attachments go missing, and nobody can tell afterwards which partner sent which lead.

  3. One flaky connection, two copies of a buyer

    Your developer wires the app to a CRM, but the network drops just as a request completes and the app tries again. Without a way to recognise the retry, the same buyer is created twice and two reps end up calling them.

YOUR OWN SYSTEMS

Send leads to the CRM from systems no connector reaches

Meta, Google, IndiaMART and DigiPix Flow forms each have a connector of their own. The lead API is for everything else: a property or booking portal you run, your mobile app, a dealer or partner system, or an internal tool your team built. Give each one its own source code and its leads arrive tagged, so you always know which system sent them.

  • Portals and apps that have no connector
  • Partner and dealer systems that collect enquiries
  • A source code for each system that sends leads
  • The same lead inbox as every other channel
Explore the lead inbox
An example of DigiPix Flow's Leads list filtered to leads sent through the lead API: four leads, each tagged with the source code of the system that sent it, booking-portal, dealer-app, partner-portal or the default api, with the owner each was assigned to and the time it arrived.
SET UP

An API client for each system, made in Settings

In Settings, under Integrations and Developer access, create an API client named after the system that will send leads. Its credential is shown once to copy into that system, and DigiPix Flow keeps only a hash. Each client shows when it was last used, and the lead API shows as connected in your Capture hub once a client is active.

  • One named client for each sending system
  • Credential shown once, then stored as a hash
  • Rename, rotate the secret or revoke in a click
  • Connected in the Capture hub once a client is active
Explore API keys and scopes
An example of the lead API set up in DigiPix Flow: Settings, Developer access lists two active API clients, Booking portal and Dealer app, each with the create leads scope and when it was last used, and the Capture hub below shows the Public CRM API as connected beside Meta Lead Ads and IndiaMART.
SIGNED REQUESTS

Every request signed, so a copied one goes nowhere

Besides the credential in the Authorization header, each request carries a timestamp and a signature: an HMAC-SHA256 of the timestamp, method, path and a hash of the body, made with the same credential. A request whose body was changed on the way, or that arrives more than five minutes after it was signed, is refused with a 401.

  • Credential sent as a Bearer token
  • X-Digipix-Timestamp and X-Digipix-Signature headers
  • Body changed in transit means the request is refused
  • Signed requests stay valid for five minutes
An example of a signed request to DigiPix Flow's lead API: the headers carry the API client credential as a Bearer token, an Idempotency-Key, an X-Digipix-Timestamp and an X-Digipix-Signature, the signed string joins the timestamp, POST, the leads path and a hash of the body, and three outcomes show a fresh signed request accepted with 202 while a request whose body was edited and one signed seven minutes earlier are both refused with 401.
WHAT YOU SEND

A short, predictable body with nothing to guess

Send the person's email address, and add their first name, last name and company whenever your system has them. The source field becomes the lead's source code, so your team can tell your portal's leads from your app's; leave it out and the lead is tagged api. If an email address turns out to be malformed, the lead is still kept as long as it has a name.

  • Email required; names and company optional
  • A source code of your choosing, or api by default
  • A malformed email dropped, the named lead kept
  • Fields outside the schema are ignored, not stored
An example of a lead API request body and what it becomes in DigiPix Flow: email, first name, last name, company name and the source booking-portal each map to a field on Sneha Nair's lead, email is marked required and the others optional, the source defaults to api when left out, and a travelDates field that is not part of the API is shown as ignored.
SAFE RETRIES

Send it again after a timeout, still get one lead

Every request needs an Idempotency-Key header, and the best key is the enquiry's id in your own system. The first request is accepted with a 202 and a correlation id. If the same key comes again, whether from a retry loop or a job that ran twice, nothing new is created and the answer carries the first correlation id with duplicate set to true.

  • An Idempotency-Key header on every request
  • Use the enquiry id your system already has
  • A repeated key creates nothing new
  • Replays don't count toward your monthly requests
An example of one booking sent to DigiPix Flow's lead API three times with the same Idempotency-Key, BK-4471: the first response is lost when the connection drops, a retry and a later sync job both get 202 with duplicate true and the first correlation id, and the Leads list still shows a single lead for Sneha Nair.
WHAT HAPPENS NEXT

An API lead gets the same care as a form lead

Once the request is accepted, the lead goes through the intake every source shares. It is checked against your existing leads by email address, and possible duplicates are flagged for someone to review. The company is filled in from the email domain, the lead is scored, and your assignment rules give it an owner, respecting working hours, with a default owner as the fallback.

  • Possible duplicates flagged for review, never merged
  • Company details filled in from the email domain
  • Scored, then assigned by your rules
  • Workflows on Lead created run for API leads too
Explore duplicate checks
An example of a lead that arrived through DigiPix Flow's lead API: Kavya Iyer's lead from the booking-portal source shows a banner flagging a possible duplicate with the same email as an earlier lead, waiting for review rather than merged, and a timeline records the lead created from the API, the duplicate flag, the company filled in from the email domain, a score of 64 and assignment to Priya Sharma by the Holiday bookings rule inside working hours.
ERRORS & LIMITS

Answers your code can act on when something is off

Each response says plainly what happened. A missing signature or a revoked client gets a 401, a client without the lead scope gets a 403, and a missing Idempotency-Key or an invalid consent claim gets a 422 naming the problem. Beyond 120 requests a minute, or past your plan's monthly allowance, the answer is a 429, so your system can wait and retry with the same key.

  • 401 for a bad signature or a revoked client
  • 403 when the client lacks the lead scope
  • 422 with the field that needs fixing
  • 429 to slow down, then retry with the same key
Explore outbound webhooks
An example reference of the lead API's error responses in DigiPix Flow: 401 for an invalid signature or a revoked API client, 403 when the client lacks the lead.create scope, 422 for a missing Idempotency-Key or a consent grant without a notice version, and 429 for more than 120 requests a minute or a reached monthly request limit, each with what the calling system should do next.
HOW IT WORKS

From a new API client to an assigned lead, in five steps

  1. STEP 01

    Create an API client

    Name it after the portal, app or partner system that will send leads.

  2. STEP 02

    Store the credential

    Copy it once into that system's secrets; DigiPix Flow keeps only a hash.

  3. STEP 03

    Sign and send each enquiry

    POST the lead with its signature headers and your own id as the Idempotency-Key.

  4. STEP 04

    Let intake do the rest

    Duplicates are flagged, the lead is scored and your rules assign an owner.

  5. STEP 05

    Reply while it's fresh

    The owner sees the new lead in their list and picks up the conversation.

THE DIFFERENCE

The lead API vs a nightly export

What it coversA nightly export imported by handDigiPix Flow
When the lead arrivesThe next morning, if someone remembersAs soon as your system sends the request
Who does the workA coordinator downloads, cleans and uploadsYour system sends it with no one in between
Sent twiceTwo rows, two leads, two callsOne lead, recognised by its Idempotency-Key
Which system it came fromLost once the file is merged with othersA source code on every lead
Duplicates of existing buyersSpotted later, if at allFlagged for review when the lead arrives
OwnerShared out by hand after the importAssigned by your rules, in working hours
ConsentA column nobody can trace back to a noticeClaims recorded with the notice version

Lead API questions, answered

When should we use the lead API instead of a form or a connector?

When the enquiry is collected somewhere DigiPix Flow has no connector for, such as your own booking portal, a mobile app, a dealer system or a partner's platform. If the enquiry comes from your website, a DigiPix Flow form is quicker to set up, and Meta, Google Ads and IndiaMART have connectors of their own.

What does the lead API do?

It creates leads, and only that. A single endpoint accepts a person's email address with, optionally, their first and last name, company, a source code and consent claims. To act on what happens to a lead afterwards, such as an owner being assigned, use outbound webhooks.

Which fields can we send?

Email is required. You can add firstName, lastName, companyName and source, plus up to 12 consent claims. Any other field in the body is ignored rather than stored, so keep extra details in your own system or add them to the lead in DigiPix Flow afterwards.

How do we sign a request?

Send the API client's credential as a Bearer token, the current unix time in X-Digipix-Timestamp, and in X-Digipix-Signature an HMAC-SHA256, keyed with the credential, of the timestamp, method, path and a SHA-256 hash of the body, joined with dots. Requests more than five minutes old are refused.

What if our system sends the same enquiry twice?

Give every request an Idempotency-Key, ideally the enquiry's id in your system. When a key has been seen before, no second lead is created and the response returns the first request's correlation id with duplicate set to true. Replays are not counted against your plan's monthly requests.

What does a successful response look like?

A 202 Accepted with accepted set to true, a correlation id you can log, and a duplicate flag. The lead itself is created moments later by the same intake that handles every other source, so it appears in your lead list shortly after the response.

Does the API merge a lead with a buyer we already have?

No. A new lead that shares an email address with an existing lead is flagged as a possible duplicate for someone on your team to review, and nothing is merged on its own. Duplicate checks can be switched off for captured leads in your lead settings if you prefer.

Who owns a lead that arrives through the API?

Your assignment rules decide, just as they do for forms and ads. If assignment is limited to working hours, a lead that arrives overnight waits for the day to start, and if no rule matches, the default owner you chose for captured leads takes it.

Is there a limit on how many leads we can send?

Each workspace can send up to 120 requests a minute, and your plan may also set a monthly allowance. Beyond either, the API answers with a 429, and your system should wait and retry with the same Idempotency-Key.

Something we haven't covered? Talk to an expert

Stop exporting leads from the systems you already run

Talk to an expert — bring the portal, app or partner system your enquiries come through, and see one arrive as a lead.

  • A real person, not a bot
  • Bring your developer
  • See a lead arrive from your system
Talk to an expert