Shiprocket Aggregator Connector for Odoo

This is a build-to-order module, so it is not an instant download. After a short scoping call we build, test across your Odoo version, and install it — typically 2 to 4 weeks. Timing depends mainly on how much COD reconciliation logic and custom courier-selection rules you need. You get a firm timeline before we start, plus staging-first deployment so nothing hits production untested.

Every build ships with a defined support window (30 days by default, extendable) covering bug fixes within the delivered scope. Because you receive the full source, you own the module and can extend it yourself. We also offer optional annual maintenance to keep it aligned with Shiprocket API changes and to migrate it forward when you upgrade Odoo (e.g. 18 to 19).

Both. The connector is built on standard Odoo framework components — models, fields, views, `ir.model.access.csv`, record rules, `ir.cron` and QWeb reports — that exist in Community and Enterprise alike. We build and test it against your exact edition and version (17, 18 or 19) so it installs cleanly with no Enterprise-only dependency unless you specifically want one.

Yes. You bring a Shiprocket account with your couriers activated and your pickup locations registered; we handle all the Odoo-side engineering. During setup we wire your API credentials into the secure `shiprocket.config` model, which issues and auto-refreshes the auth token via a scheduled cron so your team never re-authenticates manually.

When an order is COD, the collectable amount flows from the `sale.order` through to the Shiprocket order at AWB creation. As Shiprocket remits collected cash, the connector surfaces a reconciliation view that matches each remittance back to its originating order and delivery, so finance can confirm what has been collected and what is still pending without a manual spreadsheet.

Yes. On a confirmed delivery order it calls Shiprocket for live rates from every serviceable courier and applies your chosen rule — cheapest, fastest, or best-rated — via a computed field (@api.depends). The recommendation is pre-selected but always overridable, so your team keeps final say while the default does the thinking.