Odoo API vs Webhook vs Scheduled Action: Choosing the Right Pattern

Introduction

Connecting Odoo with another system is rarely just a question of whether an integration is technically possible.

The more important question is:

How should the two systems exchange information?

A CRM may need to send a new customer to Odoo immediately.

An eCommerce platform may need to notify Odoo when an order is created.

A reporting system may only need a data refresh every hour.

A finance system may need Odoo records synchronized overnight.

These scenarios can all involve APIs, but they do not necessarily require the same integration pattern.

Three approaches commonly appear in Odoo integration architecture:

• API requests for direct system-to-system communication
• Webhooks for event-driven communication
• Scheduled actions for time-based or batch processing

Choosing the wrong pattern can create unnecessary load, delayed data, difficult error recovery, or unclear ownership.

Odoo 19 introduces the External JSON-2 API for external access to Odoo data and models, while Odoo Studio provides webhook and automation capabilities for event-driven and scheduled workflows.

The goal is therefore not to decide which technology is “best.”

The goal is to determine which pattern fits the business requirement and operational risk.

API vs Webhook vs Scheduled Action: Quick Answer

The simplest way to think about the three patterns is:

A useful decision rule is:

Need an immediate response to a request? → API

Need another system to notify Odoo when something happens? → Webhook

Need Odoo to process or synchronize information periodically? → Scheduled Action

In real-world architecture, these patterns can also work together.

For example:

Webhook → Integration Layer → Odoo API

or:

Scheduled Action → API → External System

The right architecture depends on the business process rather than the technology alone.

1. What Is the Odoo API?

An API allows another application to communicate with Odoo programmatically.

Instead of a user opening Odoo and manually creating or updating records, an external system can make a request to Odoo.

For example:

eCommerce → Odoo API → Customer / Sales Order

or:

Data Platform → Odoo API → Reporting Data

Odoo 19 provides the External JSON-2 API, which exposes Odoo models and methods through HTTP using the /json/2/<model>/<method> endpoint. The API uses Odoo's access rights, record rules and field access controls when processing operations.

This makes APIs useful when the external system needs to actively request or send information.

Typical API use cases

Odoo APIs can be useful for:

• Creating customers
• Updating product information
• Creating sales orders
• Reading inventory information
• Retrieving accounting data
• Synchronizing master data
• Running integration processes
• Connecting external applications
• Feeding reporting platforms

The key characteristic is that the application initiates the request.

2. What Is an Odoo Webhook?

A webhook is an event-driven integration pattern.

Instead of another system repeatedly asking:

“Has anything changed?”

the source system sends a notification when an event occurs.

For example:

Order Confirmed → Webhook → Odoo

or:

Payment Completed → Webhook → Odoo

Odoo 19 documentation describes webhooks as a way to automate an action in Odoo when a specific event occurs in an external system. The external system sends a payload through a POST request to the webhook URL.

This makes webhooks particularly useful when timing matters.

Typical webhook use cases

Webhooks can be useful for:

• New orders
• Payment confirmations
• Customer creation
• Shipment updates
• Inventory events
• Subscription changes
• Status changes
• External workflow events
• Real-time notifications

For example:

Payment Gateway

↓

Payment successful

↓

Webhook

↓

Odoo receives event

↓

Update payment status

The system does not need to continuously check whether the payment has changed.

3. What Is a Scheduled Action in Odoo?

A scheduled action performs work at a predefined time or interval.

Instead of responding immediately to an external event, Odoo checks or processes information according to a schedule.

For example:

Every 15 minutes → Check pending records

or:

Every night → Synchronize external data

Odoo's scheduled actions use ir.cron and can execute automatically according to a configured frequency. Odoo's developer documentation also recommends batching scheduled processing so that long-running jobs do not unnecessarily block workers or cause timeouts.

Scheduled processing is therefore useful when immediate synchronization is unnecessary or when a business process naturally works in batches.

Typical scheduled action use cases

Examples include:

• Nightly data synchronization
• Periodic inventory reconciliation
• Report generation
• Cleanup processes
• Expired record processing
• Batch updates
• Data quality checks
• Retry processing
• Periodic external API polling

For example:

Every Hour

↓

Check external orders

↓

Find new records

↓

Process records

↓

Update Odoo

4. Odoo API vs Webhook vs Scheduled Action

The three patterns solve different architectural problems.

There is no universal winner.

The correct choice depends on:

Timing + Volume + Reliability + Recovery + Ownership + Governance

5. Choose Based on Business Timing

Timing is one of the strongest factors in deciding between API, webhook and scheduled action.

Real-time requirement

If the business process requires an immediate response, an API or webhook is usually more appropriate.

Example:

A customer completes checkout.

The order needs to reach Odoo immediately.

A webhook can notify Odoo that the event occurred.

Near-real-time requirement

If a small delay is acceptable, either webhooks or APIs may work.

For example:

Customer information can be synchronized within a few minutes without affecting operations.

Periodic requirement

If the business only needs information refreshed every hour or every night, a scheduled process may be simpler.

For example:

ERP → Reporting Database

A nightly synchronization may be completely sufficient.

The important question is not:

“Can we make this real time?”

It is:

“Does the business actually require real time?”

Real-time architecture can introduce additional complexity that provides little business value when minutes or hours of delay are acceptable.

6. API vs Webhook: What Is the Difference?

The difference becomes clearer when looking at who starts the communication.

API

The system actively makes a request.

System A → API Request → Odoo

For example:

An integration service asks Odoo:

“Give me the latest customer information.”

Odoo responds.

Webhook

The source system sends an event.

System A → Event → Webhook → Odoo

For example:

An external payment system detects:

“Payment completed.”

It sends that event to Odoo.

The distinction can be summarized as:

API = Ask for information

Webhook = Tell the system something happened

In practice, a mature integration can use both.

For example:

Webhook

↓

Notify integration platform that an order changed

↓

API

↓

Retrieve complete order information

This approach can reduce unnecessary polling while still allowing the integration to retrieve authoritative data.

7. Webhook vs Scheduled Action

The difference between webhooks and scheduled actions is primarily about event timing versus polling.

Webhook

The source system says:

“Something happened.”

Scheduled Action

The receiving system says:

“Let me check whether something happened.”

For example, suppose an external marketplace receives 10,000 orders per day.

A polling model might repeatedly ask:

“Are there new orders?”

A webhook model can instead send an event when an order is created.

This can reduce unnecessary requests.

However, webhooks introduce their own operational requirements.

Odoo recommends testing webhooks before implementing them in a live database and provides call logging to help troubleshoot webhook requests.

8. When Should You Choose an Odoo API?

Choose an API when the integration requires direct control over when information is requested or submitted.

Good examples include:

On-demand data retrieval

A reporting or business application needs specific Odoo data.

Record creation

An external platform needs to create customers, orders or other records.

Record updates

An integration needs to update Odoo when a business process changes.

Controlled synchronization

An integration platform controls when and how data is exchanged.

Request-response workflows

The calling application needs to know whether the operation succeeded.

An API is especially useful when the business process naturally looks like:

Request → Process → Response

9. When Should You Choose a Webhook?

Choose a webhook when an important business event occurs and another system needs to know about it quickly.

Good examples include:

Order events

Order Created → Webhook

Payment events

Payment Confirmed → Webhook

Shipping events

Shipment Delivered → Webhook

Customer events

Customer Created → Webhook

Status changes

Subscription Activated → Webhook

Webhooks are particularly valuable when polling would create unnecessary requests.

But webhooks should not be treated as a simple “real-time switch.”

They require proper handling of:

• Authentication
• Secrets
• Payload validation
• Duplicate events
• Failed requests
• Retries
• Logging
• Monitoring
• Idempotency
• Ownership

Odoo specifically warns that webhook URLs should be treated as confidential because improper exposure can provide unintended access to the database.

10. When Should You Choose a Scheduled Action?

Scheduled actions are often the better option when immediate processing is unnecessary.

Consider a business that receives product updates throughout the day.

If inventory does not need to update instantly, the business could synchronize inventory:

Every 30 minutes

or:

Every hour

or:

Once per night

This can be simpler than implementing an event-driven architecture.

Scheduled actions are also useful when:

• The external system does not support webhooks
• Batch processing is preferred
• Data can tolerate some delay
• Large volumes need controlled processing
• Retry logic is easier in batches
• The process is naturally periodic

For large jobs, processing should be designed in manageable batches rather than attempting to process everything in one execution. Odoo's developer documentation explicitly recommends batching scheduled-action work to reduce worker blocking and timeout risks.

11. Compare Reliability and Failure Recovery

Architecture decisions should not stop at the successful path.

Ask:

What happens when the integration fails?

This is where the differences become important.

API failure

An API request can fail because of:

• Network problems
• Authentication errors
• Invalid data
• Permission issues
• Server errors
• Timeouts

The integration should define whether the request is retried, rejected, queued or manually reviewed.

Webhook failure

A webhook can fail because:

• The receiving endpoint is unavailable
• The payload is invalid
• Authentication fails
• The target record cannot be identified
• Processing takes too long
• Duplicate events arrive

The architecture needs a strategy for retrying or recovering failed events.

Scheduled action failure

A scheduled process may fail during execution.

The advantage is that a future run can potentially process the remaining work again, provided the process is designed to identify incomplete or failed records correctly.

Therefore:

Reliable integration ≠ successful first attempt

Reliable integration means the business has a defined process for:

Detect → Log → Retry → Reconcile → Escalate

12. Design for Idempotency

Idempotency is one of the most important concepts in integration architecture.

Suppose a webhook is received twice.

The integration should not create two identical sales orders simply because the same event was delivered twice.

For example:

Event ID: 12345

First delivery:

→ Create order

Second delivery:

→ Detect Event ID 12345 already processed

→ Do not create duplicate order

The same principle applies to API and scheduled integrations.

Before implementing an integration, define:

• Unique business identifiers
• Event IDs
• External references
• Duplicate detection
• Processing status
• Retry behavior

This is particularly important for financial transactions, orders, payments and inventory movements.

13. Compare Data Volume and Load

The integration pattern should also reflect the expected data volume.

Imagine three scenarios.

Scenario A: 10 important events per day

A webhook may be ideal.

Scenario B: 50,000 records require synchronization

A scheduled batch process may be more appropriate.

Scenario C: Users need individual records on demand

An API may be the natural choice.

The architecture should consider:

Number of records × frequency × processing cost

rather than simply asking whether the integration needs real-time communication.

High-frequency webhooks can create significant processing load if every event triggers expensive database operations.

Likewise, aggressive API polling can generate unnecessary traffic.

Scheduled processing can sometimes provide better control over large workloads.

14. Think About Auditability

Integration data should be traceable.

For every important transaction, the business should ideally be able to answer:

• What triggered the integration?
• When did it occur?
• Which system sent the data?
• What payload or reference was received?
• Which Odoo record was affected?
• Did processing succeed?
• If it failed, why?
• Was it retried?
• Who resolved the exception?

Odoo provides webhook call logging when the Log Calls option is enabled, which can help with troubleshooting webhook activity.

For APIs and scheduled jobs, equivalent application-level logging and monitoring should be considered.

Auditability should therefore be part of the architecture rather than something added after deployment.

15. Security and Access Control Matter

Integration architecture also creates security responsibilities.

For API integrations, consider:

• API key management
• Dedicated integration users
• Minimum permissions
• Key expiration
• Key rotation
• Secure storage

Odoo 19's JSON-2 API uses standard Odoo access rights, record rules and field access controls. Odoo also recommends dedicated bot users for extended automated integrations and recommends appropriate API-key expiration periods.

For webhooks, consider:

• Secret protection
• Endpoint exposure
• Payload validation
• Authentication
• Replay protection
• Logging
• Access control

For scheduled actions, consider:

• Who owns the process
• What permissions it runs with
• What records it can modify
• How failures are monitored

Integration security should therefore be treated as part of Odoo data governance.

16. Do Not Confuse API With Integration Architecture

An API is a technical interface.

It is not an entire integration architecture.

For example:

External System → Odoo API

is only the communication mechanism.

A complete architecture may also require:

Source System

↓

Integration Layer

↓

Validation

↓

Transformation

↓

Odoo API

↓

Logging

↓

Monitoring

↓

Retry / Exception Handling

Similarly, a webhook is only the event delivery mechanism.

A mature integration architecture should define what happens before and after the API or webhook call.

17. Can API, Webhook and Scheduled Action Work Together?

Yes.

In fact, combining them can produce a stronger architecture.

Consider an eCommerce integration.

Step 1 — Webhook

The eCommerce platform sends:

Order Created

↓

Step 2 — Integration Layer

The integration validates the event.

↓

Step 3 — API

The integration retrieves the complete order information.

↓

Step 4 — Odoo

The order is created or updated.

↓

Step 5 — Scheduled Reconciliation

Every night, a scheduled process checks for missing or inconsistent orders.

This creates three layers:

Webhook = Fast notification

API = Data retrieval / transaction

Scheduled Action = Reconciliation

This is often more robust than trying to force one pattern to handle every requirement.

18. Use a Decision Matrix Before Choosing

A practical decision matrix can help stakeholders select the appropriate pattern.

✓ = suitable

△ = possible with additional architecture

✗ = generally not the natural choice

19. API vs Webhook vs Scheduled Action: Example Scenarios

Scenario 1: Payment Confirmation

Requirement: Update Odoo as soon as payment succeeds.

Recommended: Webhook

Reason: Payment is an event and the business benefits from rapid notification.

Scenario 2: Customer Lookup

Requirement: An external application needs customer information when a user searches for a customer.

Recommended: API

Reason: The application needs an on-demand request and response.

Scenario 3: Nightly Reporting

Requirement: Transfer data to a reporting environment every night.

Recommended: Scheduled Action + API

Reason: The business does not need real-time synchronization.

Scenario 4: Marketplace Orders

Requirement: Send new marketplace orders to Odoo quickly.

Recommended: Webhook + API

Reason: The webhook can notify the integration that an order exists, while the API can retrieve complete order information.

Scenario 5: Data Reconciliation

Requirement: Verify that external orders and Odoo orders match every night.

Recommended: Scheduled Action

Reason: Reconciliation is naturally a batch process.

Scenario 6: External System Does Not Support Webhooks

Requirement: Synchronize new records from an external platform.

Recommended: API + Scheduled Action

Reason: A scheduled process can periodically call the external API and retrieve changes.

20. Common Integration Architecture Mistakes

Using Polling for Everything

Constantly asking another system whether something changed can create unnecessary traffic and processing.

Use event-driven communication when the business genuinely needs event-based updates.

Using Webhooks for Everything

Not every process needs real-time communication.

High-volume batch processing may be easier to manage through scheduled jobs.

Treating Scheduled Actions as Real-Time

A scheduled process introduces delay.

If a transaction must be processed immediately, a scheduled job may not satisfy the business requirement.

Ignoring Failure Recovery

An integration that works only when everything goes perfectly is not production-ready.

Define retry and exception handling before deployment.

Creating Duplicate Records

Repeated events or retries can create duplicate customers, orders or payments if idempotency is not considered.

Sharing API Credentials

Integration credentials should be managed securely and should use the minimum permissions necessary.

Exposing Webhook URLs

Odoo recommends treating webhook URLs as confidential because they can provide access to the Odoo database if improperly exposed.

Processing Large Jobs in One Run

Large scheduled jobs should be designed around manageable batches and recoverable progress.

21. Odoo Integration Governance Checklist

Before implementing an Odoo integration, define the following.

Business Requirements

• What business event or process starts the integration?
• Is real-time processing actually required?
• How much delay is acceptable?
• What happens if the integration is unavailable?

Architecture

• API, webhook or scheduled action?
• One-way or two-way integration?
• Direct connection or integration layer?
• What system owns the master data?

Reliability

• What happens when a request fails?
• How are retries handled?
• How are duplicate events detected?
• How are partially processed records recovered?

Security

• Which credentials are required?
• Which user or service owns them?
• What permissions are required?
• How are secrets stored and rotated?

Monitoring

• Are requests logged?
• Are failures visible?
• Who receives alerts?
• How are unresolved exceptions escalated?

Data Governance

• Which fields are exchanged?
• Which system is authoritative?
• How are data conflicts resolved?
• How long should integration logs be retained?

Testing

• Normal transaction
• Invalid payload
• Duplicate event
• Timeout
• Authentication failure
• Partial failure
• Retry
• High-volume processing
• Recovery after downtime

22. A Practical Odoo Integration Decision Framework

A simple architecture decision tree can be used during project discovery.

Question 1: Does another system need to tell Odoo that something happened?

Yes → Consider a Webhook

Question 2: Does a system need to request or send information directly?

Yes → Consider an API

Question 3: Can the process run periodically?

Yes → Consider a Scheduled Action

Question 4: Is the data volume large?

Yes → Consider batching and scheduled processing

Question 5: Is immediate notification required?

Yes → Consider Webhooks

Question 6: Does the process require a response?

Yes → Consider API-based communication

Question 7: Is reconciliation required?

Yes → Consider a scheduled reconciliation process

This produces a more practical architecture than selecting a technology first.

23. Recommended Architecture by Business Requirement

The strongest enterprise integrations often use more than one pattern.

24. Odoo 19 API Considerations

For organizations planning new integrations on Odoo 19, API architecture should also consider the current Odoo API direction.

Odoo 19 introduces the External JSON-2 API as a new external API for accessing Odoo models through HTTP. Odoo's documentation also notes that the older XML-RPC and JSON-RPC external APIs are scheduled for removal in later Odoo versions, making API architecture an important consideration for new integrations.

This means businesses planning long-lived integrations should avoid designing new architecture around legacy assumptions without considering Odoo's current API direction.

The important principle is:

Choose an integration pattern that can remain maintainable as the Odoo environment evolves.

Frequently Asked Questions

1. What is the difference between an Odoo API and a webhook?

An Odoo API is typically used when a system actively requests or sends data, while a webhook is used to notify Odoo when a specific event occurs. APIs are request-driven, while webhooks are event-driven.

2. When should I use an Odoo webhook?

Use an Odoo webhook when an external system needs to notify Odoo about an event quickly, such as a new order, payment confirmation, shipment update or customer change.

3. When should I use an Odoo API?

Use an Odoo API when an application needs on-demand access to Odoo data or needs to create, update or process Odoo records programmatically.

4. What are Odoo scheduled actions used for?

Scheduled actions are used to execute processes automatically at defined intervals or times. They are useful for batch processing, periodic synchronization, cleanup, reconciliation and other time-based workflows.

5. Are webhooks better than APIs for Odoo integrations?

Not necessarily. Webhooks are better for event-driven communication, while APIs are better for direct request-and-response operations. Many integrations use both.

6. Can Odoo API and webhooks be used together?

Yes. A webhook can notify an integration that an event occurred, while an API can then retrieve the complete data needed to process that event.

7. Can scheduled actions replace webhooks?

Sometimes, but not always. Scheduled actions can poll for changes when real-time communication is unnecessary or when the external system does not support webhooks. They introduce a delay and may create additional polling traffic.

8. How should Odoo integrations handle failed requests?

Integrations should define logging, retry, duplicate detection, reconciliation and escalation processes. A failed transaction should be recoverable rather than requiring manual database intervention.

9. What is idempotency in Odoo integration?

Idempotency means processing the same request or event more than once does not create unintended duplicate results. It is important for orders, payments, inventory and other critical transactions.

10. Which Odoo integration pattern is best for large data volumes?

Large data synchronization is often better suited to controlled API-based batch processing or scheduled actions. The integration should use batching, checkpoints and recovery mechanisms instead of processing everything in one operation.

11. Are Odoo webhooks secure?

Webhooks can be secure when their URLs, secrets, payloads, permissions and monitoring are properly managed. Odoo specifically recommends treating webhook URLs as confidential and testing webhook configurations before using them in a live database.

12. Which integration pattern should an Odoo business choose?

The choice depends on the business requirement. APIs suit direct requests, webhooks suit event-driven communication, and scheduled actions suit periodic or batch processing. Complex integrations may combine all three.

Conclusion

Choosing between an Odoo API, webhook and scheduled action should start with the business process, not the technology.

Use an API when systems need direct request-and-response communication.

Use a webhook when an event should trigger an action quickly.

Use a scheduled action when processing can happen periodically or in batches.

For enterprise integrations, the strongest architecture may combine all three:

Webhook for notification

↓

API for data exchange

↓

Scheduled Action for reconciliation

This approach can provide responsive integrations without sacrificing recovery, governance or operational control.

Before implementing an Odoo integration, evaluate the required timing, data volume, failure scenarios, security model, audit requirements and ownership.

A well-designed integration is not simply one that moves data between systems.

It is one that continues to work predictably, securely and recoverably when real-world conditions are not perfect.

Request an Odoo integration architecture review