What to sync

Each switch enables one scheduled flow. Turning a switch off never deletes anything - it only stops the scheduler running that flow; manual runs from the Operations pages remain possible.

Sync Orders (default on). Enables the two order flows: order push (send eligible confirmed sales orders to the 3PL) and status poll (refresh the 3PL's status for every order that has been sent). With this off, the dashboard order cards grey out with an "Inactive" badge and no order ever leaves Odoo by itself. Example: during a migration weekend you switch Sync Orders off so nothing is pushed while stock is being counted, then switch it back on Monday - the next push picks up everything that queued up, oldest first.

Sync Stock Levels (default on). Enables the scheduled inventory sync (see Inventory sync). What the sync actually does with differences is governed by Stock Master and Stock Adjustments below.

Sync Products (default off). Enables the background product push queue: product bindings marked To Push (or queued by the bulk wizard / "Push Queued Products") are sent to the 3PL's item master in batches. Off means products only move when someone pushes them by hand.

Sync Suppliers (default off). Pushes vendor records to 3PLs that keep their own supplier master, so inbound deliveries can reference them. Hidden for providers without supplier support (the 3PL, for example, does not take suppliers via API - which is why the Suppliers operation never offers a the 3PL instance).

Sync Returns (default off). Polls the 3PL for customer returns - including parcels that arrive unannounced and undeliverable/return-to-sender parcels - and books received goods back into Odoo. See Returns for the full lifecycle.

How often

Each flow has its own schedule, applied only while its switch is on and checked by a scheduler that wakes every few minutes. A schedule is "every N units", and the unit decides what else you can set:

• minute(s) / hour(s) - a plain interval: the flow runs whenever that much time has passed since its last run (and immediately the first time).
• day(s), at a set time - e.g. every 1 day at 02:00, or every 3 days at 18:30. Setting or changing a schedule anchors it at that moment: configure "every 1 day at 02:00" at noon and the first run is tomorrow at 02:00.
• week(s), on a weekday - e.g. every week on Sunday at 06:00, or every 2 weeks on Friday at 20:00.
• month(s), on a date - e.g. every month on day 1 at 05:00, or every 3 months on day 31 (automatically clamped to the last day of shorter months).

Times of day are in the company's timezone. The defaults are the plain minute intervals: order push 15, status poll 30, stock sync 1440 (daily), returns poll 60.

Guidance: status polling is the chattiest flow - against a rate-limited API, lengthen its schedule first. Inventory syncs are heavy on both sides; every 1 day at 02:00 is right for most operations. Every flow can always be run now from the dashboard or its Operations page regardless of the schedule.

Push delivery (webhooks)

Polling asks the 3PL "anything new?" on a timer. A webhook is the warehouse telling you the moment something happens. The instance's Event Delivery tab, inside Synchronisation, decides which of those it relies on - and what happens when the telling stops.

• Polling only (the default). Nothing changes.
• Push assists polling. Events act the moment they arrive and the timer carries on underneath. Nothing to lose, so this is the sensible first step.
• Push is primary. Events act immediately and the poll drops back to a safety-net interval, cutting API traffic without cutting the net.

Push never replaces polling outright. A webhook is one delivery attempt at a server that might be restarting, upgrading or simply down, and an event nobody caught is an order that silently never despatched. With push as primary you also set how often the safety-net poll still runs (180 minutes by default) and how long silence may last before the connector raises the alarm (120 minutes by default).

What happens if an event is missed

The endpoint's only job is to write the delivery down and acknowledge it - nothing is processed inside the provider's request. A background job picks events up within the minute, retries what fails five times, and leaves anything still broken as Failed with its payload intact, ready to replay from the Pushed Events list. Repeat deliveries are recognised by fingerprint, so a provider retrying until it sees a 200 does not produce duplicates.

Events are notifications, not sources of truth: the connector reads the event to learn what changed, then asks the provider's API for the detail. That is why a missed event is survivable - the catch-up runs exactly the same flows the polls do, so whatever the events would have told you is read back from the provider's own state. If nothing arrives for longer than your tolerance, the connector runs that catch-up by itself and notes it on the instance; Catch Up Now does it on demand.

Which providers can push

Where a provider cannot push, the connector polls and the tab says so. Nothing is lost - polling is how every instance worked before push existed.