Odoo Webhooks and External System Integration

When an order ships, a payment clears, or inventory changes, another system may need to know immediately. A webhook lets one application notify another that an event has occurred, usually by sending an HTTP request containing a payload. 

For businesses using Odoo, webhooks can connect ERP workflows to ecommerce platforms, shipping providers, warehouse systems, payment services, and internal applications. They can reduce manual updates and shorten the delay between an event and the action that follows. 

But webhooks are not simply URLs that make systems communicate automatically. You need to decide what triggers an event, which data is sent, how the receiving system verifies it, and what happens if delivery fails. 

This guide explains inbound and outbound Odoo webhooks, when to use Odoo's built-in automation tools, when custom development is warranted, and how to design an integration that can recover from errors. 

1. Understand inbound and outbound webhooks 

The first design decision is the direction of the event. 

Inbound webhooks: external system to Odoo 

An external application sends an HTTP request to Odoo when something happens in that application. For example, a warehouse platform may send a shipment update after a package leaves a facility. Odoo receives the payload and updates the relevant record or runs a configured action. 

The external system initiates the request. 

Outbound webhooks: Odoo to external system 

Odoo sends an HTTP request to another application's webhook URL when a configured event occurs in Odoo. 

For example, when a sales order reaches a particular state, Odoo may notify a fulfillment platform that the order is ready for processing. 

Odoo's automation rules include a Send Webhook Notification action that sends a POST request to the configured URL with selected field values. 

These two directions should not be treated as interchangeable. The security checks, payload contract, retry strategy, and failure handling depend on which system initiates the request. 

2. Choose the right Odoo implementation 

Odoo 19 supports webhook-related automation through Odoo Studio. Its documentation describes receiving POST requests from external systems and configuring actions to run when a webhook is triggered. Automation rules can also send webhook notifications to external endpoints. 

For straightforward workflows, built-in automation may be enough. A developer may be needed when the integration requires custom target-record logic, validation, complex mapping, or behavior beyond the configured actions. 

The right approach depends on the systems involved, how quickly data needs to move, and what should happen when an event fails. For a broader look at connecting business applications, see our guide to Odoo integrations for growing businesses. Do not build a custom endpoint before checking whether a standard automation action meets the requirement. Conversely, do not force complex integration logic into a low-code rule if it becomes difficult to test, monitor, or maintain. 

3. Example: receive a shipment update in Odoo 

Imagine a shipping platform that sends an event when a package is dispatched. The payload might look like this: 

{ 

  "event_id": "evt_84721", 

  "event_type": "shipment.dispatched", 

  "order_reference": "WEB-10482", 

  "tracking_number": "TRK-784120", 

  "occurred_at": "2026-10-20T10:30:00Z" 

} 

This is an illustrative payload, not a built-in Odoo schema. The shipping platform and Odoo integration must agree on the event names, field types, identifier format, and required values. 

Before implementing the receiver, answer these questions: 

• Which Odoo record corresponds to order_reference?

• Is the external order reference unique and reliable? 

• Which model fields should be updated? 

• Can the event arrive more than once? 

• What should happen if the order does not exist? 

• How will the receiver authenticate the sender? 

• Should the event update a record immediately or enter a queue for processing? 

The order reference is especially important. Do not assume the external platform's order number is an Odoo database ID. Map it to a field with a defined uniqueness rule. 

4. Configure an inbound webhook with Odoo Studio 

For a supported workflow, Odoo Studio provides a way to create a webhook that receives external POST requests and triggers an automated action. 

The exact options depend on the Odoo version, model, and hosting environment, so use the documentation for your deployed version. 

A typical setup involves: 

1. Open Odoo Studio and create a webhook or an automation rule using the On webhook trigger. 

2. Give the rule a name that explains the event and purpose. 

3. Select the target model where appropriate. 

4. Review the generated webhook URL and treat it as confidential. 

5. Configure the target-record logic and the action to run. 

6. Enable call logging if it will help with diagnosis and operational support. 

7. Test with a controlled payload against a duplicate or staging database. 

8. Configure the external system to send requests to the webhook URL only after the Odoo-side behavior has been verified. 

Odoo warns that a poorly configured webhook can disrupt the database. A test against a duplicate database is therefore an important safety measure, not an optional finishing step. 

Map the payload to the correct record 

A webhook payload can contain an external reference, but Odoo still needs a reliable way to find the matching record. 

Avoid relying on a sample record ID or a fixed database ID copied from a tutorial. That can cause an event to update the wrong record. 

For example, if the shipping provider sends an order reference, your implementation should locate the corresponding Odoo record using the agreed external-reference field. If no matching record exists, define whether the event should be rejected, queued for later processing, or handled through a separate exception workflow. 

5. Build an outbound webhook for an order event 

Suppose Odoo needs to notify a fulfillment platform when an order is ready. 

A practical implementation should define: 

• The event that triggers the notification. 

• The external endpoint and authentication method. 

• The exact fields included in the payload. 

• The identifier the receiver uses to recognize the order. 

• What constitutes a successful response. 

• How failures are logged and retried. 

Odoo's Send Webhook Notification automation action can send a POST request containing selected fields to the external URL. Use the sample payload to verify what the receiver will get, and avoid exposing fields that the external service does not need. 

For example, a minimal event contract might look like this: 

{ 

  "event_type": "order.ready_for_fulfillment", 

  "order_reference": "WEB-10482", 

  "occurred_at": "2026-10-20T10:30:00Z" 

} 

The receiver can then use the reference to retrieve any additional details through an authenticated integration, if necessary. This can reduce the amount of business data included in each webhook. 

Webhook notifications can also form part of a larger automated process, such as routing an order update to the right team or triggering the next step in a service workflow. For examples of how tailored workflows can support these processes, read about Odoo workflow customization. 

6. Secure the webhook endpoint 

A webhook URL should not be treated as public just because it is an HTTP endpoint. 

For Odoo Studio webhooks, the generated URL is confidential. Odoo documents that rotating the secret changes the URL, so the external sender must be updated as part of that process. 

For custom endpoints, select an authentication mechanism that suits the threat model. Depending on the sender, this may include a signed request, a shared secret, an API key, or another supported authentication method. 

Apply these safeguards: 

• Use HTTPS. 

• Keep webhook URLs and secrets out of public source code and documentation. 

• Validate the request structure and required fields. 

• Reject unexpected event types. 

• Validate identifiers and values before updating records. 

• Apply least-privilege access to any user or service account involved. 

• Avoid using elevated privileges without a clear reason and narrow scope. 

• Redact secrets and sensitive business data from logs. 

• Rotate credentials when they are exposed or no longer needed. 

If the sender supports cryptographic signatures, verify the signature against the exact raw request body according to that provider's specification. Do not invent a signature format or assume every webhook provider uses the same header or algorithm. 

For custom Odoo controller work, the receiver must also account for public methods and request parameters being untrusted. Odoo's security documentation is a useful reference for avoiding unsafe public methods and bypassing access controls. 

7. Handle duplicates, retries, and out-of-order events 

Webhook delivery is not the same as guaranteed once-only processing. A sender may retry because it did not receive a response, even if the receiver completed the original operation. Some systems can also deliver events out of order. 

Make event processing idempotent 

An idempotent operation can be repeated without producing an unintended additional effect. 

If the sender provides a stable event ID, store it and use it to detect duplicates. Enforce uniqueness where appropriate; a check performed only in application code may not be sufficient when two identical events arrive concurrently. 

For example, if the same shipment.dispatched event arrives twice, the second request should not create another shipment record or trigger a second fulfillment action. 

Define retry behavior 

Retry only when the error is likely to be temporary. Use bounded retries with increasing delays rather than an immediate, endless retry loop. 

Examples: 

• A temporary network failure may justify a retry. 

• A rate-limit response may require a delay. 

• A malformed payload needs correction, not repeated delivery. 

• A permission error needs configuration changes. 

• A timeout leaves the outcome uncertain and requires duplicate protection. 

If the integration is business-critical, store failed events for later processing or reconciliation instead of relying entirely on the sending system's retry policy. 

Protect against out-of-order events 

Consider a shipment that sends shipment.dispatched  and later shipment.delivered.

If a delayed dispatch event arrives after the delivery event, a naive handler could move the record backward. 

Use event timestamps, a version or sequence number when available, and explicit state-transition rules. The integration should not blindly apply every event just because it arrived successfully. 

8. Monitor and troubleshoot webhook failures 

A webhook that silently stops working can leave two systems disagreeing for hours or days. 

Track at least: 

• Events received and successfully processed. 

• Failed requests by error category. 

• Duplicate events detected. 

• Processing latency. 

• Events waiting for retry or manual review. 

• Differences discovered during reconciliation. 

Odoo Studio supports logging webhook calls when configured. For custom integrations, add structured logs and correlation IDs so a specific event can be traced across Odoo, middleware, and the external application. 

Common issues include: 

A successful HTTP response should not be the only measure of success. Verify that the intended record changed and that the business workflow reached the expected state. 

9. Know when webhooks need supporting architecture 

Webhooks are useful for timely notifications, but they are not a substitute for every integration mechanism. 

For a small workflow, a direct automation may be sufficient. For high-volume or financially important operations, a queue or middleware layer can provide durable storage, retry scheduling, deduplication, alerting, and replay tools. 

A scheduled reconciliation job can also compare the source and destination systems to find events that were missed or never completed. 

For example, an ecommerce order may trigger a webhook to Odoo, while a scheduled job later checks that every paid order has a matching Odoo order. This combines timely processing with a way to detect gaps. 

If your workflow requires complex mapping, custom endpoints, or multiple connected systems, Our Odoo integration services can help define the data contract and implementation approach. 

Conclusion 

Odoo webhooks can help businesses respond to order updates, shipment events, payment notifications, and other changes without relying entirely on manual updates or scheduled polling. But reliable integration depends on more than configuring a trigger. You also need to validate incoming data, secure endpoints, handle duplicate events, plan for failed deliveries, and monitor whether the intended business operation actually completed. 

Start with the process you need to connect, choose the simplest integration approach that meets the requirement, and test how it behaves when requests are delayed, repeated, or rejected. For workflows that require custom endpoints, specialized business logic, or more complex system connections, Contact us to discuss an approach suited to your requirements.