What Is a Webhook? Connecting Forms, CRMs, and Automations

A webhook is an HTTP notification sent when an event happens. In a service business, it can carry a quote request from a form to an automation that validates the contact and passes it to a CRM. The webhook delivers a message. The rules that decide whether to create a record, update one, notify a colleague, or stop processing belong to the integration.

That distinction prevents a common misunderstanding: adding a URL to a form does not create an organized inquiry process by itself. You need to define which data travels, how the recipient recognizes the sender, what a successful response means, and how to handle a request received more than once. For a business commissioning an automation, these are acceptance criteria. For the person building it, they are operating requirements.

Webhook, API, or polling: who starts the exchange?

An API provides operations through which systems exchange information. A webhook generally uses an HTTP endpoint to notify a recipient without waiting for it to ask repeatedly whether anything has changed. With polling, a scheduled process looks for new records at intervals. These approaches can work together: receive a notification, then call the API to retrieve the complete record.

Imagine a form containing a name, email address, and requested service. When a submission is completed, the form tool sends a request to the configured URL. The automation receives a data payload, often JSON, and returns an HTTP response. Stripe’s webhook documentation illustrates event delivery and explains operational concerns including signature verification, duplicate events, and delivery order. Those details must still be checked for the provider you actually use.

The minimum path from a form to a CRM

A useful workflow has five identifiable stages: receive, validate, normalize, look up the record, and save the result. Notify the team after the relevant record has been saved. This prevents a polished notification from hiding a contact that never reached the CRM. It also helps locate failures without resending everything indiscriminately.

1. Receive: the form sends the event to the integration endpoint.
2. Validate: the integration checks authentication, required fields, and message structure.
3. Normalize: remove unnecessary whitespace and standardize the identifiers used for lookup.
4. Look up and route: decide whether to update an existing contact or create a new one.
5. Record the result: save the resulting identifier and final processing state for follow-up and controlled retries.

An email address can help locate a person, but it does not necessarily identify a request. The same customer may ask about two services at different times. Store the contact identifier separately from the opportunity or request identifier. If families, teams, or businesses share an address, agree on grouping rules before automating record creation.

A sample message with a clear purpose

For a website design inquiry, a simple payload might contain the fields below. These names illustrate a data contract between systems; they are not universal form fields. Define your contract before configuring the destination, and send only what the task requires.

{
  "event_id": "request-1042",
  "type": "quote.received",
  "contact": {
    "name": "Example Customer",
    "email": "customer@example.com"
  },
  "service": "business_website"
}

The event_id field lets the integration recognize a repeated message. The type describes what happened, and the contact fields help locate the customer record. Avoid a bare sequential number if two sources could generate the same value. A combination of source and identifier, or a unique identifier persisted by the sender, needs to fit the integration’s strategy.

Do not include website passwords, CRM tokens, or identity documents just because a form allows them. Credentials belong in protected service configuration. If the form accepts attachments, check whether the webhook delivers the file, a temporary URL, or metadata only. Each arrangement needs different handling at the destination, including any expiry or access requirements.

Set up receiving in n8n

In the n8n editor, add a Webhook node, select the HTTP method expected by the sender, such as POST, and choose a recognizable path. The Webhook node documentation distinguishes test and production URLs, authentication options, and response modes. Use the test URL while inspecting a development execution.

Start listening for a test event, copy the URL shown, and send an authorized test form submission. Open the node output and locate the received fields before writing expressions in later nodes. Map the structure that actually arrived: an email at body.contact.email is not necessarily available as email at the root of the item.

Next, add validation and the CRM lookup. Inspect each branch: contact found, contact absent, and invalid data. Configure creation or updating only on the appropriate branch. Once testing is complete, make the workflow available using the activation or publishing mechanism for your version, and change the sender to the production URL. The temporary test endpoint is not the address for ongoing operation.

“Received” and “completed” are different responses

If the automation replies immediately, the sender knows the endpoint received the event; it does not prove that the CRM saved the contact. If the response waits for the whole workflow, a slow CRM may exceed the form tool’s timeout. Define the response contract, and track processing in an internal record when you acknowledge the request early.

One approach is to acknowledge receipt after persisting the request in an appropriate queue or database, then let later processing update its state. That requires real infrastructure and failure handling. Returning success before storing anything can lose the inquiry if processing stops. For short workflows, an explicit final response may be sufficient if it remains within the sender’s timeout.

Design for duplicates and retries

A connection can fail after the CRM has saved a record but before the sender receives confirmation. If the sender retries, creating the contact again would be an integration error, not a new customer intention. Safely look up or reserve the event identifier, record its processing state, and return a consistent result when the same event arrives again.

A lookup followed by creation does not solve concurrency by itself. Two executions can check at the same moment and both find no existing record. Use the destination’s appropriate uniqueness constraints, idempotency support, or atomic operation. Separate temporary failures that may be retried from invalid messages that require correction. Retain enough information for investigation without exposing customer details in public logs.

Also distinguish retrying a failed CRM call from replaying the entire workflow. If a previous step already sent a customer message, replaying every step can send it again. Record which actions completed and define where a retry resumes. The same event identifier should help preserve the intended outcome rather than merely appear in a log.

Protect the endpoint and monitor the result

Knowing a URL should not be enough to create requests in your CRM. Configure authentication supported by the sender and, when offered, verify the message signature according to that provider’s documentation. Signature checks often depend on the exact received body; do not invent validation by comparing transformed fields. Use HTTPS, and keep secrets out of screenshots, articles, and shared messages.

Record the time, source, event identifier, outcome, and resulting CRM identifier. Decide who receives a failure alert and how they resume the item. A dashboard full of successful executions can help, but acceptance testing should locate the request at the destination and inspect the saved fields. If the objective is handling quotes, check the assigned owner and pipeline stage too.

Frequently asked questions

Can a webhook work if my form tool has no API?

The tool needs some way to send the event, either directly or through a supported integration. It may expose outgoing webhooks without a general-purpose API. If no supported mechanism exists, another integration approach, such as polling through an available service interface, may be needed. Creating a receiving URL alone does not make the form send data.

Can the same event arrive twice?

Yes. Delivery policies depend on the sender, but repeated delivery and network failures should be part of the design. Use a persistent event identifier, processing-state tracking, and record operations that do not create a second inquiry accidentally. Do not assume that every repeated message represents a separate lead.

Do I need to code to use a webhook?

Visual tools reduce the code needed to receive and map fields. You still need to understand the data contract, permissions, error handling, and business rules. The more sensitive or concurrent the operation, the more important implementation review becomes. A connection that works once is not the same as one that handles failures safely.

When a webhook makes sense for your business

Use a webhook when there is a defined event, the source can notify you about it, and the destination has a clear process for handling the data. For a quote form, the desired outcome is a traceable request linked to the right contact and routed to the person responsible. Start with that short path, test failure states, and only then expand the automated actions.

If the form belongs to a campaign, first make sure the page explains the offer and next step. See when to use a landing page for a service business. Need help connecting that page to your systems? Talk to Josué about forms and CRM integration.