Job integrate-crm-person-and-lead-push-on-form-submit · revised 11 October 2026
Send each website enquiry into Pipedrive as a person and a lead, and never lose one
Each valid submission of one website form creates or reuses one Pipedrive person and adds one linked lead. Failed sends are kept and retried, and a lost reply is looked up before any retry.
You might be seeing
- Someone retypes each enquiry from an email into Pipedrive, and some never get entered
- A previous push created duplicate people when a visitor submitted twice
- Submissions made while the CRM was unavailable are not anywhere
No passwords, keys, card details or admin invites needed to start.
What usually happened
A form handler that calls the CRM inside the visitor's request depends on the CRM being up, under its limits and correctly authorised at that moment. If the call fails the enquiry is lost, if the visitor resubmits a second person is created, and if an API token is mistakenly placed in the page, anyone can read it. Retrying is not safe by itself either: Pipedrive's documentation shows no idempotency key or duplicate protection for creating a lead, so when a create call succeeds but its reply is lost, a blind retry creates a second lead. The fault is missing storage, matching, lookup and retry rules around one call.
Who it’s for: A founder or sales lead whose website form currently emails someone who retypes the enquiry into Pipedrive, or whose earlier automatic push has dropped enquiries during outages.
Usually starts when: Enquiries are re-entered by hand and some are late or missing, or the first automatic version lost a submission when Pipedrive was slow, rate-limited or returned an error.
The result: A test submission of the named form on staging creates one person and one linked lead with the agreed fields in a Pipedrive account you control. A second submission with the same email reuses that person and adds one lead. With Pipedrive unavailable, rate-limited or rejecting the token, each submission is stored and delivered later. When a create call's result is unknown, for example because the reply was lost, the lead is looked up by its stored submission reference before any retry, and if that lookup cannot be made the submission is flagged for a person instead of being retried blindly. No token appears in the page. Duplicates are made unlikely and findable, not impossible: Pipedrive offers no idempotency for lead creation.
Check whether this job fits
Answer from what you know about your form and Pipedrive account. It needs no tokens or enquiry data.
Checks you can run yourself
Trace one real enquiry end to end
Pick one recent enquiry and note where it arrived, who typed it into Pipedrive and how long it took. Leave out names and contact details.
Look for: The point at which it can be lost: the email, the retyping or the CRM. Include the answer in your enquiry.
What you get
- A pull request with the form handler change, the submission store, the Pipedrive client, the claim, lookup and retry job, the reconciliation check and tests
- A field-mapping table and the matching and lead rules you approved, with the API versions used
- Redacted evidence from the staging run, including the outage, lost-reply and lookup-unavailable cases
- A written note of the residual duplicate risk and how the reconciliation check finds it
- Undo steps
Included
- One website form in one existing site or app, submitting to your server, which then calls Pipedrive's API: the person calls on API v2 (add a person and search persons, because Pipedrive marked the v1 persons endpoints out of support from 1 August 2026) and the lead calls on API v1 (add a lead, which had no v2 equivalent in Pipedrive's documentation at the 11 October 2026 check) with the v2 lead search; the versions are confirmed again at agreement
- Person matching by exact email through Pipedrive's person search, creating a person only when none matches and keeping the Pipedrive person id against that email on your side, then creating one linked lead with a label and the form's message
- A saved copy of every submission before the CRM call, with its own submission reference and a status that shows pending, sending, delivered or needs attention
- A claim on each submission before it is sent (an atomic change from pending to sending, with a time limit) and one delivery at a time for any one email address, so two workers cannot both create the same lead or person
- The submission reference stored on the lead, in a custom lead field your administrator creates or, if that is not possible, in the lead title, and a lookup of that reference with Pipedrive's lead search before any retry after an unknown outcome (a timeout, dropped connection or server error); if the lookup cannot be made, the submission is flagged for a person and not retried
- Retry of calls Pipedrive clearly rejected before acting on them, such as a 429, that waits when Pipedrive asks it to, stops at an agreed number of attempts and then flags the submission
- A reconciliation check you can run on request, which compares delivered submissions with the leads found by reference and lists any with no lead or with more than one
- Mapping of the form fields to the person and lead fields you choose, using fields your Pipedrive administrator has already created
Not included
- Any other CRM: HubSpot, Salesforce and others are separate jobs (for HubSpot form duplicates, see "Stop web-form leads creating duplicate HubSpot contacts and companies"; for the whole HubSpot path from form to salesperson, see "Repair the path from web form to salesperson, end to end")
- Cleaning, merging or de-duplicating people already in Pipedrive
- Deal pipeline rules, automations, email sequences or lead scoring inside Pipedrive
- Creating custom fields or labels in your Pipedrive account: your administrator does that
- Spam filtering of the form or consent and privacy wording on it
- Contacting enquirers or any outbound messaging
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
A synthetic submission of the named form on staging creates exactly one person and one lead linked to that person, with the agreed field values and the submission reference, in the test account.
Evidence: Counts of people and leads before and after, and a screenshot of the lead showing the mapped fields and the reference.
A second synthetic submission with the same email reuses the same person and adds one more lead under the approved rule; the person count does not change.
Evidence: Counts before and after and the person's lead list.
With a stand-in service returning 429 with a wait, then success, each submission is stored at once and delivered after the wait, and the stand-in recorded exactly one lead per submission.
Evidence: Test output with the stand-in's request log and the submission statuses.
In the staging run against the real Pipedrive test account, the lead created for a synthetic submission is found by a search on its stored reference, using the field agreed for it (a custom text field, or the lead title if the custom field cannot be searched), and the field actually used is recorded.
Evidence: The search request and result from the staging run (redacted), and the recorded field choice.
With a stand-in that creates the lead and then drops the reply (and, in a second run, answers 503 after creating it), the retry looks the lead up by its reference, finds it, marks the submission delivered and sends no second create call, so the stand-in holds one lead.
Evidence: Test output with the stand-in's request log showing one create call and one lookup per submission, and the lead count.
With the stand-in creating a lead, dropping the reply and then refusing the lookup, the submission is flagged needs attention, no further create call is made, and once the lookup works again one run resolves it to the existing lead.
Evidence: Test output with the request log, the submission status at each step and the lead count of one.
Running the delivery job twice at the same moment on one submission creates one lead, and two submissions with the same new email delivered at the same moment create one person and two leads.
Evidence: Test output from a concurrent run (repeated many times, with the number stated) with the stand-in's counts of persons and leads.
The reconciliation check, run against a stand-in holding one delivered submission with no lead, one with two leads and three correct ones, lists exactly the first two and none of the others.
Evidence: The check's output beside the seeded data.
With the credential rejected, the submission stays stored with a needs-attention status and the visitor still sees the agreed confirmation; after the credential is fixed one run delivers it. A search of the page source and logs finds no credential.
Evidence: Test output, the submission status before and after, and the search results.
Sign-off. You read the mapping table, the Pipedrive counts, the outage and lost-reply test output, the reconciliation output and the note on residual duplicate risk, then sign off in writing and merge. Payment follows sign-off; your team deploys and holds the production credential.
If it fails. If the agreed checks do not pass you do not pay for this fixed scope. If the cause is a hosted form that cannot post to your server, a plan without API access or a duplicate-cleaning need, we explain the evidence and stop. Wider work needs a new written agreement.
When it fits, and when we stop
It fits when
- You have a Pipedrive account whose plan allows API access, and an administrator who can create the API credential and the fields, including one text field to hold the submission reference
- The form posts to a server you control where the call can be made, not straight from the visitor's browser to Pipedrive
- You can supply a test Pipedrive account, or accept clearly labelled test records that your administrator deletes afterwards
- You have approved how an existing email should be treated, and what a repeat enquiry creates
- Your maintainer can review, merge and deploy the change
We stop and tell you if
- The form is hosted by a third party that does not let you send submissions to your own server
- You need existing duplicates cleaned as part of the job, which is a separate data task
- The Pipedrive account has no API access on its plan and you will not change it
- Real enquirers' data could only be used for testing
What could go wrong
Before merge, closing the pull request changes nothing. After merge, reverting the commit restores the previous form handling; the submission store keeps every enquiry received, and test records in Pipedrive can be deleted by your administrator.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| An enquiry is lost when Pipedrive is slow, limiting requests or rejecting the credential. | The submission is saved first, delivery is retried with the wait Pipedrive asks for, and a failed credential flags the submission for your administrator. |
| A create call succeeds but its reply is lost, and a blind retry creates a second lead. Pipedrive documents no idempotency key for creating a lead. | Each submission has a reference stored on the lead and is claimed before it is sent. After an unknown outcome the lead is looked up by that reference before any retry, and if the lookup cannot be made the submission is flagged for a person. A test creates a lead and drops the reply. |
| A duplicate still occurs in a case the design cannot see, for example the lookup returns a wrong or incomplete answer or another process in your account creates the same lead. | This cannot be ruled out, and the handover says so. The reconciliation check lists delivered submissions with no lead or with more than one lead, so a duplicate is found rather than silent. |
| Two submissions with the same new email are delivered at the same moment and each creates a person. | Delivery is one at a time for any one email address, and the Pipedrive person id is kept against the email once known. A test delivers two such submissions together. |
| Pipedrive retires or changes an endpoint the job uses. | The persons calls use API v2 because Pipedrive marked the v1 persons endpoints out of support from 1 August 2026. Lead creation is v1 with no v2 equivalent in the documentation at the 11 October 2026 check. The client sits in one module, the handover lists each endpoint and version, and the monthly service watches Pipedrive's changelog. |
| The wrong existing person is matched among duplicates. | Matching uses exact email only and, when more than one person matches, the submission is flagged rather than guessed. |
A reviewer separate from the builder checks the diff, that the credential is only in server configuration, that a submission is stored and claimed before the CRM call, that a retry after an unknown outcome looks the lead up first and flags the submission if it cannot, that the reconciliation check works, and that the handover states the residual duplicate risk. Your authorised maintainer merges.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the form, the field mapping, the repeat-enquiry rule, who creates the credential and fields (including the submission-reference field) and the API versions to use
- Read the form handler and the place where submissions are processed today
- Write the three synthetic enquiries and the outage, lost-reply and lookup-unavailable cases first
- Build the submission store, the claim, the Pipedrive client, the lookup before retry, the retry job and the reconciliation check on a branch with tests
- Run the synthetic enquiries on staging against the test account, then the outage and lost-reply cases against a stand-in that can create a lead and drop its reply, and capture the evidence
- Have an independent reviewer check the diff and evidence, then hand over with undo steps
An enquiry books nothing and charges nothing. Scope, access route and checks are agreed in writing first.
Need to keep it working?
If enquiries are important, ask about the monthly service that watches the integration, credentials and quotas.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Pipedrive's own documentation for persons and leads shows the calls this job uses (check which API version each page documents), and your developer can follow it directly. developers.pipedrive.com
- An automation tool with a Pipedrive connection may cover a simple form without custom code; check whether it can keep enquiries when Pipedrive is unavailable.
Questions
Why store the enquiry before calling Pipedrive?
So that a CRM outage, limit or rejected credential cannot lose it. The call can be retried later from the saved copy.
What if a visitor submits twice?
The same email reuses the same person and adds the lead or note your rule chooses, so no second person is created.
Can it promise there will never be a duplicate lead?
No. Pipedrive's documentation shows no way to make lead creation safe to repeat, so if a reply is lost the job looks the lead up by its stored reference before retrying, and if it cannot look it up it flags the enquiry for a person. That makes duplicates unlikely, and the reconciliation check lists any that still occur.
Can it work with HubSpot or Salesforce?
Not in this job. Each CRM has different matching and limit rules and needs its own scope. For HubSpot, "Stop web-form leads creating duplicate HubSpot contacts and companies" and "Repair the path from web form to salesperson, end to end" are the related jobs.
Do you need my Pipedrive login?
No. Your administrator creates an API credential for a test account. We never need your login.
Send an enquiry
Send us
- The website platform or framework and the form's field names
- What currently happens to an enquiry after submission
- Whether a repeat enquiry from the same email should add a lead, a note or nothing
- Do not send API tokens, real enquiries, exports of your people or code in the first enquiry
Later, once you agree
- Read access to the code through a company-controlled repository or export, and a staging environment you control
- A Pipedrive API credential for the test account, created and held by you, and the custom fields already created
- Three synthetic enquiries, one with an email that already exists in the test account
- A time to run the outage cases against a stand-in service
You own the Pipedrive account, the credential, the form and every enquiry. We work on a branch through a company-controlled identity with a test account credential you create. The production credential stays in your secret store.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “integrate-crm-person-and-lead-push-on-form-submit” as the subject.