Bukalapak Store Management
This is the installation and configuration guide for Bukalapak Store Management, the module you downloaded from your ECOSIRE dashboard. Everything on this page describes the bukalapak_store_management module exactly as it ships today — the facts below were read out of the released build, not from a roadmap.
| Technical name | bukalapak_store_management |
| Odoo versions | 17.0, 18.0, 19.0 (Community or Enterprise) |
| Current shipped version | 17.0 → 17.0.1.1.0, 18.0 → 18.0.1.1.0, 19.0 → 19.0.1.1.0 |
| Price | 19.0 → $499 USD · 17.0 / 18.0 → $249 USD — one-time, per Odoo version |
| Odoo module licence | OPL-1 |
| Category | Connector |
This module ships licence-free: it installs and runs standalone, with no separate licence module to install and no activation key to paste. Your right to use it is the OPL-1 licence you purchased — a contract, not a configuration step. There is no Settings → ECOSIRE.COM menu and nothing checks a key at runtime.
The 17.0, 18.0 and 19.0 builds are separate purchases, and your dashboard offers the download matching the version you bought. Buy the version you actually run — and if you later upgrade Odoo, you need the build for the new version.
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 Bukalapak seller account with API access — an app registered in the Bukalapak Developer Console, giving you a Client ID and Client Secret |
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. You will only be offered the file matching the version you bought — that is expected, see the warning above.
2. Extract into your addons path
unzip bukalapak_store_management_v19_*.zip -d /opt/odoo/addons/
ls /opt/odoo/addons/bukalapak_store_management/__manifest__.py # sanity check
The module must end up as a single top-level bukalapak_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 Bukalapak Store Management and click Install.
- Odoo pulls in the Odoo apps listed above automatically. There is nothing else to install and no activation step — the app is ready to configure as soon as the install finishes.
When the install finishes, a Bukalapak menu appears in the main Odoo app switcher.
What changed in the current build
If you last looked at this module a while ago, two shipped changes matter to you as a user:
Sync runs are fault-isolated (since 1.0.10)
Every record the module handles during a sync — products, orders, customers, inventory, webhook-triggered imports — is processed inside its own transaction boundary. If Bukalapak sends one malformed or rejected record, only that record fails: it is written to Operations → Logs with the platform's own error text, and every other record in the run still imports and stays imported.
Before this change, a single bad record could abort the whole run — worse, it could silently roll back records that had already imported while the run's log still claimed success. If you used to re-run an import "to be safe" after a partial failure, that workaround is no longer needed: check Operations → Logs for the per-record verdict instead of re-importing on top.
No licence client, no activation (since 1.1.0)
The module no longer declares the separate ECOSIRE licence-client module as a dependency, and there is no licence check anywhere in it. Concretely:
- Fresh installs need one ZIP — the connector's. Nothing else to download, no key to activate, no Settings → ECOSIRE.COM screen.
- If you are upgrading an older build that shipped with the licence client: the connector simply stops using it. You do not need to uninstall the licence client if other ECOSIRE modules on the same database still use it — this module just no longer touches it.
Configuration
Connect to Bukalapak
Open Bukalapak → Configuration → Instances and create a connection record. The fields the module defines for the connection are:
| Field | Technical name | Type | Required |
|---|---|---|---|
| Instance Name | name | Char | Yes |
| Client ID | client_id | Char | Yes |
| Client Secret | client_secret | Char (masked) | Yes |
| Company | company_id | Many2one | Yes |
| Access Token | access_token | Char (masked) | No — filled in automatically when you connect, never typed by hand |
| Status | state | Draft / Connected / Error | No — maintained by the module |
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.
Press Connect in the header of the record. The module exchanges your app credentials directly with Bukalapak (the OAuth2 client-credentials grant against api.bukalapak.com/oauth/token, requesting the public, user, store, inventory, order and wallet scopes), stores the access token, and flips the record to Connected — no browser redirect is involved. The button hides itself once you are connected. Test Connection independently verifies the credentials; a failure marks the record Error and shows the reason in a notification that stays on screen until you dismiss it.
The same record carries three automation switches, all defaulting to off — auto_confirm_order, auto_create_invoice, auto_validate_invoice. They gate what the module is allowed to do automatically once connected: confirm imported orders, then create their invoice, then post it. Leave anything you are not ready for switched off, and turn them on one at a time.
Optional defaults on the same record, used when the corresponding feature runs: a default warehouse for order imports, a pricelist and salesperson for imported orders, a bank journal for payout statements, the products used to represent Bukalapak discounts and shipping charges on order lines, the risk-score thresholds behind the risk-detection scheduled action, and monthly marketing/operating cost figures that feed the net-profit figures in Analytics.
The module's own source contacts one host only: api.bukalapak.com. Your firewall must allow outbound HTTPS to it.
Public endpoints this module exposes
The connector serves five externally reachable endpoints. The paths are relative to your Odoo base URL (web.base.url).
| Endpoint | Method | Auth | Purpose |
|---|---|---|---|
/bukalapak/callback | GET | Public (unauthenticated) | OAuth redirect target, for partner apps issued an authorization-code client by Bukalapak. |
/bukalapak/webhook/product | POST | Public (signature-verified) | Inbound webhook receiver for product events. |
/bukalapak/webhook/order | POST | Public (signature-verified) | Inbound webhook receiver for order events. |
/bukalapak/webhook/customer | POST | Public (signature-verified) | Inbound webhook receiver for customer events. |
/bukalapak/webhook/refund | POST | Public (signature-verified) | Inbound webhook receiver for refund events. |
The callback. The normal way to connect is the Connect button above — it needs no redirect URI. The callback endpoint exists for the case where Bukalapak issued your app an authorization-code client instead: register https://erp.example.com/bukalapak/callback as the redirect URI in your Bukalapak app, and make sure web.base.url is already set to that real HTTPS address, because the module builds the redirect URI from it during the token exchange. The endpoint is public because the browser arrives on it without an Odoo session, not because it is unguarded: it refuses a request with no authorization code, and matches the single-use state nonce issued when the flow started against the connection record before exchanging anything. On success it stores the token, marks the record Connected, and lands you back on the instance form.
The webhook receivers. Each receiver expects two headers on the request: X-Bukalapak-Shop-Domain, which tells the module which connection record the event belongs to, and X-Bukalapak-Hmac-SHA256, the signature of the raw request body. A request that passes verification is answered with {"status": "ok"} and gets a pending queue job in Operations → Queue Jobs — the Process Queue Jobs scheduled action then imports it like any other job. A request that cannot be resolved or verified is refused with {"status": "error", ...} and the attempt is written to Operations → Logs.
Bukalapak has no API for registering webhook subscriptions automatically, so the Configuration → Webhooks screen in Odoo is a local registry: Create Webhook records the event type and delivery URL (your Odoo's receiver path from the table above) in Odoo, and you enter that same delivery URL manually in the Bukalapak seller/developer portal. The Test button sends a signed sample payload to the recorded URL so you can confirm the endpoint answers before you rely on it.
Scheduled actions
The module installs 13 scheduled actions (Settings → Technical → Scheduled Actions):
| Scheduled action | Runs every |
|---|---|
| Bukalapak: Sync Products | 30 minutes |
| Bukalapak: Sync Orders | 15 minutes |
| Bukalapak: Sync Customers | 60 minutes |
| Bukalapak: Sync Inventory | 10 minutes |
| Bukalapak: Process Queue Jobs | 5 minutes |
| Bukalapak: Import Payout Reports | 6 hours |
| Bukalapak: Import Refunds | 30 minutes |
| Bukalapak: Auto Risk Detection | 30 minutes |
| Bukalapak: Generate Analytics | 4 hours |
| Bukalapak: Webhook Health Check | 60 minutes |
| Bukalapak: Cleanup Old Logs | 24 hours |
| Bukalapak: Process Workflows | 10 minutes |
| Bukalapak: Daily Summary Report | 1 day |
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:
- Bukalapak → Dashboard
- Bukalapak → Orders
- Bukalapak → Refunds
- Bukalapak → Products
- Bukalapak → Customers
- Bukalapak → Payouts
- Bukalapak → Analytics
- Bukalapak → Operations — Run Operations, Queue Jobs, Logs
- Bukalapak → Configuration — Instances, Locations, Payment Gateways, Scheduled Actions, Webhooks
A normal first run is:
- Save the connection record, press Connect, and confirm the record shows Connected before importing anything.
- Review the mapping and default records (warehouse, pricelist, journal) 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, and since the fault-isolation change each failure names exactly the one record it concerns.
Troubleshooting
| 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. Since the fault-isolation change, a stopped run means an infrastructure problem, not one bad record. |
| 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. |
| A webhook arrives but nothing imports, or the caller reports an error | The request must carry both X-Bukalapak-Shop-Domain and a valid X-Bukalapak-Hmac-SHA256 signature over the raw body. A refused attempt is written to Operations → Logs with the reason. |
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.1.0 |
| 18.0 | 18.0.1.1.0 |
| 19.0 | 19.0.1.1.0 |
ECOSIRE module versions are <odoo major>.<module major>.<minor>.<patch>, so 19.0.1.1.0 is the Odoo 19 build of module version 1.1.0. Your installed version is shown in Apps.