ShoppingFeed Store Management

This is the installation and configuration guide for ShoppingFeed Store Management, the module you downloaded from your ECOSIRE dashboard or the Odoo App Store. The build you download today is 2.3.0; releases 2.4.0 to 2.4.4 are built and awaiting publication, and the "What's new" sections for them describe what reaches you with that release.

Technical name	shoppingfeed_store_management
Odoo versions	17.0, 18.0, 19.0 (Community or Enterprise)
Current shipped version	17.0 → 17.0.2.3.0, 18.0 → 18.0.2.3.0, 19.0 → 19.0.2.3.0 (2.4.4 built, awaiting publication)
Price	$499 USD — one-time, per Odoo version
Odoo module licence	OPL-1 (Odoo Proprietary License)
Category	Connector

The module installs and runs standalone — nothing to unlock and no separate companion module to install first. Licensing is contractual: buying it entitles you to run the software and receive updates, per the licence terms above.

What's new in 2.4.4 (awaiting publication) — the dashboard is readable everywhere

A presentation release. Nothing about your configuration changes and there is no re-sync to run.

• The dashboard follows Odoo's dark mode. Odoo serves dark mode as its own stylesheet bundle, and the dashboard was only reacting to a theme attribute Odoo never sets — so a dark-mode user got a bright white dashboard. A dark stylesheet now ships in that bundle and re-themes every card, chart, banner and skeleton.
• The Order Status doughnut draws. It was built empty and then updated, which left a legend sitting over a blank area. Charts are now drawn from the loaded figures after the page renders, take their colours from the active theme, and a period with no orders says so instead of showing an empty legend that reads like a failure.
• No blank KPI values. Total Revenue and Avg. Order Value showed nothing until the first response arrived; the first load now shows a spinner and skeleton cards, never an empty tile.
• Empty and error states say what to do. An empty period shows a banner pointing at Sync Now; a load that fails shows its message at the top of the page with Try again and Settings, rather than an all-zero dashboard with the error below the fold.
• Lists stay readable on a phone. Orders, Customers, Locations and Logs use short column headers, keep secondary columns optional, show status as a badge, and explain themselves when empty. Analytics gains a real list — report, store, period, dates, status — and an empty-state guide, in place of a bare name column.

What's new in 2.4.3 (awaiting publication) — hardened against 36 real-world failure cases

Every escaped defect this connector has ever met is now bound to an executed test in the shipped suite, so a regression fails the build instead of reaching you. Nothing about your configuration changes. Re-run Test Connection only if you had a refund webhook pointed at this connector (see the last item).

• The Operations Center can actually run what it offers. Shoppingfeed → Operations → Run Operations shipped without a Run button, so every operation it listed was unreachable. Run Operation now runs the selected import or export against the chosen instance, honours the From/To dates on the order imports, and refuses explicitly if an operation has no implementation in your build. The result is reported in the sync log.
• An imported order shows its ShoppingFeed evidence. The sale order form carries a ShoppingFeed panel with the platform order id, the instance it came from, and the platform's fulfilment and financial status. The panel appears only on orders imported from ShoppingFeed; ordinary quotations are unchanged.
• Two variants of one product keep two mappings. Variants of one ShoppingFeed product share the product id and differ only by their reference (SKU). The mapping was matched on the product id or the variant id, so the second variant silently rewrote the first and one sellable unit disappeared. Identity is now the SKU. If a variant was lost this way, re-run Import Products once; the missing mapping is recreated.
• A non-HTTP image reference is refused instead of stored as a broken picture. An object key, a bare image id or an s3:// URI used to be handed to the HTTP client and its failure body was saved as the product image. Such a reference is now refused and the reason is recorded on the image record. ShoppingFeed publishes no image-resolution resource, so the module does not guess one.
• Refund import is explicitly unsupported, and now says so. ShoppingFeed's published API has one refund route, which posts a refund to an order; there is no resource that lists or returns refunds. Earlier builds still accepted the refund webhook and queued an Import Refund job whose handler had been withdrawn, so the sender saw "received" and the job later failed with Method not found. The webhook now answers with an explicit refusal and queues nothing, and Import Refunds and Import Payout Report are gone from the Operations Center. Refunds you record in Odoo still reconcile exactly as before — subtotal, tax and total stay distinct, and credit notes are unchanged.
• 33 new regression tests cover order and product idempotency, multi-store isolation, pagination to the terminal cursor, per-record failure isolation, currency handling, masked personal data, external-identifier search, dashboard date-range inclusivity, access isolation between companies, and the unsupported-capability surface.

What's new in 2.4.2 (awaiting publication) — three screens, and one buyer per contact

This release adds views the connector was missing, corrects the version this page and the store listing advertise, and moves sign-in to the login route ShoppingFeed publishes today. After upgrading, click Test Connection once on each ShoppingFeed instance — that is the only thing to re-check.

• Sign-in uses only ShoppingFeed's published login route. ShoppingFeed now publishes its username/password login as POST /v1/account/login; the older POST /v1/auth has been withdrawn from its API specification. Earlier releases tried the old route first and fell back to the new one. 2.4.2 sends only the published route, with the same credentials. If ShoppingFeed ever moves it again, the error says the route moved instead of looking like a wrong password. A wrong password is still reported as a wrong password.

• A failed order download leaves a record. When ShoppingFeed cannot list your orders, the import job is marked Failed with ShoppingFeed's message, and an error line appears in the sync log.

• 17.0 and 18.0 now carry the full connector. Until this release the 17.0 and 18.0 builds could connect, test the connection and read stock, but they did not import or export orders or products — order import and acknowledgement, shipment push with carrier and tracking, catalogue import, price and stock export, and warehouse import existed only on 19.0. 2.4.2 rebuilds both lines from the 19.0 connector, so every series now ships the same capabilities and the same test suite. Upgrade in place; no data is removed.

• The buyer resolver is now one implementation on every series. On 17.0 and 18.0 the order import and the customer import each resolved a buyer their own way, so a store running both could end up with two contacts for the same buyer; they disagreed on email case, on phone formatting (a buyer stored as +33 6 12 34 56 78 never matched the 06 12 34 56 78 ShoppingFeed sends) and on rejecting junk names. Both now share one matcher — email, then phone, then exact name — and one guest contact for anonymous checkouts. This is the resolver the 19.0 line has shipped since 2.4.0, now on every series with its tests.

• ShoppingFeed Products has a kanban and a search view. A mapping stuck in error or pending is visible at a glance instead of found by filtering, and the search view carries Synced / Pending / Sync-Errors / Archived filters with group-by Sync Status and Instance.

• The dashboard charts drill down. Clicking a segment of the Order Status doughnut opens exactly the orders that segment counts — the same domains the tile is computed from, so the list reconciles with the number you clicked — and clicking the sales trend opens the orders behind the period on screen.

• The listing and this page advertise the right version, and the app description now links a live demo at shoppingfeed.demo.ecosire.com.

What's new in 2.4.1 (awaiting publication) — install repair

If you are on 19.0.2.4.0, this is the release you install. 2.4.0 was published with a refactor left half-finished and could not be installed at all — not from the store, not from the branch. Nothing else changed beyond the repair and one determinism defect it exposed; the version is bumped so that a build that cannot install is never the same release as the one that can.

• 19.0.2.4.0 no longer fails to install. The 2.4.0 release renamed a batching constant and removed a second one inside the API client, but left callers importing the old names — so Odoo raised ImportError: cannot import name 'MAX_BATCH_SIZE' the moment it loaded the module. Installing 2.4.0 was impossible, and so was upgrading to it from 2.3.0. The callers now use the renamed constants, and the 20-file limit on the order-document upload is enforced again as the published API requires.
• The Locations screen's Import Warehouses button works. 2.4.0 added the button to the view but called a method the model never defined, which is the second half of why the release could not install. It now imports the warehouses ShoppingFeed publishes for the connected store and reports what it did.
• Importing warehouses with more than one store connected reads a defined store. The button used to take whichever connected instance the database happened to return first, so the imported warehouses could belong to a different store between two runs of the same button. It now takes the lowest-numbered connected instance, or the store whose form you opened the button from.

What's new in 2.4.0 (awaiting publication) — the full published API, warehouses and stock

Added

• Your ShoppingFeed warehouses now import. Configuration → Locations reads GET /v1/store/{storeId}/warehouse and creates one mapping row per warehouse, carrying the warehouse name, whether ShoppingFeed marks it as the store default, and its address (street, city, state, postal code, country). Re-running the import updates the existing rows instead of duplicating them, so it is safe to run whenever you add a warehouse in ShoppingFeed.
• Stock import and export actually move stock. A location with an Import Stock Warehouse mapped reads the catalog inventory (GET /v1/catalog/{catalogId}/inventory) and reconciles that quantity onto the mapped Odoo warehouse; a location with Export Stock Warehouses mapped sums their on-hand stock and pushes it back (PUT /v1/catalog/{catalogId}/inventory, in batches of 100 as the API requires). Both directions skip any reference with no matching Odoo product and report the count in the log, rather than writing a zero that would wipe real stock.

Fixed

• The rest of the published ShoppingFeed API is now wired up. Previous releases could reach 10 of the 53 operations ShoppingFeed publishes. This release covers the full published surface — catalog and pricing, channels, feeds, taxonomy, the complete store-order workflow (accept, acknowledge, unacknowledge, ship, deliver, cancel, refuse, refund), order tags, order documents and shipments, the store timeline, tickets and warehouses. Every call is addressed through a route catalog transcribed verbatim from the published contract, and a route the contract does not define cannot be sent.
• Connecting no longer fails silently when ShoppingFeed moves its login. ShoppingFeed has republished its authentication from POST /v1/auth (the route our contract certifies, and still the one tried first) to POST /v1/account/login. If the first route answers 404, 405 or 410, the module now retries the same credentials against the published replacement and logs which route worked. A wrong password still stops immediately.
• The Locations screen no longer shows fields nothing fills. The location name, ID, default flag and address were displayed but written by no code, so a mapping row looked empty whatever ShoppingFeed held. They are now populated by the warehouse import above.
• The "Legacy (Fulfillment Service)" flag is gone — ShoppingFeed publishes no warehouse field behind it, so the column could only ever be blank.
• Log and queue-job timestamps are the framework's own again. Created On and Last Updated were re-declared as plain read-only dates, shadowing Odoo's automatic audit columns.

What's new in 2.3.0 — reliability and workflow permissions

Version 2.3.0 fixes two defects that could be hit in normal use and tightens who may drive a record through its workflow.

• Risk assessments save correctly. Creating or updating a risk record previously failed with "Unsupported tracking on field risk_indicators". The field is no longer chatter-tracked, and risk records save normally.
• The dashboard no longer overwrites another user's date range. Choosing a period used to store that range on the connection record, so two people looking at different periods changed each other's view. The dashboard now reads without writing; the saved range on the connection form is yours to set and is left alone.
• Workflow buttons require the ShoppingFeed Manager group. Validating a payout, issuing a credit note, resolving a risk, activating a carrier or workflow, creating or deleting a webhook, testing a connection and generating analytics are now restricted. Users outside the group see a clear message naming the group instead of silently changing the record. Grant the group under Settings → Users & Companies → Users. Scheduled actions and other automated runs are unaffected.
• Faster backend page loads. A charting library that the module never used was still being downloaded with every backend page. It has been removed; dashboard charts are unchanged.

What's new in 2.2.0 — official ShoppingFeed API alignment

Version 2.2.0 replaced earlier unpublished endpoint guesses with the current official ShoppingFeed API surface (https://developer.shopping-feed.com/):

• Authentication uses the documented password grant: POST /v1/account/login exchanges your ShoppingFeed username and password for a bearer token, and GET /v1/me reads your account and store list.
• Orders are read through store-scoped routes (/v1/store/{store_id}/order), so every order belongs to an explicit ShoppingFeed store.
• Catalog references and inventory are read and updated through catalog-scoped routes (/v1/catalog/{catalog_id}/...), with inventory updates batched at 100 rows per call.
• Explicit store and catalog IDs are recorded on the connection. Single-store accounts are discovered automatically; multi-store accounts get a readable selection prompt instead of guessing.
• Rate limiting is handled: the documented maximum page size of 200 is used, and X-RateLimit-Wait responses are retried with bounded waits instead of hammering the API.
• Customers are derived from published order data, because ShoppingFeed does not publish a standalone customer endpoint.

Requirements

Requirement	Detail
Odoo	17.0, 18.0 or 19.0, Community or Enterprise. Self-hosted or Odoo.sh — Odoo Online (SaaS) cannot install third-party modules
Odoo apps	base, sale_management, stock, account, delivery, mail, web, portal, product, contacts, digest — Odoo installs any that are missing automatically
Python packages	requests
Platform account	A ShoppingFeed account with API access

Install the Python packages into the same interpreter that runs Odoo:

sudo -u odoo pip install requests

Installation

1. Download the ZIP for your Odoo version

Sign in at ecosire.com and open your dashboard downloads, or use the ZIP attached to your Odoo App Store purchase.

2. Extract into your addons path

unzip shoppingfeed_store_management_v19_*.zip -d /opt/odoo/addons/
ls /opt/odoo/addons/shoppingfeed_store_management/__manifest__.py   # sanity check

The module must end up as a single top-level shoppingfeed_store_management/ directory with __manifest__.py directly inside it. If your ls check fails, the folder landed one level too deep or too shallow — move it so the path above resolves.

3. Restart Odoo and install

sudo systemctl restart odoo

1. Go to Apps and click Update Apps List (developer mode must be on).
2. Search for ShoppingFeed Store Management and click Install.
3. Odoo pulls in the Odoo apps listed above automatically.

When the install finishes, a Shoppingfeed menu appears in the main Odoo app switcher.

Configuration

Connect to ShoppingFeed

Create a connection record on the shoppingfeed.instance model. The fields the module defines for the connection are:

Field	Technical name	Type	Required
Instance Name	name	Char	Yes
Shoppingfeed Shop URL	shop_url	Char	Yes
Company	company_id	Many2one	Yes
API Username	api_key	Char	No
API Password	shared_secret	Char	No
Access Token	access_token	Char	No
API Secret (legacy)	password	Char	No
Legacy Store Token	store_token	Char	No
ShoppingFeed Store ID	shoppingfeed_store_id	Char	No
ShoppingFeed Catalog ID	shoppingfeed_catalog_id	Char	No

The fields marked Yes are enforced by the model — Odoo will not let you save the record without them. The technical name is the reliable identifier if your screen wording differs.

There are two ways to authenticate, and you need exactly one of them:

• Paste a token — copy the bearer access token from your ShoppingFeed account into access_token, or
• Username and password — fill api_key (your ShoppingFeed username) and shared_secret (your ShoppingFeed password). The module exchanges them once using the documented password grant and keeps the returned token. Since 2.4.2 the module logs in only through ShoppingFeed's published POST /v1/account/login (the older POST /v1/auth is withdrawn and never sent). A wrong password stops immediately; a route ShoppingFeed no longer serves is reported as moved, so it is not mistaken for a credentials problem.

The legacy password and store_token fields exist only so upgrades from older versions never lose data — the current official API surface does not read them.

If you leave the store and catalog IDs empty, the module reads your account with GET /v1/me: a single-store account is selected automatically, and a multi-store account shows a readable selection prompt. Once selected, the ShoppingFeed store ID and catalog ID are stored on the connection and every order, reference and inventory call is scoped to them.

The module contacts https://api.shopping-feed.com (HTTPS, outbound). Your firewall must allow outbound HTTPS to that host.

Manual token entry endpoint

The in-app token entry form posts to POST /shoppingfeed/save_token — a logged-in-Odoo-user, CSRF-protected route that saves a manually entered ShoppingFeed API key or bearer token onto the chosen instance record and returns you to its form. It exists so a key can be pasted from ShoppingFeed without editing technical fields by hand.

The same record carries 3 behaviour checkboxes — auto_confirm_order, auto_create_invoice, auto_validate_invoice. They gate what the module is allowed to do automatically once it is connected. Leave anything you are not ready for switched off, and turn them on one at a time.

API behaviour to be aware of

• Requests page at the documented maximum of 200 records per call.
• Inventory updates are sent in batches of 100 rows per call.
• When the API answers with an X-RateLimit-Wait header, the module waits as instructed and retries — with a bounded number of retries, so a long throttle window surfaces as an error in the logs instead of an endless loop.
• Customers are derived from the order data ShoppingFeed publishes; there is no standalone customer endpoint to import from.

Scheduled actions

The module installs 11 scheduled actions (Settings → Technical → Scheduled Actions):

Scheduled action	Runs every	Enabled on install
Shoppingfeed: Sync Customers	60 minutes	Yes
Shoppingfeed: Sync Inventory	10 minutes	Yes
Shoppingfeed: Process Queue Jobs	5 minutes	Yes
Shoppingfeed: Auto Risk Detection	30 minutes	Yes
Shoppingfeed: Generate Analytics	4 hours	Yes
Shoppingfeed: Webhook Health Check	60 minutes	Yes
Shoppingfeed: Cleanup Old Logs	24 hours	Yes
Shoppingfeed: Process Workflows	10 minutes	Yes
Shoppingfeed: Daily Summary Report	1 day	Yes
Shoppingfeed: Apply Repricing Rules	1 hour	Yes
Shoppingfeed: Evaluate SLA Breaches	30 minutes	Yes

Intervals above are the shipped defaults. Adjust them to your volume — but be aware that the platform, not Odoo, sets the API rate limits, and shortening a sync interval is the usual cause of throttling errors in the logs.

Using the module

The module's menu is laid out as:

• Shoppingfeed → Dashboard
• Shoppingfeed → Orders
• Shoppingfeed → Refunds
• Shoppingfeed → Products
• Shoppingfeed → Customers
• Shoppingfeed → Payouts
• Shoppingfeed → Analytics
• Shoppingfeed → Operations — Run Operations, Queue Jobs, Logs, Repricing Rules, SLA Compliance, Low-Quality Feed
• Shoppingfeed → Configuration — Instances, Locations, Payment Gateways, Scheduled Actions, Webhooks, Marketplace Channels

A normal first run is:

1. Save the connection record and confirm the module reports a successful connection before importing anything.
2. Review the mapping records so imported data lands on the right Odoo records.
3. Run a small import first — restrict it by date or by a handful of products — and check the results before letting the scheduled actions take over.
4. Watch the log records during the first full sync. Failures are recorded there rather than raised at the user.

Troubleshooting

Connection and syncing

Symptom	Cause and fix
The connection will not validate	Provide either an access token, or the API username and API password. Most failures are a mistyped password, or credentials created for a sandbox while the module points at production (or vice-versa).
The requests library is required	requests is missing from Odoo's Python environment. Install it into the interpreter that runs Odoo.
Nothing syncs even though the connection is fine	The scheduled actions are disabled at the Odoo level, or Odoo's cron worker is not running. Check Settings → Technical → Scheduled Actions and that --max-cron-threads is greater than zero.
Sync starts then stops part-way	Read the module's log records for that run. Rate limiting and rejected field values are the two common causes; both are logged with the platform's own error text. When the API asks the module to wait (X-RateLimit-Wait), it does — a long wait surfaces as an error entry, not a crash.
Records import but map to the wrong Odoo values	Fix the mapping records under the module's configuration, then re-run the import.
Duplicated products or customers	Run the initial import once. If a first attempt half-finished, check the existing records before re-running rather than importing on top.
Orders from the wrong ShoppingFeed store appear	A different store was selected during discovery. Set the explicit shoppingfeed_store_id on the connection and re-run the import.
A refund webhook is answered with a refusal	Expected from 2.4.3 on (on 2.3.0 the refund webhook queues an import job that cannot fetch anything). ShoppingFeed publishes no resource that lists refunds, so refund import is unsupported and the webhook says so instead of queuing a job that cannot run. Record the refund in Odoo; it reconciles as before.
Run Operation says the operation has no implementation	The selected operation is advertised by the wizard but not implemented in your build. Nothing was run. Update to the current release; if the message persists, contact support with the operation name.

Version history

Odoo version	Version you download today
17.0	17.0.2.3.0
18.0	18.0.2.3.0
19.0	19.0.2.3.0

ECOSIRE module versions are <odoo major>.<module major>.<minor>.<patch>, so 19.0.2.3.0 is the Odoo 19 build of module version 2.3.0. Release 2.4.4 is built and awaiting publication. Your installed version is shown in Apps.

2.4.3 is the hardening release (36 real-world failure cases bound to executed tests, the Operations Center Run button, the ShoppingFeed panel on imported orders, SKU-based variant identity, refused non-HTTP image references, refund import explicitly unsupported); 2.4.2 moves sign-in to the published login route, adds the missing product views and the dashboard drill-downs and brings 17.0 and 18.0 to the full 19.0 connector (order and catalogue sync, warehouses, the shared buyer resolver); 2.4.1 is the install repair, 2.4.0 wired the full published API and added warehouse and stock import/export, 2.3.0 was the reliability and permissions release, and 2.2.0 was the official ShoppingFeed API alignment. The 2.4.0 install defect never affected the 17.0 or 18.0 trees, because neither carries the renamed constants. 2.1.x removed the historical licence-client dependency so the module installs standalone, and pinned the canonical API host api.shopping-feed.com.

Support

• General troubleshooting
• Email: info@ecosire.com
• Support portal