Odoo integration
Connect Shiprocket Shipping and Fulfilment to Odoo
Shipping goes wrong in two places: the rate you quote at checkout, and the status nobody updated afterwards. Both are integration problems, and they have different answers.
- Rates at checkout
- Shipment hand-off
- Status sync
- Tracking
- Reconciliation
Reviewed by Bhavesh Selarka, COO & Co-Founder, Heliconia Solutions · Odoo 16 Functional Certification · Odoo Partner · Updated
Proof
Clients
Businesses that run on what we built
The short answer
What Does a Shiprocket and Odoo Integration Cover?
Odoo owns the order, the customer, the stock and the delivery record. Shiprocket owns the courier, the label and the parcel status. The integration quotes a rate before the order is placed, hands the shipment over once it is paid, and brings the status back so the Odoo delivery and the customer both know where the parcel is.
Most businesses start by doing this by hand: a CSV upload each morning, then a tab open all afternoon to answer where's my order. It works until volume makes it the most expensive hour of the day.
LittleQ run it as part of a connected flow. Their Next.js storefront talks to Odoo over GraphQL, Cashfree takes the payment, and Shiprocket calculates shipping and handles fulfilment, with Odoo keeping catalog, stock, orders and customers.
The decision that shapes the project is whether Odoo stays the system of record for the delivery. We think it should, because that is where the stock move, the invoice and the customer conversation already are.
Being precise
What We Have Delivered, and What We Would Scope
Shipping platforms expose a wide API surface. This table separates what our production project actually covers from what we would estimate as new work, because the difference matters when you are choosing a partner.
| Operation | Status | Notes |
|---|---|---|
| Serviceability and rate calculation | Delivered in production | LittleQ quote shipping at checkout from the courier platform rather than from a flat table |
| Fulfilment hand-off from the Odoo order | Delivered in production | Paid orders flow into fulfilment as part of the connected order workflow |
| Shipment creation and courier assignment | Scoped work | Ordinary API work. We would estimate it against your order model rather than claim it as proven here |
| Label and manifest generation | Scoped work | Straightforward, but the file handling and reprint rules need defining with your warehouse |
| Tracking and status updates back into Odoo | Scoped work | Webhook or polling, with the delivery record and customer notification updated from one source |
| Return and NDR handling | Scoped work | The rules are the hard part: who decides, what the stock move is, how the refund is triggered |
| Cash on delivery remittance reconciliation | Scoped work | Needs agreement with finance before code, like any settlement flow |
We would rather publish a shorter list we can stand behind. If an operation above matters to you, ask us in the assessment and you will get an estimate, not a claim.
The first decision
Which System Owns What
Shipping integrations fail when two systems both believe they own the delivery. Settle these rows first.
| Object | System of record | Direction | Conflict rule |
|---|---|---|---|
| Order and customer | Odoo | Odoo to the platform | The courier platform is not a customer database |
| Stock and delivery record | Odoo | Odoo only | The stock move happens in Odoo. A shipment elsewhere does not move stock |
| Shipping rate quoted | Courier platform | Platform to Odoo or storefront | Quoted live at checkout, and stored on the order so the quote is auditable |
| Shipment and AWB | Courier platform | Platform to Odoo | Created once, stored on the Odoo delivery so support never has to open two systems |
| Parcel status | Courier platform | Platform to Odoo | The platform is the truth. Odoo mirrors it rather than inventing it |
| Customer notification | Whoever you choose, but only one | Either | Pick one sender. Two systems emailing the same shopper is worse than neither |
| Shipping charges and remittance | Platform, reconciled | Platform to Odoo | Ends as a cost line in the ledger, matched rather than assumed |
The lifecycle
From Rate Quote to Delivered
Where each step lives, and what has to be true for the next one to happen.
Step 01
Serviceability and rate
Before the shopper commits, the destination pin code is checked and a rate is quoted. LittleQ do this live rather than from a static table, so the quote reflects the couriers that will actually deliver.
- Checkout
Step 02
Order placed and paid
The order and payment belong to Odoo and the gateway. Nothing is handed to fulfilment until the order is genuinely paid and confirmed.
- Odoo
Step 03
Delivery prepared
Odoo creates the delivery with the picking, the weights and the dimensions. Bad weight data is the most common cause of a surprise shipping bill.
- Odoo
Step 04
Shipment created
The shipment is created on the courier platform and the AWB comes back onto the Odoo delivery, so support has one screen rather than two.
- Platform
Step 05
Label and pickup
Label and manifest are generated for the warehouse, with clear rules about reprints and cancellations before the parcel leaves.
- Warehouse
Step 06
Status back
Picked up, in transit, out for delivery, delivered. The Odoo delivery mirrors it so the order page and your team see the same thing the courier sees.
- Webhook
Step 07
Exceptions
Failed delivery, return to origin and cancellations are the cases that decide whether the integration was worth building. They need defined rules, not ad-hoc handling.
- Rules
Step 08
Reconciliation
Shipping charges, weight disputes and any cash-on-delivery remittance are matched against the Odoo orders they belong to.
- Accounting
Which pattern
Manual, Connector or Custom Integration?
Be honest about volume. Below a certain number of parcels a day, a person with a CSV is cheaper than any integration.
| Your situation | Approach | Why |
|---|---|---|
| A handful of orders a day | Manual upload | The integration will not pay for itself yet, and we will tell you so |
| Standard Odoo eCommerce, standard flow | An existing connector, evaluated | Check maintenance, version support and what it does on failure before installing it |
| Custom storefront or app | Custom integration | What LittleQ needed: rates quoted at a checkout that is not the Odoo website |
| Rates must reflect real couriers at checkout | Custom, with caching | A live rate call in the critical path needs a timeout and a fallback, or checkout stalls |
| Multiple couriers or warehouses | Custom, with routing rules | The routing logic is yours and belongs in Odoo where you can change it |
| Heavy returns or cash on delivery | Custom, with finance in the room | The money flow matters more than the parcel flow here |
Failure handling
What Makes It Survive a Bad Day
- A timeout and a fallback on the live rate call, so a slow courier API slows nobody’s checkout to a stop
- Rate responses cached by pin code and weight band, which cuts both latency and API calls
- Idempotent shipment creation keyed on the Odoo delivery, so a retry can’t produce two AWBs for one parcel
- A queue with retry and backoff for every outbound call, because courier APIs have bad hours like everyone else
- Status updates reconciled by a scheduled poll as well as webhooks, since a missed status is invisible until a customer asks
- Quoted rate stored on the order, so a later dispute about weight or charge has evidence attached
- Alerting on shipments that stay in one state too long, which is how you find the parcels nobody picked up
- Daily reconciliation of shipping charges against orders, so a weight discrepancy is caught in days rather than at month end
Security boundary
Credentials, Data and What We Do Not Touch
- 01
Platform credentials live in the server environment, never in the storefront, the database or a repository.
- 02
Customer addresses and phone numbers go to the courier platform because delivery requires it, and nowhere else. The data sent is the minimum the shipment needs.
- 03
Tokens are refreshed server-side and scoped to the account you own. The platform account stays yours.
- 04
Every outbound call and inbound status is logged with its identifier, so a disputed delivery can be traced.
- 05
Retention: shipment and tracking history stays in Odoo alongside the order, under your retention policy rather than ours.
- 06
We are not the carrier and we do not take responsibility for delivery performance, courier pricing or platform terms. We build the integration and make its failures visible.
How we run it
Implementation Sequence
Assessment
Odoo version and edition, order volumes, where checkout lives, courier mix, return rate, cash on delivery, and what your team does manually today.
Ownership and operations
The matrix above completed and the exact API operations agreed, so the scope is a list rather than the word integration.
Rates first
Serviceability and rate quoting usually pays back first, and it is the part customers see at the moment they decide to buy.
Hand-off and status
Shipment creation, labels and status back into the Odoo delivery, with the exception rules written down before they are coded.
Controlled go-live
A small volume first, with the manual process still available, until the parcel states line up for a full week.
Then reconciliation
Shipping charges and any remittance matched in Odoo, which is what turns a working integration into a controlled cost.
Evidence
Shiprocket and Odoo in Production
A direct-to-consumer brand where shipping is quoted at checkout and fulfilment runs inside a headless Odoo order flow.
| Project | Industry | Odoo | Key capabilities | Technology |
|---|---|---|---|---|
| LittleQ | eCommerce, baby care | Odoo | Headless Odoo API · Product Catalog Management · Product Discount Engine · Distributor Registration Portal | Odoo · Next.js · PayloadCMS · React · Node.js |
Integration assessment
Request an Integration Assessment
Send your Odoo version and edition, daily order volume, courier mix, where checkout lives, your return rate and what your team does by hand today. You get the ownership matrix, the list of operations worth automating first, and an estimate for the ones outside our production evidence.
- Data ownership matrix completed for your setup
- The exact API operations in scope, named individually
- Rate-at-checkout design, with timeout, caching and fallback
- Exception rules for failed delivery, returns and cancellations
- Shipping cost reconciliation into the Odoo ledger
What clients say
In Their Words
Heliconia transformed our business with Odoo. They implemented a dynamic website with e-commerce capabilities, enhancing our online presence significantly.
Sandesh ThummarBusiness Owner, Ladder LogixHeliconia provided a unique canteen solution, saving us valuable ordering time. Their innovative approach has been invaluable to our operations.
Pradeep LakhaniBusiness Owner, Avasar Agency
Questions
Shiprocket and Odoo Questions, Answered Directly
What have you actually built with Shiprocket and Odoo?
Shipping rate calculation and the fulfilment hand-off inside a live headless Odoo commerce flow, for LittleQ. Everything else on this page is described as scoped work rather than delivered evidence, which is a distinction most agency pages skip.
Should Odoo or the courier platform be the system of record?
Odoo, for the order, the customer, the stock and the delivery. The courier platform is the record for the parcel: the AWB, the courier and the status. Mirror the parcel state into Odoo so nobody has to open two systems to answer one question.
Can we show live shipping rates at checkout?
Yes, and LittleQ do. The thing to design carefully is what happens when the rate call is slow: a timeout, a cached band and a sensible fallback rate, so checkout never stalls while a courier API thinks about it.
Do we need an integration at all?
Below roughly a few dozen parcels a day, probably not. A daily CSV and a person is cheaper than the build and the maintenance, and we'd rather say that than sell you a project that doesn't pay back.
How are returns and failed deliveries handled?
By rules you write down first. Who decides a return is accepted, what stock move it creates, whether it triggers a refund, and how a return to origin differs from a customer return. The code is the easy part once those answers exist.
Does this cover the payment side too?
No. Payment authorisation and order confirmation have their own page, because a paid order is the precondition for this one. LittleQ take payments through Cashfree.
Next step
Stop Answering Where Is My Order by Hand
Tell us your volume, your courier mix and what your team does manually today. We will tell you which operations are worth automating first, and which are not worth it yet.