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. Everything on this page describes the shoppingfeed_store_management module exactly as it ships today — the facts below were read out of the released build, not from a roadmap.

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.4.1
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.1 — 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 — 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/auth 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. The certified route is POST /v1/auth; ShoppingFeed has since republished its login as POST /v1/account/login, so if the first route answers 404, 405 or 410 the module retries the same credentials against the published replacement and logs which route worked. A wrong password stops immediately rather than moving on.

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.

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.4.1

ECOSIRE module versions are <odoo major>.<module major>.<minor>.<patch>, so 19.0.2.4.1 is the Odoo 19 build of module version 2.4.1. Your installed version is shown in Apps.

The 19.0 line leads the release: 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 17.0 and 18.0 builds remain on 2.3.0 — the 2.4.x work was made on Odoo 19 and neither tree is affected by the 2.4.0 install defect, 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