Social Commerce Connector

Key Features

Authenticated multi-shop connections in `social.commerce.account` with encrypted credential fields and an `ir.cron` token-refresh job, so one database can serve several storefronts and brands

Catalog publishing that maps `product.template`/`product.product` variants to remote listings — titles, descriptions, images, attribute values and prices — persisting the remote listing id for stable round-tripping

Webhook controller route plus polling fallback, with every inbound payload staged in `social.commerce.raw.order` before parsing so nothing is lost to an unexpected schema change

Idempotent order ingestion keyed on the remote order id, so retried webhooks and overlapping cron runs can never create a duplicate `sale.order`

Partner resolution and de-duplication (create-or-match on platform buyer id, email and phone) with correct invoice and delivery addresses written to the sale order

Fiscal position and tax mapping per shop, including marketplace-facilitated tax scenarios where the platform remits on your behalf and Odoo must post it differently

Free-to-promise availability computed with `@api.depends`, plus per-listing safety stock and warehouse scoping, pushed back to the storefront on a queued, rate-limit-aware job

Fulfilment push on `stock.picking` validation — carrier, tracking number and dispatch timestamp sent inside the platform shipping SLA, with acknowledgement state written back onto the order

Cancellation, return and refund events mapped onto Odoo return pickings and credit notes instead of leaving orphaned confirmed orders

Payout ingestion into `social.commerce.payout` with settlement lines matched to orders, commission/fee/promotion lines posted to nominated accounts, and an explicit unmatched-variance list

Live-commerce burst handling: batched ingestion and queued outbound calls so a single stream drop does not breach API rate limits or lock the sale order table

Security layer built the Odoo way — `ir.model.access.csv`, record rules scoping shop operators to their own accounts, and multi-company rules so cross-company data never leaks

Operations dashboard (list/kanban/form in XML/OWL), QWeb reports for payout reconciliation and daily order intake, and a sync-error queue with one-click retry

All connector models exposed over the XML-RPC/JSON-RPC API so BI tools and middleware can read sync state without direct database access

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

You order

Start with a one-time build price. We scope it with you at kickoff.

We build & install

ECOSIRE builds, configures and installs it on your Odoo.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

About this Product

Social storefronts and live commerce sell fast and settle slowly. Orders land in a seller centre app, stock is decremented in a place your ERP cannot see, refunds and cancellations happen inside a short window you never hear about, and weeks later a payout arrives net of commission, shipping subsidies, promotion co-funding and adjustments that nobody can tie back to a specific order. Odoo out of the box has no concept of any of this. sale.order is happy to record a sale once someone types it in, stock.quant will reserve goods once a picking exists, and account.move will post an invoice — but nothing bridges the social platform to those models. Teams end up exporting CSVs from the seller centre, re-keying orders, and discovering oversells only when a picking cannot be reserved. The Odoo eCommerce module does not help here either: it drives your own website, not somebody else's storefront.

The Social Commerce Connector is the missing bridge, written as a proper Odoo module rather than a scripted import. We add a social.commerce.account model holding one authenticated shop connection (credentials in an encrypted field, token refresh handled by an ir.cron), plus social.commerce.listing linking a product.product to its remote listing id and variant/SKU mapping. Catalog publishing pushes titles, descriptions, images, variant attributes and prices out of Odoo, then stores the remote id so the mapping is never lost. Order capture receives webhooks on a dedicated controller route with a polling fallback, and every payload is written to a social.commerce.raw.order staging record first — so a malformed or unexpected message is retried and inspected rather than silently dropped. From that staging record we create a real sale.order with the correct customer, fiscal position, delivery address, taxes and analytic distribution, and confirm it so Odoo does what Odoo is good at: reserving stock, generating the picking and running your existing delivery workflow.

Stock flows in both directions. A @api.depends compute on free-to-promise quantity, with configurable buffers and a per-listing safety stock, drives a queued push back to the platform so the storefront stops advertising units you have already committed elsewhere. Warehouse-scoped and multi-company setups are respected — the connector never reserves out of a warehouse the shop is not allowed to sell from. Fulfilment goes the other way: when a stock.picking is validated, the carrier and tracking reference are pushed to the platform inside its shipping SLA, and acknowledgement states are written back onto the order so your team sees one truth in Odoo. Payout reconciliation lands settlement statements as a social.commerce.payout record with lines matched to orders, commission and fee lines posted to the accounts you nominate, and an explicit variance list for anything that will not tie — the report finance will actually open every week.

Everything ships as maintainable Odoo, not a black box: a versioned __manifest__.py per target series, ir.model.access.csv plus record rules so a shop operator sees only their own accounts, list/form/kanban views and an operations dashboard in XML/OWL, QWeb reports for payout reconciliation and daily order intake, and an ir.actions.server and automated-action layer so routing rules can be extended without touching Python. Every remote call is idempotent and keyed, so a retried webhook cannot create a duplicate sale order, and all connector models are readable over the XML-RPC/JSON-RPC API for your BI tooling. The connector runs on Odoo Community; where you have Enterprise we wire into what you already pay for, including the full accounting reconciliation widget for payouts and Studio-compatible field extension. Odoo 17.0, 18.0 and 19.0 are supported, built against your exact series rather than back-ported blindly.

This is a build-to-order product, so nothing is downloaded and nothing is guessed. We start with a scoping call to confirm which platforms and shops you sell through, your API access level, warehouse and company topology, tax treatment for marketplace-facilitated sales, and how you want commission and fees posted. You get a written scope, a fixed price and a delivery date. Typical delivery is 2 to 4 weeks from confirmed scope, depending on how many storefronts and how much settlement complexity is in play. We build against a copy of your database, hand you a staging instance for UAT, then install on production in a scheduled window with a rollback plan. You receive the full source code and the git repository — no licence key, no obfuscation, and no dependency on us to keep running.

What you get

Installable module source code built and tested against your exact Odoo series (17.0, 18.0 or 19.0), Community or Enterprise

Installation and configuration on your environment: shop credentials, warehouse and company mapping, cron scheduling and webhook endpoint setup

Technical documentation covering the data model, field reference, webhook and cron behaviour, error-handling and retry semantics, and upgrade notes

End-user guide plus a live training session for your operations and finance teams, recorded so new staff can be onboarded later

UAT on a staging copy of your database against an agreed acceptance checklist, with a documented rollback plan before the production install

Post-go-live support window for defect fixes on the delivered scope, with a named point of contact

Git repository handover with full commit history — you own the code outright, no licence key and no vendor lock-in

Configuration handover pack: listing/SKU mapping sheets, account and journal setup, and the weekly payout reconciliation runbook

Who this is for

Direct-to-consumer brand owner selling on social storefronts

Sells through one or more social shops alongside their own site and needs every channel to land in the same Odoo database. Wants a single stock pool, one place to see margin after commission, and no more re-keying orders out of a seller centre app at the end of each day.

Ecommerce and channel operations manager

Owns day-to-day order flow and lives inside SLA windows for dispatch and tracking upload. Needs orders in Odoo within minutes of purchase, tracking pushed automatically when the picking is validated, and a visible error queue when a sync fails rather than a silent gap discovered by a customer complaint.

Finance controller or accountant

Has to close the month against platform payouts that arrive net of commission, shipping subsidies and promotion co-funding. Needs settlement lines matched to orders, fees posted to real accounts, marketplace-facilitated tax handled correctly, and a short honest variance list for the exceptions.

Odoo partner or in-house technical lead

Will maintain and extend the module after go-live. Wants clean Odoo conventions — proper models, security CSV and record rules, XML/OWL views, no monkey-patched core — plus the git repository and documentation so their team can add a storefront or change routing rules without calling us.

How Social Commerce Connector Compares

Criterion	ECOSIRE	Custom Build	Competitor	Odoo Native
Order capture from social storefronts	Webhook plus polling fallback into a staged raw-order model, then a real confirmed sale order	Whatever your developer has time for; staging and retry are usually the first things cut	Often a one-way import script with no staging layer, so a schema change loses orders	No connection at all — orders are typed in by hand or imported from CSV
Duplicate protection on retried webhooks	Idempotent on the remote order id across both webhook and cron paths	Achievable, but a common oversight until duplicates show up in production	Varies widely; several rely on timestamps rather than a stable key	Not applicable — there is no ingestion to duplicate
Stock sync back to the storefront	Free-to-promise compute with safety buffers, warehouse scoping and rate-limit-aware queuing	Buildable, but rate limits and multi-warehouse rules are where DIY builds stall	Typically a flat on-hand push, which oversells when other channels hold reservations	Odoo reserves internally but has no channel to publish availability to
Fulfilment and tracking push	Fires on picking validation, with platform acknowledgement written back onto the order	Depends on scope; SLA windows are easy to miss without acknowledgement handling	Usually present, but often fire-and-forget with no confirmation state	Tracking is stored in Odoo only; nothing reaches the platform
Payout and commission reconciliation	Settlement lines matched to orders, fees posted to your accounts, explicit variance list	Rarely reaches finance-grade matching before the budget runs out	Frequently out of scope, or a summary journal entry with no order-level match	Manual spreadsheet reconciliation against the seller centre statement
Security and multi-company scoping	`ir.model.access.csv` plus record rules per shop operator, multi-company rules enforced	Correct only if specified up front; usually added after an incident	Often a single global access group with no per-shop restriction	Standard Odoo rules apply, but there are no connector records to scope
Version fit and upgrade path	Built for your exact series (17.0/18.0/19.0), Community or Enterprise, with upgrade notes	Tied to whoever wrote it; upgrades depend on their availability	Version support lags; your series may be a back-port or simply unavailable	Upgrades cleanly, because there is no integration to upgrade
Code ownership and lock-in	Full source and git repository handed over — no licence key, no obfuscation	You own it, but usually without documentation or tests	Licence-keyed per database, frequently obfuscated, renewal required	Not applicable

Frequently Asked Questions about Social Commerce Connector

How long does delivery take?

This is a build-to-order module, not an instant download. Typical delivery is 2 to 4 weeks from confirmed scope. The clock starts when the platforms and shops in play are agreed, your API access is provisioned, and the written scope is signed off. Single-storefront builds with straightforward settlement land at the shorter end; multi-shop, multi-company or complex payout structures sit at the longer end. If your scope pushes beyond that range we tell you before you commit, not after.

Which Odoo versions are supported, and do we need Enterprise?

Odoo 17.0, 18.0 and 19.0. The module is written against your exact series rather than back-ported blindly, so the ORM and view APIs match what you run. It works on Community — Enterprise is not required. Where you do have Enterprise we wire into what you already pay for, such as the full accounting reconciliation widget for payouts and Studio-compatible field extension. Confirm your series on the scoping call and it is built for that target.

What happens with support and updates after go-live?

You get a post-go-live support window for defect fixes on the delivered scope, with a named contact. Beyond that we offer an optional maintenance agreement covering social platform API changes (which happen often and with little notice), Odoo minor-version upgrades, and new feature work. You also receive the full git repository, so nothing forces you to buy support from us — your own team or another Odoo partner can maintain it.

Will it stop us overselling when the same stock is listed in several places?

That is one of the main reasons people buy it. Available quantity is computed from Odoo's free-to-promise figure with a configurable buffer and per-listing reserve, scoped to the warehouses that shop is allowed to sell from. Changes push back to the storefront on a queued, rate-limit-aware job, so a sale on any channel reduces what the social shop advertises. It is not instantaneous — no connector can be, because the platform sets the API limits — but the lag is seconds to a couple of minutes and it is visible to you, not hidden.

Does it handle commission, fees and payout reconciliation?

Yes. Settlement statements are ingested into a payout record with lines matched back to the originating orders. Commission, transaction fees, shipping subsidies and promotion co-funding post to the accounts and journals you nominate during scoping. Anything that will not tie appears on an explicit variance list rather than being force-balanced. Marketplace-facilitated tax, where the platform remits on your behalf, is mapped through fiscal positions so your VAT/GST return stays correct.

What do you need from us to start?

Seller or developer API access for each storefront (or the ability to create it), a copy of your Odoo database or access to a staging instance, your warehouse and company topology, your chart-of-accounts decisions for commission and fees, and one person who can answer operational questions during the build. We work against a copy of your database, so production is untouched until the agreed install window.

How do you make sure this does not break our live database?

We build and test against a copy of your database, then hand you a staging instance for UAT against an agreed acceptance checklist. The production install runs in a scheduled window with a database backup taken first and a documented rollback plan. The module adds its own models and extends existing ones through standard Odoo inheritance — it does not patch core — so uninstalling leaves your sale, stock and accounting data intact.