How to connect your website to Odoo, your CRM, bookings and payments

To connect your website to Odoo or another CRM, the website’s server hands each enquiry over in one of three ways: by calling the CRM’s API, by sending it through a webhook to an automation service, or by emailing it to an address the CRM turns into a lead. For Odoo, the two direct routes are its JSON-2 API with an API key, and a sales team’s email alias. Whichever you choose, map the fields that matter, keep a second copy so a CRM outage cannot lose the lead, and keep the account in your own name.

This guide is for businesses that already use a CRM, a booking system or a payment provider and want the website to feed it, rather than retyping enquiries by hand. If you are not sure you need a CRM at all, start with our guide to whether you need a CRM yet, which covers choosing one and setting it up so it is not a chore.

Three ways a website hands a lead to a CRM

Route	How it works	Good for	Watch for
The CRM’s API	The website’s server calls the CRM directly and creates the lead, with a key the CRM issues	Full control over every field, tags and source	The key must live on the server, never in the page, and the plan must include API access
A webhook	The form sends each enquiry to a web address an automation service gives you, which then creates the lead	Connecting to a CRM without writing code against its API	One more company holds your enquiries: check where it keeps them, and add it to your privacy notice
An email the CRM reads	The enquiry is emailed to an address the CRM watches, which turns each message into a lead	The quickest route, and it needs almost no set-up	Less control over the fields: test which details land where

The API route, and what it means for Odoo

An API is a standard way for one program to ask another to do something, in this case “create a lead with these details”. It is the route that gives you the most control, because the website decides exactly which field gets what.

For Odoo, the current route is the External JSON-2 API, new in version 19.0. Odoo’s documentation (version 20.0, checked in November 2026) describes posting a JSON request to /json/2/<model>/<method>, with an Authorization header that carries the word bearer followed by an API key. Three things in that documentation matter before anyone quotes you an integration:

• Your plan. “Access to data via the external API is only available on Custom Odoo pricing plans. Access to the external API is not available on One App Free or Standard plans.” If you are on Odoo Online, check your plan first.
• The older endpoints are going. The XML-RPC and JSON-RPC endpoints (/xmlrpc, /xmlrpc/2 and /jsonrpc) are deprecated, and the documentation schedules their remaining services for removal in Odoo 22 (autumn 2028) and Odoo Online 21.1 (winter 2027). Many older tutorials still use them, so new work should start on JSON-2.
• Keys expire. Each API key needs a description and a duration, and the documentation says it is “not possible to create keys that last for more than three months”, so a long-running connection needs its key replaced at least every three months. Give the website a key for a user of its own, with as few rights as the job needs, never a person’s password.

The webhook route

A webhook is simply a message one system sends to a web address when something happens. Many automation services give you an address to post a form to, then pass the details on to your CRM. It works, and it can save writing code. The cost is a third company in the middle holding every enquiry, so check where it keeps data, whether it signs a data processing agreement, and what happens to enquiries when it is down.

The email route, and Odoo’s email aliases

The simplest route is an email the CRM reads. In Odoo, each sales team can have its own email alias: Odoo’s documentation says that “when messages are sent to this address, a lead (or opportunity), is created with the information from the message”, with the subject as the lead’s title and the email address taken from the message. You choose who may send to the alias, from “Everyone” down to known contacts only.

It is quick to set up, but you get less control than through the API. Test what happens when the message comes from your website’s form rather than from the customer directly, so the customer’s address, not the form’s, ends up on the lead. Note too that if the Leads feature is not switched on in Odoo’s CRM settings, alias messages arrive as opportunities instead.

What to map from the form to the CRM

A lead is only useful if the right details land in the right places. This is the map we work from:

On the form	In the CRM	Why it matters
Name, email, phone	The contact on the lead	So the follow-up reaches the person
Business name	The company on the lead	So it links to the right customer if they come back
Their message	The lead’s notes, kept as written	The enquiry itself, in their words
The service they asked about	A tag, or the lead’s title	So the right person picks it up, and you can count enquiries by service
The page and source they came from	The lead’s source and medium	So you can see which pages and channels bring work
How they asked to be contacted	The lead’s notes	So someone who asked for a call gets one
Any marketing consent	A consent record of its own	So you can prove who agreed, when, and to what

Consent deserves its own care. Replying to an enquiry does not need consent, but adding someone to your newsletter does. If your form offers that as a separate tick box, record it properly: the ICO’s guidance asks you to keep “the name of the individual, or other identifier”, the time they consented, the wording they were shown “including version numbers and dates”, and whether and when they have withdrawn it. A tick box mapped to a yes or no field in the CRM is not enough on its own.

Never fail a lead over a missing tag. If the website tries to add a tag or a source the CRM does not have, the safe behaviour is to leave that detail off and create the lead anyway. A connection that refuses the whole enquiry because one label is missing has lost a customer over housekeeping.

Keeping the lead when the CRM is down

The connection is only as good as the moment it fails, so design for that moment first. CRMs go down for maintenance, keys expire, and networks time out. If the CRM is the only place an enquiry goes, each of those moments loses work. There are two sound patterns:

1. Two destinations. Email each enquiry to your inbox as well as creating the lead, and treat it as kept if either one takes it. If the email has failed, create the lead first, because it is now the only copy. Tell the visitor it has reached you only once one of the two holds it, and if neither can, say so and offer them another way.
2. A queue that retries. Hold each enquiry somewhere safe and keep trying the CRM until it succeeds, with a record of anything that never gets through.

Either way, give the CRM call a time limit, so a slow CRM cannot keep the visitor waiting until they give up and press Send again. Our guide to website enquiry forms that never lose a lead covers the rest of the form side: spam checks that do not eat real enquiries, the acknowledgement and the privacy notice.

Bookings and payments: keep the system, connect it

Most businesses that take bookings or payments already have a system they know, and replacing it to suit a website is usually the wrong way round. Connect it instead, in one of three ways, chosen by what the system supports:

• An embed. The system gives you a widget or a snippet of code that sits on your own pages, so the customer books without leaving your site. Usually right for a booking calendar.
• An API or a feed. Your site fetches the data, such as a menu or your stock, and shows it as real pages that search engines can read.
• A link. Your Book and Pay buttons open the system’s own page, ideally on your own web address. It works with almost anything; the customer leaves your site for that step.

Before you connect any of them, check that you can export your customer list and history whenever you want, and that the supplier signs a data processing agreement. Our bookings integration page sets out what to look for in a booking system, and our guide to online booking for barbershops works through one trade’s choice between marketplaces and a booking system on your own site.

Payments and webhooks

Payment providers tell your systems what happened (a payment succeeded, a refund went through) by webhook. Stripe’s documentation is a good model of how to handle one properly:

• Check that it really came from the provider. Stripe signs each event, and its documentation says to verify it with the signature header and your signing secret before acting on it.
• Answer quickly. Return a success response before any slow work, as Stripe’s documentation asks, so the delivery does not time out and get sent again.
• Expect repeats. Stripe “attempts to deliver events to your destination for up to three days with an exponential back off in live mode”, so the same event can arrive more than once. Track event IDs, as Stripe advises, so a payment is never recorded twice.

Who owns the data

The customer list is the most valuable thing any of these systems holds, so settle ownership before anything is connected:

• The account is in your name. The CRM, the booking system and the payment account should be opened by your business, under your own contract with each provider, with your supplier added as a user you can remove.
• You are the controller. Under UK GDPR, a supplier who handles your customers’ data for you is a processor, and needs a written contract with you. The ICO says that contract must say the processor “may only process personal data in line with the controller’s documented instructions”, and that at the end it must, “at the controller’s choice, delete or return to the controller all the personal data it has been processing”.
• You can leave with it. Check the export before you commit: every contact, every booking and every order, as a spreadsheet, any time.
• You know where it lives. Every service in the chain, including any automation service in the middle, belongs in your privacy notice and your record of where data goes.

How we connected our own site to Odoo

We run our own enquiries this way. Our business system is Odoo, which, as our sub-processor list puts it, “we run ourselves”, on our own server at OVHcloud in France, and “Odoo S.A., which publishes the software, receives no enquiry data”. Every enquiry sent through our site is emailed to us and recorded there.

The approach, without the operational detail:

• The website’s server creates the lead through Odoo’s external API, after the email, with an API key for an intake user of its own, never a person’s password.
• Each lead says where it came from: the source and medium are set to the website, each service the visitor ticked becomes a tag, and the form’s answers go into the lead’s notes beside the visitor’s own words.
• Nothing is ever refused for housekeeping. Tags are looked up by name, and one that does not exist in Odoo is left off while the lead is still created.
• Either copy is enough. If Odoo is slow or down, the attempt gives up within a time limit and the email stands; if the email failed, Odoo is tried first.
• Flagged is not deleted. An enquiry our spam checks flag is still recorded, tagged as possible spam with the reason, because some of them are real people.

The case study of our own site sets out how the rest of it is built and run. For a client, we connect the CRM you already use once we have checked it can take enquiries reliably, and the account stays yours; our CRM and pipeline service sets up the CRM itself, and our guide to what marketing automation is covers what can run on top of it.

The short version

Pick the route your CRM and plan support: the API for control, a webhook for convenience, an email alias for speed. Map the source, the service and any consent, not just the name and email. Keep a second copy, so the CRM being down never costs you an enquiry. Connect the booking and payment systems you already have rather than replacing them, verify every webhook, and keep every account, and every customer list, in your own name.

When you want your booking, ordering, payment or CRM system connected to your site, our integrations service does it on the accounts you already hold: tell us what you use now and we will send a written quote.