Allegro Store Management
This is the installation and configuration guide for Allegro Store Management, the module you downloaded from your ECOSIRE dashboard. Everything on this page describes the allegro_store_management module exactly as it ships today — the facts below were read out of the released build, not from a roadmap.
| Technical name | allegro_store_management |
| Odoo versions | 17.0, 18.0, 19.0 (Community or Enterprise) |
| Current shipped version | 17.0 → 17.0.2.2.7, 18.0 → 18.0.2.2.7, 19.0 → 19.0.2.2.7 |
| Price | $499 USD — one-time |
| Odoo module licence | OPL-1 |
| Category | Connector |
The module ships as a separate build for each Odoo major version (17.0, 18.0, 19.0) and each is a separate product. Download the build that matches the Odoo version you actually run — a 17.0 build will not install on Odoo 19. There is no activation key and no licence client to install: since module version 2.1.0 the connector installs and runs standalone, and licensing is covered contractually by the OPL-1 licence.
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, product, contacts — Odoo installs any that are missing |
| Python packages | requests |
| Platform account | An Allegro seller account with API access (an application registered on developer.allegro.pl) |
There is no separate ECOSIRE licence module to install and no key to activate — the connector is self-contained.
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. Pick the build that matches the Odoo version you run (see the note above).
2. Extract into your addons path
unzip allegro_store_management_v19_*.zip -d /opt/odoo/addons/
ls /opt/odoo/addons/allegro_store_management/__manifest__.py # sanity check
The module must end up as a single top-level allegro_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
- Go to Apps and click Update Apps List (developer mode must be on).
- Search for Allegro Store Management and click Install.
- Odoo pulls in the Odoo apps listed above automatically.
When the install finishes, a Allegro menu appears in the main Odoo app switcher. Nothing else is required — the module is usable immediately, with no activation step.
User access levels
The module ships three user groups (Settings → Users → Groups or a user's access-rights tab):
| Group | What it can do |
|---|---|
| allegro User | View Allegro data — orders, products, customers, logs, dashboards. |
| allegro Manager | Everything an allegro User can do, plus the operational actions: run or retry queue jobs, cancel them, respond to disputes, and generate/submit JPK_FA e-invoicing XML. |
| allegro Administrator | Full access, including configuration. |
Since module version 19.0.2.1.1 the operational actions are enforced, not just hidden from the menus: a user below the allegro Manager group who calls queue process, retry failed, cancel, queue-line process/retry, dispute response, or JPK_FA XML generation / KAS submission directly gets an Odoo Access Error. Read-only users keep full read access, and existing Manager/Administrator setups behave exactly as before.
Multi-company behaviour
Every Allegro record is company-scoped by record rule (33 rules across the module), so a user working in company A never sees company B's Allegro data. Since 19.0.2.1.1 this includes the two models that previously fell outside the net — the RODO-masked buyer profiles (Allegro Buyers (Masked)) and the Allegro Pay (BNPL) records. Run one configuration record per company and the data stays isolated end to end.
Fault isolation during syncs
Since module version 2.0.5, a single bad marketplace record can no longer poison a whole sync run. Every record the connector imports, exports, or acts on is processed inside its own database savepoint: if one order, product, or customer is rejected (malformed field, platform error), that record alone rolls back, the run continues, and the good records before and after it are still committed. Failures are written to the sync log with the platform's error text, so a partially-successful run is visible and re-runnable rather than silently lost.
Configuration
Connect to Allegro
Create a connection record on the allegro.configuration model. The fields the module defines for the connection are:
| Field | Technical name | Type | Required |
|---|---|---|---|
| Configuration Name | name | Char | Yes |
| Client ID | client_id | Char | Yes |
| Client Secret | client_secret | Char | Yes |
| Refresh Token | refresh_token | Char | Yes |
| Company | company_id | Many2one | Yes |
| Allegro URL | allegro_url | Char | No |
| Use Sandbox | sandbox | Boolean | No |
| Marketplace | marketplace | 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.
The same record carries 7 behaviour checkboxes — sync_products, sync_orders, sync_customers, sync_inventory, auto_sync_products, auto_sync_orders, auto_sync_customers. 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.
The module's own source contacts these hosts: api.allegro.pl, api.allegro.pl.allegrosandbox.pl, allegro.pl, allegro.pl.allegrosandbox.pl, developer.allegro.pl, plus api.zippopotam.us (best-effort state-from-postal-code resolution when enriching buyer addresses). Your firewall must allow outbound HTTPS to them.
Public endpoints this module exposes
The connector serves one externally reachable endpoint. The path is relative to your Odoo base URL
(web.base.url), so the address you register on the platform looks like
https://erp.example.com/allegro/webhook.
| Endpoint | Method | Auth | Purpose |
|---|---|---|---|
/allegro/webhook | POST | Public (unauthenticated) | Receives Allegro webhook deliveries. This is the URL to register as your notification destination in the Allegro seller portal. |
/allegro/webhook fails closed. A delivery is acknowledged only after an active webhook record
(model allegro.webhook, status active) verifies the delivery's signature against the raw request
body and headers. Anything that fails verification is answered HTTP 403 and nothing is processed
from it, so the endpoint being publicly reachable does not make it publicly usable. Rejected
deliveries are written to the Odoo log with the calling IP address.
Create and enable the webhook record — with its signing secret — before you register the URL on the platform; until one exists, every delivery is refused.
The module also exposes three internal JSON-RPC endpoints that require a logged-in Odoo session (auth='user') — nothing to register anywhere, they are listed so a custom integration or monitor knows they exist: /allegro/dashboard/data (loads the dashboard's KPIs and charts), /allegro/api/sync (what the dashboard's Sync Now button calls), and /allegro/api/status (connection state and last-sync timestamps).
Scheduled actions
The module installs 6 scheduled actions (Settings → Technical → Scheduled Actions):
| Scheduled action | Runs every | Enabled on install |
|---|---|---|
| allegro: Sync Products | 1 hour | Yes |
| allegro: Sync Orders | 30 minutes | Yes |
| allegro: Sync Customers | 6 hours | Yes |
| allegro: Sync Inventory | 15 minutes | Yes |
| allegro: Test Connection | 1 day | Yes |
| allegro: Cleanup Old Logs | 1 day | 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:
- Allegro → Dashboard
- Allegro → Orders
- Allegro → Products
- Allegro → Customers
- Allegro → Programs — Allegro Smart!, Allegro Lokalnie, Categories
- Allegro → Logistics — Returns, Disputes, Carriers, Allegro One Box Points, Locations
- Allegro → Operations — Import Wizard, Export Wizard, Mapping Wizard, Test Connection, Logs, Reports, Workflows, Auto Workflows, Allegro Buyers (Masked)
- Allegro → Insights — Analytics, Risk, Daily Digest
- Allegro → Finance & Compliance — Settlements, Refunds, Allegro Pay (BNPL), JPK_FA Exports (PL)
- Allegro → Configuration — Settings
A normal first run is:
- Save the connection record and confirm the module reports a successful connection before importing anything.
- Review the mapping records so imported data lands on the right Odoo records.
- 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.
- Watch the log records during the first full sync. Failures are recorded there rather than raised at the user.
Troubleshooting
Installation
| Symptom / error code | Cause and fix |
|---|---|
| Odoo refuses to install the module | The ZIP you extracted does not match your Odoo version (a 17.0/18.0 build on Odoo 19, or the folder landed one level too deep — see step 2). |
The requests library is required | requests is missing from Odoo's Python environment. Install it into the interpreter that runs Odoo. |
| Access Error when running a queue job, dispute response, or JPK_FA submission | Your user is below the allegro Manager group — see User access levels. Ask an administrator to grant the group. |
Syncing
| Symptom | Cause and fix |
|---|---|
| The connection will not validate | Re-check every required field in the table above. Most failures are a mistyped secret, or credentials created for a sandbox while the module points at production (or vice-versa). |
| 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. |
| 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. |
Version history
| Odoo version | Version you download today |
|---|---|
| 17.0 | 17.0.2.2.7 |
| 18.0 | 18.0.2.2.7 |
| 19.0 | 19.0.2.2.7 |
ECOSIRE module versions are <odoo major>.<module major>.<minor>.<patch>, so 19.0.2.2.7 is the Odoo 19 build of module version 2.2.7. Your installed version is shown in Apps.
Recent releases in user terms:
- 2.2.7 — the dashboard is easier to read and to use on a phone: text meets WCAG 2.2 AA contrast in light and dark mode, the header stacks instead of running past the edge of a narrow screen, a long connection name truncates, error and first-run notices sit at the top of the page, the loading state says what it is doing instead of showing a page of zeros, a chart with no data says so rather than showing an empty area under a legend, Recent Activity shows readable entries (“Product import completed”, with the local date and time), the KPI cards and quick actions open their screens again, and an empty premium list explains itself instead of showing a blank panel. The Order Status chart no longer counts a cancelled order as both Failed and Cancelled.
- 2.2.6 — the daily sales chart shows the current day and agrees with the totals printed beside it: the series stopped one day short of its own end date, so an order placed today was counted by the “total sales” figure and missing from the chart under it, and a 90-day or year range charted its first 30 days instead of the most recent ones.
- 2.2.5 — the dashboard never crosses a company line: a user allowed in one company saw other companies' Allegro revenue, order counts, queue and daily series; every figure is now bounded to the companies that user may operate, the daily series counts Allegro orders only (it summed every sale order), and sync health is read per connection in scope.
- 2.2.4 — hardened against 36 known real-world connector failure cases, each pinned by a test: sync counters describe the current run instead of accumulating; a partial sync no longer advances the last-sync timestamp (the failed window is retried); the dashboard's end date includes its own day; imported products and orders keep the Allegro connection they came from, so a second account selling the same SKU cannot overwrite the first account's records; orders import with their finance, shipping, payment, currency and tax fields and are booked in the currency the buyer paid in; a cross-currency import with no exchange rate is refused instead of booked at 1:1; a failed connection test keeps its explanation on the dashboard; offers map images, category, brand, GTIN, publication status and variant identifiers; the 17.0 build installs again (an action-window declaration Odoo 17 rejects).
- 2.2.3 — the API status endpoint answers correctly on the 18.0 and 17.0 builds again; it had been returning an error on those two series only, while the 19.0 build was unaffected. No action is needed if you are on 19.0.
- 2.2.2 — the dashboard reports every Allegro connection you run (and names them) instead of only the first one, and its figures are scoped to the companies you are allowed to work in; starting a synchronization now requires the allegro Manager group; a malformed Client ID or Client Secret is refused when you save it rather than surfacing as a bare
invalid_clientlater; a failed shipping-rate write logs the delivery method and connection it failed on. - 2.2.1 — the dispute and claim surface works again, and the module's whole test suite runs again; the six post-purchase and returns operations that Allegro publishes only under its beta media type are now sent that type; four routes Allegro does not publish are no longer called, so stock push and offer create/edit address the routes the platform actually serves.
- 2.2.0 — 28 further Allegro operations gained a real client method (advertising badges, the disputes/"issues" API including its chat thread, buyer and seller messaging, flexible bundles, loyalty promotions, price-automation rules, offer fee preview, ratings, return policies, warranties, additional-service groups, points of service, shipping rates and delivery methods); the client now dispatches through a route registry taken verbatim from the ECOSIRE platform contract, and the three operations Allegro has withdrawn are refused with the withdrawal date and reason instead of being sent.
- 2.1.1 — operational actions (queue process/retry/cancel, dispute response, JPK_FA generation and KAS submission) restricted to the allegro Manager group; RODO buyer profiles and Allegro Pay records became company-scoped like every other Allegro model.
- 2.1.0 — licence client removed: the module installs and runs standalone, no activation key, no separate dependency.
- 2.0.5 — per-record fault isolation in every sync/import run: one bad record rolls back alone instead of aborting the batch.