EspoCRM web-to-lead capture and double opt-in setup

How EspoCRM web-to-lead capture brings website leads into the CRM

EspoCRM can create leads directly from web forms and API calls, so a website enquiry becomes a lead record with an owner instead of an email in a shared inbox or a row in a spreadsheet. Optional double opt-in adds a confirmation step before a contact is treated as a confirmed subscriber. Teams need this when marketing and sales are losing track of enquiries, when follow-up depends on who happened to read a mailbox, or when they cannot show where a contact's details came from. The capture path is the same whether the form sits on a marketing site, a landing page or a partner portal, so the design work is mostly about which fields arrive, who receives them and what happens next.

Web-to-lead does not replace the decisions that sit around it. Your legal counsel or privacy lead still needs to approve the consent wording, the privacy notice linked from each form, the lawful basis for each kind of contact and the retention period for leads who never confirm. EspoCRM stores what you send it and records the outcome of the confirmation flow, but it does not decide whether a form is compliant. Your web team also needs to protect the endpoint against spam and automated submissions, since EspoCRM will accept what the form posts unless you add controls in front of it. Confirm with your counsel and your web platform owner before the first form goes live.

Which web-to-lead configuration fits which intake pattern

This table compares the main ways to get website leads into EspoCRM, from standard form posting to API-driven capture and the choice between target lists, campaigns and double opt-in. Read each row for when the pattern fits, what your team must keep up, and the main trade-off. Confirm exact field names and settings in the version you run before you commit to a design.

Pattern	When it fits	What the team maintains	Main trade-off
Standard HTML form posting to Lead Capture	Marketing site with simple forms and a small set of lead fields	Form markup, the Lead Capture entry point and its field names, spam controls on the form	Fast to launch, but field changes on the site must match CRM settings
API-driven capture from a custom site or backend	Custom applications, product sign-ups or forms that need server-side validation	Integration code, API user with limited role, error handling and retries	More control over payloads, but you own the code path and its monitoring
Target lists to group leads	Simple grouping for newsletters or event follow-ups without tracking spend	List membership rules and who can add or remove contacts	Easy to manage, but gives little view of which activity produced a lead
Campaigns to group leads	Tracked marketing activity where you need to measure response by source	Campaign setup, naming conventions and linked target lists	Better attribution, but requires disciplined campaign hygiene from the start
Double opt-in	Consent must be confirmed by the subscriber before marketing mail is sent	Opt-in email template, placeholder use, and checks that confirmation links work in your mail setup	Stronger consent evidence, but some subscribers never confirm and lists shrink
Single opt-in	Lower-friction sign-up where your legal review accepts the consent basis	Consent wording on the form and records of when and how consent was given	Fewer drop-offs, but weaker proof of intent if consent is later disputed
Team assignment on capture	Leads should route to a named team or user as soon as they arrive	Assignment rules and team membership as sales staffing changes	Speeds first response, but needs review when team structures change

Setting up Lead Capture and double opt-in in order

This sequence takes a website form from an unconfigured EspoCRM instance to a tested lead capture flow. Each step closes with a check, so the team can confirm the entry point, permissions, field mapping, routing and opt-in confirmation work before the form goes live.

Create the Lead Capture entry point
An administrator creates a Lead Capture entry point in EspoCRM's administration area and sets the target entity to Lead. Confirm the exact option names and settings for your version in the Web-to-Lead documentation before you start. Decide which consent and opt-in options the entry point should use, because later steps depend on them. The step is complete when the entry point is saved, appears in the list, and is set to the expected target entity.
Create a dedicated API user with minimal permissions
Create a separate API user for the form integration instead of reusing an administrator or a person's account. Give the user a role that allows creating leads and only the read or update access the flow needs. Prefer HMAC authentication, because EspoCRM's documentation describes it as the most secure option and basic authentication as not recommended. Restrict the user by IP address where your network allows. The check is that the credentials can create a lead and are refused for other entities and actions.
Map payload fields to lead fields
Document every field your form sends, such as first name, last name, email, company, country and consent flag, and match each one to a lead field. Mark which fields are required and what format each value must follow. Include a field that records the consent source if your privacy process needs it. The check is a test payload that fills each mapped field on the new lead, with no values landing in the wrong field or being dropped.
Define the target list or campaign
Decide whether new leads should join a target list, a campaign or both, so marketing can see where each contact came from and which mailings it may receive. Create that target list or campaign and attach it to the entry point. Pending contacts should not be added to mailing lists until the opt-in is confirmed, so confirm how your setup handles that before go-live. The check is that a test submission places the lead in the expected list or campaign with the right status.
Configure team assignment and distribution
Assign new leads to a team and, if you distribute them, define the rule that picks the owner, such as round-robin, region or product interest. Rules that change ownership automatically may depend on workflows, which are part of the Advanced Pack, so confirm the edition and licensing that applies to your deployment. Test each branch with sample data. The check is that each test lead lands on the expected team and user, and that the record shows the correct owner.
Build the double opt-in email template
Create an email template for the confirmation message and include the {optInUrl}, {optInLink}, {optInDate} and {optInTime} placeholders the double opt-in process uses. The link is what the subscriber clicks to confirm, so keep the wording clear about why the message was sent and what happens after confirmation. Review the template with your legal or privacy team. The check is a rendered test email that shows the link, date and time correctly and resolves to the confirmation page.
Test submission and confirmation flow
Submit a test form with a mailbox you control, then open the confirmation email and click the link. Check that the lead's opt-in status changes, that the date and time are recorded, and that the lead stays in its assigned team and list. Also test an unconfirmed submission and a rejected request, such as one with invalid credentials. The sequence is complete when the confirmed record, the stored timestamps and the audit trail match what your process expects.

How lead distribution and team assignment decide who sees each lead

Every web-to-lead submission lands in a team, an owner and a status before anyone reads it. The decisions below set those defaults, and each one changes who sees the lead and how quickly. Confirm the exact options in your EspoCRM version and installed extensions before you fix the design.

Owning team for incoming leads

Decide which team receives leads from each form, campaign or API source. Web-to-lead entry points can assign a team, so a single shared intake team and per-product teams produce very different visibility. Check that the team you pick can see the lead entity through its roles, and test with a submission from each source before launch.

Round-robin or manual assignment

Choose whether each new lead goes to a named owner by hand or is distributed automatically. Automatic distribution needs a rule that your EspoCRM setup supports, so confirm whether the option is built in or comes from an extension. Manual triage suits small teams with low volume, while rules suit high volume but need a fallback owner for leads that match nothing.

Handling duplicates against existing contacts

A visitor who already exists as a contact or lead should not create a second record that splits the sales history. Decide whether a match updates the existing record, creates a new lead, or routes to a person for review. Test matching on the fields you actually collect, such as email address, and document the rule so sales and marketing read it the same way.

Field defaults for source and status

Set default values for lead source, status and any campaign reference so reports can separate web traffic from other channels. Defaults that are missing or inconsistent make pipeline and attribution reports unreliable. Agree the status values with the sales team before go-live, and check that each entry point sets the same source values.

Owner notification

Decide who is told when a lead arrives and through which channel. Email notifications depend on your mail configuration and background jobs, so confirm that outbound email and scheduled jobs run in your environment before you rely on them. Silent assignment is a common gap: a lead assigned to an owner who never logs in will wait without anyone noticing.

Handling unconfirmed leads

Leads that have not clicked the double opt-in link should follow a defined path, such as staying in a pending status, being excluded from campaigns, or being removed after a set period. Decide who owns that cleanup and how it is recorded. Confirm the exact behavior for unconfirmed records in your version, since it affects both marketing lists and privacy obligations.

How the double opt-in confirmation works for subscribers

When double opt-in is enabled for a web-to-lead form, EspoCRM sends an automatic email to the new subscriber, and the subscriber confirms by clicking a link inside it. The confirming click is the event the deployment relies on, so the email is the part of the flow that most needs to be right. According to the EspoCRM double opt-in docs, the confirmation email is built from an email template you define, and that template is where the confirmation link is placed. The Web-to-Lead documentation describes how the template is linked to the capture form, which your team should verify against the EspoCRM version you run.

The template supports the placeholders {optInUrl}, {optInLink}, {optInDate} and {optInTime}. {optInUrl} gives the raw confirmation address, {optInLink} gives a clickable link, and the date and time placeholders record when the opt-in was generated. Confirm in a test instance which placeholder your mail client renders correctly, and check that the link works when the email is opened on mobile devices. Decide with the business owner which sender name, subject line and language variants the template needs, and make sure the wording states clearly what the subscriber is agreeing to receive.

Because the template is the subscriber's first written contact with your organization, the privacy owner should review its wording, purpose statement, sender identity and any link to a privacy notice before go-live. The same person should confirm what the confirmation changes in the record and how that status is used in later marketing steps, since the template alone does not decide who may be contacted. Ask the privacy owner to sign off on the final text and keep a dated copy of the approved version alongside the form configuration.

Protecting the public capture endpoint and personal data

A web-to-lead endpoint accepts input from anyone on the internet, and the records it creates hold personal data that feeds marketing consent. The controls below work together: limit what the endpoint can do, authenticate it properly, filter abuse before it reaches the CRM, and restrict who can read what comes in.

Create-only API user

Run the capture flow under a dedicated API user whose role allows creating Lead records and nothing else. Confirm that it cannot read, edit or delete existing leads, contacts or accounts, and that it has no access to user, settings or Entity Manager areas. If the capture form is compromised, the attacker should gain a write-only path into one entity rather than the whole CRM. Test this by attempting a read with the same credentials before go-live.

Strong API authentication method

The EspoCRM API docs describe HMAC as the most secure of the supported methods and describe basic authentication as not recommended. Prefer HMAC for any server-side call that writes leads, and keep the secret out of browser code wherever possible. Ask your engineers which method the form handler uses and whether the secret is stored in a secrets manager. Rotate credentials on a defined schedule and after any staff change.

Spam and bot submissions

Public forms attract automated submissions that fill the lead queue, trigger double opt-in emails to fake addresses and damage your sender reputation. Place a bot challenge or honeypot field in front of the endpoint and reject submissions that fail it before they create records. Decide in advance how rejected attempts are counted and reviewed, since a sudden spike in confirmation emails is an early warning sign.

Rate and origin controls at the proxy

Enforce rate limits and allowed origins at the reverse proxy in front of EspoCRM, not only inside the application. Restrict cross-origin requests to the domains that host your forms, and limit request size and frequency per source address. Confirm the chosen limits with your marketing team so legitimate campaign traffic is not blocked. Document the configuration in version control so changes are reviewed.

Logging of submissions

Keep a record of each submission attempt, including accepted, rejected and failed requests, the source address, the form identifier and the time. Store these logs separately from personal data where possible, and set a retention period that your privacy notice supports. Logs help you explain how a given lead entered the system and why a consent confirmation was sent, which matters when a data subject asks.

Lead data access by role

Captured leads contain contact details and consent status, so restrict who can view them through roles and teams. Give sales users access to leads assigned to their team, give marketing access to consent fields, and keep administrators off daily lead work. Require two-factor authentication for every staff account that can manage capture settings or export records, as the EspoCRM security docs recommend, and avoid running daily work from admin accounts.

Questions teams ask before setting up web-to-lead capture

How much more effort is a basic web form setup than a custom API integration?

A basic web-to-lead form is the lighter path, because EspoCRM generates an HTML form from the Lead Capture settings and your web team only needs to place it on the page. A custom API integration adds work on both sides: the developer builds the request, handles authentication with an API user, validates payloads, manages errors and retries, and tests failure cases. The gap widens when the form must write to custom entities, feed campaigns or trigger before-save logic. Ask any partner to split the quote into form configuration, API work and testing, so you can see which part you are actually paying for. The EspoCRM web-to-lead documentation is the best starting point for checking which path fits your site.

What drives the cost of web-to-lead capture?

Cost follows the number of moving parts, not the existence of a form. The main drivers are:

The number of forms and websites that submit to the CRM, and how many differ in fields and consent wording
Field mapping, including custom fields, dropdown values and any transformation before save
Custom entities or layouts that the captured data must reach
Email template localization for the double opt-in message, with one template per language and market
Testing across sites, browsers, mail clients and consent paths

No price is given here because none is supplied for this work. Ask for a written scope listing each form, each field and each language, since that list is what a fixed-scope quote is built from.

What does our team need to provide for the work?

The work needs four inputs from your side before build starts. First, a marketing owner who decides which forms exist, what each one captures and which campaigns or target lists they feed. Second, privacy sign-off on consent wording, the double opt-in message and retention of unconfirmed contacts, because those choices carry legal weight that a partner cannot settle for you. Third, web developer access to the pages that host the forms, plus the ability to deploy changes. Fourth, a test instance of EspoCRM that mirrors production, so submissions and confirmation emails can be checked without polluting live data. Confirm each of these owners by name in the scope document.

Can our own team set up web-to-lead capture without a partner?

Yes, a team with an administrator who knows the EspoCRM Entity Manager and a web developer can set up a single form with a standard set of fields. The risk lies in what gets skipped. Teams often leave out the confirmation email template, the duplicate handling, team assignment rules and the test of an unconfirmed record, then discover the gaps after launch. A partner is most useful when several forms, custom fields, multi-site hosting or privacy review are involved. Whichever route you choose, write down the expected behavior for each submission path before anyone builds it, and check it against the live form.

Which EspoCRM version and extensions must we confirm before we start?

Confirm the exact EspoCRM version you run or plan to run, because Lead Capture behavior, API options and double opt-in details are documented per release and the current stable line changes over time. Check the version against the EspoCRM releases page and your own upgrade plan. Also confirm whether you depend on the Advanced Pack for workflows that react to new leads, and whether any email integration will send the confirmation message. Each of these affects which steps appear in the build and which ones need separate testing.

How do we verify that double opt-in works before we go live?

Verify it end to end with test addresses on the test instance. Submit the form, confirm that the lead is created with the expected status, check that the double opt-in email is sent from the right template, and click the confirmation link to confirm the record changes state. Also test an unconfirmed address, a repeated submission and a link that is used after it expires or after a second click. The confirmation template uses the placeholders documented for opt-in URLs, links and dates, so check that each one renders in every language you publish. Keep the test results as evidence for your privacy file.

Limits to confirm in your environment before go-live

Web-to-lead capture and double opt-in depend on the installed EspoCRM version, the mail and scheduling setup around it, and the data rules your organization applies to every new contact. The cards below cover the items to verify before a form goes live, and each one should be confirmed against your own environment rather than assumed from the feature description.

Behavior on your installed version

Confirm that the Lead Capture entry point, payload fields and double opt-in flow behave as documented in the exact EspoCRM release you run. Current releases include the 10.0.x line, and behavior can change between majors, so test the full path on a staging instance built from the same version as production. Record the version and the test results in your change file.

Email delivery and cron

Opt-in confirmation depends on outbound mail and scheduled jobs. Verify that the instance sends mail through your approved relay, that SPF, DKIM and DMARC are set for the sending domain, and that cron runs on the schedule the server documentation requires. A confirmation email that never leaves the server means the subscriber is never confirmed, so test delivery to several mail providers before launch.

Duplicate handling for leads

Decide what happens when a form submission matches an existing lead, contact or account. Check whether the capture flow creates a new record, updates an existing one or stops, and confirm how the duplicate check matches on email address and other fields. Unchecked duplicates inflate lead counts and can send a second confirmation to someone already in a target list.

Consent records and legal basis

Confirm with your privacy lead which legal basis covers each form and how the opt-in timestamp and confirmation data are stored against the contact. The double opt-in template can use placeholders for the opt-in date and time, so check that those values are retained as evidence and that the retention period matches your policy. Legal interpretation belongs to your counsel, not to the configuration.

Extensions and add-on dependencies

List every capability your flow needs, such as target list handling, campaign assignment, workflows that route leads, or external mail tools, and confirm which ones come from core and which need an official extension. Confirm whether your edition and plan include those extensions before you design the process around them, since add-on availability differs between self-hosted and cloud deployments.

Running lead capture after launch

Lead capture usually breaks quietly, so the first ongoing task is watching for the gaps. Someone on the operations side should review leads that arrive without an owner, leads still waiting on double opt-in confirmation, and any submissions that failed before they reached EspoCRM. Confirm where your web server and EspoCRM logs record rejected API calls, and agree who reads them and how often. Unconfirmed leads deserve their own review, because a lead that never clicked the confirmation link cannot be contacted for marketing, and a long backlog usually means the email template, the sending mail setup or the background jobs need attention.

Field mapping and credentials need a regular review. Every change to a website form, such as a renamed input, a new dropdown or a removed field, can leave a payload field empty or pointing at the wrong attribute in EspoCRM. Compare the form fields against the payload fields your Lead Capture entry point expects after each website release. Rotate the API user's credentials on a schedule your security team sets, and confirm that the API user still has only the permissions needed to create leads. Ask your implementation partner or internal admin to document each rotation so the website team knows when to update its configuration.

Test capture after every EspoCRM upgrade and after every change to the form or email template. Run the test on a copy of the production instance, not on production itself, so a broken form or template is found before it reaches prospects. Submit a test lead through each entry point, confirm the target list, campaign and team assignment, and check that the opt-in email renders the {optInLink} placeholder correctly and that its confirmation link works. Review the EspoCRM Web-to-Lead documentation with each upgrade, since placeholder names and settings are the first things to verify. Keep the email template under review as your privacy notice and sender details change.

Where to read the official documentation

Four references cover this topic, and they connect in a fixed order: the Web-to-Lead page defines what a capture point accepts, the API page defines how that point authenticates, and the security page defines who may change the settings. Read them against the EspoCRM version you actually run, because capture options and permission names have changed between releases.

Web-to-Lead entry points

Start here for the Lead Capture entry point, the form and API call options it exposes, and the payload fields it accepts. Note which fields are mandatory, how the target team or assignment is set, and where a target list or campaign is attached. Record the exact field names your form will send, because a misspelled field is often dropped silently. Check the double opt-in email template placeholders on the same page before you write the confirmation message.

Double opt-in confirmation

Use this card to confirm how the confirmation link is generated, how long it stays valid, and what happens when a subscriber never clicks it. Verify the opt-in link placeholder works in your template before launch, and test the full path from form submission to confirmed status. Consent records are only as useful as the evidence behind them, so confirm which timestamp fields the instance stores.

API authentication methods

Capture calls that come from a website or middleware reach EspoCRM through the REST API, so the authentication method matters. The API docs describe API key, HMAC and basic authentication through dedicated API users. Choose HMAC where your integration can sign requests, and treat basic authentication as a last resort because the docs do not recommend it. Ask your team which method the form backend will use before writing code.

Permissions and security settings

The security docs cover the controls that protect a public capture endpoint: password policy, two-factor authentication for staff, limits on token lifetime and IP-based access restrictions. Review the API user role so it can create leads but cannot read or delete the rest of the database. Confirm that these settings match your internal policy, since the documented recommendations are starting points rather than a complete control set.

How DeployOpen scopes a web-to-lead project

DeployOpen scopes a web-to-lead project as a written, fixed-scope engagement agreed before any configuration starts. The scope names each form or API caller that will send leads, the Lead Capture entry points that receive them, the payload fields each source sends, the target list or campaign that records join, the opt-in email template, the team assignment and distribution rules, the test plan and the handover. Because the scope is written, your team can check each item against its own consent process and data inventory before anyone builds it, and changes after sign-off go through a change request rather than informal edits in the live CRM.

The scoping conversation focuses on decisions that are hard to undo later. These include which fields are mandatory on each form, how incoming records are matched against existing contacts so duplicates are not created, which team owns each lead source, and whether the double opt-in confirmation is sent for every source or only for some. DeployOpen also confirms with you which language the opt-in template must use, which placeholders it will carry (such as {optInUrl} and {optInLink}), and what happens when a subscriber never confirms. Your own marketing and legal owners should sign off on the wording and on what counts as consent, because DeployOpen prepares the configuration and evidence but does not provide legal consent advice or attestations. Independent auditors and certification bodies make those determinations.

The written scope also states what you provide and what you receive. You supply the test accounts, the sample payloads from each form or integration, the list of users and teams, and a named approver for test results. DeployOpen delivers the configured entry points, templates, assignment rules, a test record set and documentation of how each element was verified. Ask for those deliverables by name in the quote, and confirm with your own security team how the endpoints are exposed and protected before the scope is signed, since the web-to-lead entry points are reachable from the public internet by design.

How DeployOpen delivers EspoCRM lead capture

DeployOpen plans, builds and hands over EspoCRM web-to-lead capture and double opt-in inside infrastructure you control. We start from how your sales and marketing teams route leads, then configure the capture points, consent flow and assignment rules around that process, with testing and documentation before handover.

How we scope

Written scope lists each web form or API source that will send leads into EspoCRM
Scope defines payload fields, required consent wording and the double opt-in email template
Team assignment and lead distribution rules are agreed in writing before any build starts
Engagements are fixed-scope, with deliverables and timelines confirmed in writing

How we build

Lead Capture entry points are configured for each approved web form or API caller
Target lists, campaigns and double opt-in templates are built and tested with sample submissions
Duplicate handling and field mapping are checked against your existing lead layout
Test submissions are traced from the website through confirmation to the assigned team

How we hand over

Documentation covers each capture endpoint, payload field, consent step and assignment rule
Administrators receive a walkthrough of how to adjust templates and distribution settings
Credentials for API callers are issued to dedicated API users with limited permissions
Your team confirms the consent wording and retention rules with its legal or privacy owner

How we support

Ongoing support, upgrades and continuous testing are available as a retainer
Support can cover changes to forms, payload fields and assignment rules after go-live
Re-testing follows each EspoCRM upgrade so capture and confirmation keep working
Support scope and response arrangements are set out in the written retainer agreement