Blibli Store Management
This is the installation and configuration guide for Blibli Store Management, the ECOSIRE connector that links your Odoo database to your Blibli seller account — products, orders, customers, stock, payouts and refunds, with a scheduled-action and queue-driven sync engine. Everything on this page describes the blibli_store_management module exactly as it ships today — the facts below were read out of the released build, not from a roadmap.
| Technical name | blibli_store_management |
| Odoo versions | 17.0, 18.0, 19.0 (Community or Enterprise) |
| Current shipped version | 17.0 → 17.0.1.3.3, 18.0 → 18.0.1.3.3, 19.0 → 19.0.1.3.3 |
| Price | $499 USD — one-time, per Odoo version |
| Odoo module licence | OPL-1 (Odoo Proprietary License v1.0) |
| Category | Connector |
| Support | info@ecosire.com |
Each Odoo major version is a separate product and a separate download — buy and install the build that matches the Odoo version you run.
Licence-free build
Since version 1.1.0 the module installs and runs standalone. There is:
- no activation key to paste anywhere,
- no licence-client module to download first,
- no phone-home check that can block the connector after install.
The module is licensed contractually under OPL-1: you need a valid purchase to use it, but nothing in the code gates installation, connection or syncing. Every capability documented on this page works the moment the module is installed.
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 — all standard Odoo; Odoo installs any that are missing |
| Python packages | requests |
| Platform account | A Blibli seller account with API access — the API Key and API Secret come from Blibli's Merchant Tools Administration (MTA) |
There is no separate ECOSIRE dependency to install. Install the Python package 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 download the build matching your Odoo version from your dashboard.
2. Extract into your addons path
unzip blibli_store_management_v19_*.zip -d /opt/odoo/addons/
ls /opt/odoo/addons/blibli_store_management/__manifest__.py # sanity check
The module must end up as a single top-level blibli_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 Blibli Store Management and click Install.
- Odoo pulls in the standard Odoo apps listed above automatically.
When the install finishes, a Blibli menu appears in the main Odoo app switcher. Nothing else is required — no licence activation step exists.
Configuration
Connect to Blibli
Go to Blibli → Configuration → Instances and create a connection record. The connection fields are:
| Field | Technical name | Type | Required |
|---|---|---|---|
| Instance Name | name | Char | Yes |
| Company | company_id | Many2one | Yes |
| API Key | api_key | Char | No |
| API Secret | api_secret | Char | No |
| API Seller Key | api_seller_key | Char | No |
| Signature Key | signature_key | Char | No |
| MTA Username | username | Char | No |
| Channel ID | channel_id | Char | No |
| Store ID | store_id | Char | No |
| Merchant ID | merchant_id | Char | No |
The fields marked Yes are enforced by the model — Odoo will not let you save the record without them. The API Key and API Secret come from Blibli's Merchant Tools Administration; they are stored as password fields visible only to system-level users.
The API Seller Key, Signature Key and MTA Username come from the same Seller Center. The seller key is sent as the Api-Seller-Key header on every request; the signature key is optional and, when you set it, each request also carries the Signature and Signature-Time headers. Channel ID is the platform name lowercased with spaces turned into dashes and defaults to your company name when left empty, and Store ID defaults to 10001. The store, channel, username and merchant parameters travel on every call, while the seller-key and signature headers appear only once you have filled those fields in.
Save the record, then use the Test Connection action on the instance to verify the credentials before importing anything. The instance status moves between Draft, Connected and Error so you can see at a glance whether the last connection attempt succeeded.
The same record carries the settings the sync engine uses when it creates Odoo documents:
- Order automation — three checkboxes, all off by default:
auto_confirm_order(confirm imported sales orders),auto_create_invoice(create the customer invoice),auto_validate_invoice(post it). Turn them on one at a time, only when you are ready for the module to act without a human in the loop. - Mapping defaults — default warehouse, pricelist, salesperson, and the journal used for payout postings. Point these at the Odoo records you want imported data to land on before the first import.
- Risk thresholds — critical, high and medium score cut-offs used by the risk-detection scheduled action to flag suspicious orders.
The module's outbound API traffic goes to api.blibli.com (the seller API MTA proxy — every sync call). Customer address enrichment additionally makes a best-effort lookup at api.zippopotam.us to derive a state from a country + postcode when Blibli did not send one. Your firewall must allow outbound HTTPS to both hosts.
Scheduled actions
The module installs 9 scheduled actions (Settings → Technical → Scheduled Actions), all enabled on install:
| Scheduled action | Runs every |
|---|---|
| Blibli: Sync Customers | 60 minutes |
| Blibli: Process Queue Jobs | 5 minutes |
| Blibli: Import Payout Reports | 6 hours |
| Blibli: Auto Risk Detection | 30 minutes |
| Blibli: Generate Analytics | 4 hours |
| Blibli: Webhook Health Check | 60 minutes |
| Blibli: Cleanup Old Logs | 24 hours |
| Blibli: Process Workflows | 10 minutes |
| Blibli: Daily Summary Report | 1 day |
The heart of the engine is Process Queue Jobs: imports, exports and webhook payloads are queued as jobs and drained by this action, so a burst of platform traffic is worked through at a controlled pace. Product, order and stock transfers are triggered through the operations wizard (below) or incoming webhooks rather than by their own crons — you decide when the bulk work runs.
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.
Webhooks
The module exposes four externally reachable webhook endpoints so Blibli can push events to your Odoo instead of waiting for the next scheduled pull:
| Endpoint | Queues an import of |
|---|---|
POST /blibli/webhook/product | a product |
POST /blibli/webhook/order | an order |
POST /blibli/webhook/customer | a customer |
POST /blibli/webhook/refund | a refund |
Register these URLs in your Blibli seller portal webhook configuration, pointing at your Odoo base URL (for example https://erp.example.com/blibli/webhook/order). Every endpoint expects POST with a JSON body and answers with a small JSON status object ({"status": "ok"}, or {"status": "error", "message": ...} when the request is rejected).
Each request is authenticated with two headers:
X-Blibli-Shop-Domain— identifies which configured instance the event belongs to (matched against your instance records);X-Blibli-Hmac-SHA256— the request signature: Base64 of HMAC-SHA256 computed over the raw request body with the instance's API Secret as the key.
A request with a missing header, an unknown instance, or a signature that does not match the body is rejected before anything is queued — a misconfigured secret on the Blibli side shows up in Odoo as rejected webhook calls, not as corrupted data. Accepted payloads are queued as import jobs (visible under Blibli → Operations → Queue Jobs) and processed by the Process Queue Jobs scheduled action, with every received event written to the log.
Outbound webhook behaviour (events Odoo sends or forwards) is configured per instance under Blibli → Configuration → Webhooks: each record defines the trigger action, payload format, retry count, timeout and batch size, plus its own HMAC secret for signature verification and optional custom headers.
Using the module
The module's menu is laid out as:
- Blibli → Dashboard
- Blibli → Orders
- Blibli → Refunds
- Blibli → Products
- Blibli → Customers
- Blibli → Payouts — visible to users in the Blibli Finance access group
- Blibli → Analytics — visible to users in the Blibli Analytics access group
- Blibli → Operations — Run Operations, Queue Jobs, Logs
- Blibli → Configuration — Instances, Locations, Payment Gateways, Scheduled Actions, Webhooks
Access is controlled by the module's own user groups (Blibli User, Manager, Administrator, Finance, Analytics, Operations, Developer) under Settings → Users, so you can give warehouse staff read access to orders without exposing payout or configuration screens.
A normal first run is:
- Save the connection record and click Test Connection — confirm the status shows Connected before importing anything.
- Set the mapping defaults (warehouse, pricelist, journal) so imported data lands on the right Odoo records.
- Run a small import first — Blibli → Operations → Run Operations, restrict it by date or by a handful of record IDs — 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.
Run Operations (the operations wizard)
Blibli → Operations → Run Operations is the manual control room. Pick the instance and one of thirteen operations:
- Imports — products, orders, unshipped orders, customers, stock levels, locations, payment gateways
- Exports — products, customers, stock levels, and Update Order Status / Export Fulfillment (pushes fulfilment and tracking back to Blibli)
- Finance — import a payout report, import refunds
Each run can be narrowed with a date range (for order, payout and refund imports), a Specific IDs list (comma-separated Blibli IDs for a targeted import), Skip Existing Records (import only what is not already in Odoo), and Import Product Images.
Re-running an operation is safe: existing records matched on their Blibli identifier are updated, not duplicated. If a first attempt half-finished, check the existing records before re-running rather than importing on top.
One bad record in a batch no longer ruins the run: each record is processed in its own protected transaction, so a single malformed product or order is skipped and logged while the rest of the batch completes. Check Blibli → Operations → Logs for the per-record failure detail instead of re-running the whole import blind.
Troubleshooting
| Symptom | Cause and fix |
|---|---|
| The connection will not validate | Re-check the fields 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. |
Webhooks always answer Instance not found | The X-Blibli-Shop-Domain header sent by the platform does not match any configured instance record. Align the value in the seller portal with the instance name in Odoo. |
Webhooks always answer Invalid signature | The signature was computed with a different secret than the instance's API Secret field. Re-copy the secret into both the seller portal and the Odoo instance. |
| 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. Individual bad records are skipped and logged, not silently lost. |
| Records import but map to the wrong Odoo values | Fix the mapping defaults on the instance (warehouse, pricelist, journal), then re-run the import. |
| Customers import without a state | The state-from-postcode enrichment is best-effort — if the external lookup or the platform data fails, the state is left empty and the rest of the address still imports. Fill it manually or re-run the customer import. |
The requests library is required | requests is missing from Odoo's Python environment. Install it into the interpreter that runs Odoo. |
Version history
| Odoo version | Version you download today |
|---|---|
| 17.0 | 17.0.1.3.3 |
| 18.0 | 18.0.1.3.3 |
| 19.0 | 19.0.1.3.3 |
ECOSIRE module versions are <odoo major>.<module major>.<minor>.<patch>, so 19.0.1.3.3 is the Odoo 19 build of module version 1.3.3. Your installed version is shown in Apps.
What changed in 1.3.3
- The dashboard's revenue, average order value and sales trend now follow the period you pick. The dashboard resolves the period you select into a read-only window, so that merely opening it never writes to your configuration — and every counter on the screen used that window: order count, customers, products, queue jobs, the status breakdown and the top products. The money figures did not. They read the saved date range instead, which stays on its own default, so a seller with orders in the period saw Rp 0.00 total revenue, Rp 0.00 average order value and a flat sales trend next to an order count of 18. Revenue, average order value and the trend chart are now scoped to the same period as everything else, and show zero — rather than the previous period's numbers — when the period really is empty.
- The listing now shows the module's real screens. Six screenshots captured from the shipped build — the dashboard, the order list, one order in full, the catalogue, payouts and the scheduled jobs — replace the placeholder store page.
What changed in 1.3.2
- Hardened against 36 known real-world failure cases. Every one of them is a defect a Blibli seller hit in production, and each now has a test that drives the connector and checks the result, on Odoo 17, 18 and 19.
- A foreign-currency order is no longer booked at 1:1. An order quoted in a currency other than your company's was written into your books at the platform number while the currency itself was only recorded on the mapping, and Odoo converts a currency it has no rate for at parity. The import now refuses the order and names the missing rate, and books the order in the platform currency so Odoo converts it properly. If your Blibli account trades in IDR, activate IDR under Accounting → Configuration → Currencies and keep a rate for it.
- Sync logs no longer keep credentials or buyer details. An error message returned by the platform can quote the request it failed on, so log records are scrubbed of credential material and buyer email addresses before they are stored.
- Analytics include the last day of the period, and convert before they add. The period filter compared a date against a timestamp, so everything sold on the closing day counted as zero; totals also mixed platform-currency amounts into a company-currency figure.
- An import no longer reports a record it rolled back as created. A record that failed after its product was created — on the variant uniqueness guard, for example — was counted as created even though the database never received it.
- Blibli's identifiers and settlement status are visible on the sales order and the delivery. The connector's fields on those shared screens rendered nowhere, so an operator could not see which Blibli order a sale order came from or which airway bill fulfilled it. Open a sales order that came from Blibli and look for the Blibli tab.
- A product image reference that is not an absolute web address is refused rather than fetched from a guessed host.
What changed in 1.3.1
- Connecting your Blibli seller account now sends the credentials this configuration screen collects. The previous build authenticated every request with a header Blibli does not use, so the API Seller Key, Signature Key, MTA Username, Channel ID and Store ID you enter were stored and then never sent. Every request now carries all of them — the Basic credentials, the seller key header, the optional signature pair, and the store, channel and username parameters — in the form Blibli's own integration library uses.
- Fulfilling a package from the order form reaches the address Blibli serves. The Fulfil Package at Blibli button on an order built a URL with a duplicated path segment and would have answered "not found" against the live platform. It now posts to the package-fulfilment operation on the seller namespace.
- Deleting a webhook from Odoo works again. Removing a webhook reads its delivery history at Blibli to resolve the remote identifier, and that read was missing from the client, so the Delete Webhook button raised an error instead of removing anything.
- The module installs on Odoo 19, and its test suite is green on all three series. A response helper that the product import and the order import both use had been removed from the client while its callers stayed behind, so installation stopped with an import error and none of the module ran. The suite that guards the connector's capability surface now passes on 17.0, 18.0 and 19.0, including the check that every method the module calls exists.
What changed in 1.1.0
- Standalone install. The separate licence-client dependency, the activation key flow and every licence check were removed. The connector now installs and runs with only standard Odoo apps — nothing to activate, nothing that can lock you out later.
- Fault-tolerant imports. Every per-record sync and import loop now runs in its own protected transaction. A single malformed record from Blibli is skipped and logged instead of aborting the whole run — and a mid-run database error can no longer make the closing step silently roll back every good record that came before it.
- Unchanged behaviour elsewhere. Customer address enrichment (text cleaning, country and state resolution, state-from-postcode) works exactly as before; the helpers it relies on are now carried by the module itself.