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
- 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
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.
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.
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.
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
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
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
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
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 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
Pass on what the person agreed to, with the proof
If your portal or app asked for permission, send it along. Each claim names the purpose, marketing or sales outreach, the channel, email, SMS or WhatsApp, and whether it was granted or withdrawn. A grant must name the notice version the person saw, and the record keeps which API client asserted it. Sending no consent records nothing.
- Up to 12 consent claims on each lead
- Granted or withdrawn, per purpose and channel
- A notice version required for every grant
- No claim is never treated as an opt-out
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
From a new API client to an assigned lead, in five steps
- STEP 01
Create an API client
Name it after the portal, app or partner system that will send leads.
- STEP 02
Store the credential
Copy it once into that system's secrets; DigiPix Flow keeps only a hash.
- STEP 03
Sign and send each enquiry
POST the lead with its signature headers and your own id as the Idempotency-Key.
- STEP 04
Let intake do the rest
Duplicates are flagged, the lead is scored and your rules assign an owner.
- STEP 05
Reply while it's fresh
The owner sees the new lead in their list and picks up the conversation.
The lead API vs a nightly export
| What it covers | A nightly export imported by hand | |
|---|---|---|
| When the lead arrives | The next morning, if someone remembers | As soon as your system sends the request |
| Who does the work | A coordinator downloads, cleans and uploads | Your system sends it with no one in between |
| Sent twice | Two rows, two leads, two calls | One lead, recognised by its Idempotency-Key |
| Which system it came from | Lost once the file is merged with others | A source code on every lead |
| Duplicates of existing buyers | Spotted later, if at all | Flagged for review when the lead arrives |
| Owner | Shared out by hand after the import | Assigned by your rules, in working hours |
| Consent | A column nobody can trace back to a notice | Claims recorded with the notice version |
Works alongside
Use the lead API for systems you control, forms for your website, CSV import for the lists you already hold, and outbound webhooks when your systems need to hear back.
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
Keep exploring
Visit the blog- INTEGRATIONSCRM Public APIAPI clients, scopes, secret rotation and the audit trail in detail.See the integration
- INTEGRATIONSOutbound CRM webhooksSigned notifications to your systems when leads, contacts or deals change.See the integration
- INTEGRATIONSWebsite form to CRM integrationHosted and embedded forms for the enquiries that start on your site.See the integration
- INTEGRATIONSCSV lead importBring in the lists you already have, with duplicate rows skipped.See the integration
- PRODUCTLead inbox for every sourceWhere leads from every source are checked, scored and routed.See how it works
- FEATURESDuplicate lead checksHow possible duplicates are found and reviewed before anyone merges them.Explore the feature
GUIDELead Source Tracking: How to Know Which Campaigns Bring Real CustomersA practical guide to lead source tracking: tag links with UTMs, keep Google and Meta click IDs, pass them through hidden form fields, record offline sources and report leads by source.Read the guide
GUIDEIndiaMART Lead Management: How to Turn Buyer Enquiries into OrdersA practical guide to IndiaMART lead management: reply to buyer enquiries fast, qualify them in one call, follow up on a plan and pull them into your CRM automatically.Read the guide
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




