Custom Shopify Shipping & Logistics Integration: What It Takes to Connect a Thai Carrier

Most Shopify stores solve shipping the same way: install the carrier's app, connect the account, and move on. That works until the carrier you need has no app, or has one that handles labels but not the thing your customers actually see — the shipping price at checkout. A regional courier with zone-based island surcharges, a 3PL with its own warehouse system, a cold-chain fleet that quotes by temperature band: none of these fit a generic plugin, and at that point shipping stops being a setting and becomes an integration project.

This article explains what that project is made of, using Shopify's own documented mechanisms, so you can judge what you need before you ask anyone for a quote.

Shipping integration is three jobs, not one

"Connect our carrier" hides three separate pieces of work. Many stores need only one or two, and knowing which saves real money.

1. Rates at checkout. What the customer is charged for shipping, ideally calculated live from the cart and destination.
2. Fulfillment hand-off. Sending the paid order to the carrier or warehouse so a parcel is actually created.
3. Tracking and status sync. Pushing tracking numbers and delivery updates back to Shopify so customers and your support team see them.

A store shipping flat-rate from its own stockroom through a courier's web portal might need none of this. A store with its own warehouse system usually needs the second and third. A store with complicated price tables needs the first. Scope each one separately.

Job one: live rates with Shopify's carrier service

The mechanism behind live checkout rates is Shopify's CarrierService resource. You register a carrier service against the store with a callback_url, a public endpoint you control. When a customer reaches checkout, Shopify sends your endpoint a POST request describing the shipment, and your endpoint answers with the rates to show.

What Shopify sends is substantial: the origin and destination addresses, and for each item its name, SKU, quantity, weight in grams, price and product and variant IDs, plus the currency and locale. That is enough to price by weight, by destination zone, by item type or by any rule you can compute from those fields.

What you send back is a list of rates, each with a service_name and description that the customer reads at checkout, a service_code that stays consistent across requests, a currency and a total_price in subunits.

Three details of this design shape how a custom integration has to be built:

• It is real-time and has a clock on it. Shopify's documentation sets the response limit at 10 seconds under 1,500 requests per minute, 5 seconds between 1,500 and 3,000, and 3 seconds above that, and says these are upper limits, not targets. A rate service that calls a slow carrier API on every request will be fragile.
• There is no retry. The documentation states that timeouts or errors trigger the store's backup rates and that the response must succeed on the first try. Whatever your endpoint does when the carrier's API is down is a business decision to make deliberately: fall back to a table of last-known rates, or let Shopify's backup rates apply.
• You can decline. Returning an empty array means "no rates from me for this cart," which is how you handle destinations or items your carrier does not serve.

In practice a well-built rate endpoint answers from a local rate table or a cache wherever it can, and only calls the carrier's API for the cases that truly need it.

A plan requirement worth checking early

Third-party carrier-calculated shipping is not available on every Shopify plan. According to Shopify, it is included on Advanced and Plus, and on lower plans it needs annual billing or a monthly add-on fee. Check this before design starts. It is a cost line the business case should include, and discovering it at launch is avoidable.

Job two: fulfillment hand-off

When an order is placed, Shopify creates fulfillment orders — each one representing what must be fulfilled from a single location. If an order's items sit in two locations, it has two fulfillment orders.

For a custom logistics partner there are two common shapes:

• A fulfillment service. You register the partner as a fulfillment service. Shopify creates a location for it, and orders assigned to that location become fulfillment requests your integration can read and act on. This fits a 3PL that holds your stock.
• A pull-based integration. Your own system, or a small service, reads new paid orders through the API or webhooks and creates shipments with the carrier. This fits a store that keeps stock itself but books parcels through a courier's API.

Shopify supports webhooks for fulfillment orders and the events around them, so an integration can react when something happens rather than polling the store on a timer. Polling still has a place as a safety net, to catch any event that was missed.

Whichever shape you choose, design for the awkward cases first: a partially shipped order, an address the carrier rejects, a cancelled order that was already sent to the warehouse. Happy-path orders almost never break an integration. The edge cases do.

Job three: tracking and status

Once a parcel exists, the carrier produces a tracking number, and the store needs it. The integration creates a fulfillment in Shopify with the tracking details attached, which is what triggers the customer's shipping confirmation. Fulfillment services can also expose a callback so Shopify can retrieve tracking numbers itself, when tracking support is enabled.

Delivery status is a separate question. Shopify records that an order was fulfilled and carries tracking details, but "out for delivery" and "delivered" usually come from the carrier. Stores that want those states in the customer account or in LINE notifications need a webhook or polling job from the carrier's side feeding a notification step. If your customers ask where their parcel is more than your team can answer, this third job is where the money is saved.

Thai-specific problems to price in

Generic integrations rarely account for the things that make shipping in Thailand different:

• Cash on delivery. If you offer COD, the fee, the collection and the remittance cycle are part of the integration, not a footnote. The order's payment status in Shopify needs a defined way to reflect the courier's cash collection.
• Zone and island pricing. Remote provinces and islands often carry surcharges. This is the classic reason a flat table fails and a rate endpoint is needed.
• Thai addresses. Province, district and sub-district fields need to match what the carrier validates against. A checkout that accepts free text will produce rejected parcels.
• Multiple carriers. Many stores offer a cheaper slow option and a faster premium one, sometimes from different couriers. The rate endpoint can return several options from several sources in one response.
• Carrier API access. Not every courier exposes an open API, and some gate it behind a commercial account or minimum volume. Confirm access, test credentials and documentation quality before you commit to a scope. This one question can change an estimate more than any other.

Build, buy, or configure?

The cheapest answer is the one that already exists, so work down this list in order:

1. Is there a Shopify App Store app for this carrier that does what you need? If it handles rates, labels and tracking well enough, use it.
2. Does a multi-carrier shipping app already cover it? Aggregator apps connect several couriers at once and may be enough for stores with a handful of options.
3. Can the problem be solved by shipping rules in Shopify itself? Zone-based flat rates and weight tiers can be set up in the admin with no code.
4. Only then: a custom integration. It makes sense when the carrier has no app, when pricing logic is too intricate for rules, when the store must talk to a warehouse or ERP system, or when you are shipping enough parcels that manual handling costs more than a build.

A custom integration is also a thing you own: it needs hosting, monitoring and maintenance when the carrier changes its API. Budget for that, not just for the build.

What a sensible project looks like

A well-run custom shipping integration usually moves through the same stages:

• Discovery. Which of the three jobs are in scope, the carrier's API documentation and sandbox, the store's plan, volumes and edge cases.
• Rate logic first. Because it is what customers see and what moves conversion, build and test the checkout rate endpoint against real baskets and real destinations before anything else.
• Fulfillment and tracking next. Wire the hand-off and the tracking write-back, with logging on every step so a failed parcel can be traced.
• Failure handling. Decide, and test, what happens when the carrier's API is slow or down.
• Staged launch. Run on a subset of orders or a test location before switching everything over, and keep a manual fallback for the first weeks.

Questions to answer before you ask for a quote

You will get a faster and more accurate estimate if you can say:

• Which carriers or logistics partners, and whether you hold accounts and API credentials already.
• Which of rates, fulfillment hand-off and tracking you need.
• Whether you sell COD, and how you reconcile it.
• Your Shopify plan, and your daily order volume now and at peak.
• Whether a warehouse management or ERP system sits behind the store.

If the answers are "one courier with an app, flat rates, no COD," you likely do not need a custom build. If they are "a courier with no app, island pricing, a warehouse system and COD," you do, and knowing that up front is how the project stays on budget.