Two parts. The first is for anyone running a shop. The second is for whoever writes the code.
Almost every answer depends on how you connect, so each section says which route it applies to. The three routes are the Shopify connector, the WooCommerce connector, and a direct API integration.
Everything below is last-mile unless a question says otherwise. Fulfilment questions are answered in that section: Fulfilment. If you are not sure which one you are on, Which API do I need.
- Create a business account. Individual accounts cannot be connected.
- Speak to your account manager. A commercial agreement comes before credentials.
- Get the account activated: trade licence, bank card, finance details.
- Have the services you need switched on. Same Day, Next Day, 4-hour and international are each enabled separately.
- Connect your shop, or have a developer build against the API.
- Test on staging, then go live.
Not if your shop runs on Shopify or WooCommerce. Install the connector from Quiqdash, then map your delivery methods.
For anything else, yes. The API works from any system that can send an HTTPS request, but someone has to write that code.
Yes, but there is no ready-made plugin. Only Shopify and WooCommerce have one. Everything else needs a developer, or a middleware partner such as Carriyo, ClickPost or Unicommerce.
Yes. A commercial conversation and a signed agreement come before you go live. Start that early rather than at the end, because commercial sign-off is a gate on go-live.
Not necessarily. If you send a handful of orders a day, create them by hand in Quiqdash.
Moving to the API later keeps the same account. You do not start over.
Shopify and WooCommerce.
- A default pickup location. The connector collects from one place and reads it off the account, so without it the connection will not establish.
- Every delivery method mapped to a Quiqup service.
- The services you are mapping to, enabled on the account.
Quiqdash → Integrations → Integration Orders.
It lists every order from your shop, whether it reached Quiqup, and the reason if it did not. It also carries a Repair Orders action. Check this before emailing anyone.
Something broke the connection between the two platforms. Four known causes, all connector-side, and nobody is notified when it happens. What breaks a connection
Check the Integration Orders page, then reconnect.
Check the Integration Orders page with the filter on All: every order the connector saw is there, including the ones it did not send. A delivery method mapped to Do not read orders shows its orders as Failed, by design. A method you never mapped does not hide orders: they are sent as Next Day, so they arrive, possibly on the wrong service. Unmapped delivery methods
Map every shipping method in your shop to a Quiqup service before you go live.
Orders placed before you configured the connector are also never fetched. There is no backfill.
Not through a connector. One connection maps to one pickup location. Multi-warehouse pickup is one of the reasons to build on the API instead, which sends a pickup address per order.
No. The connector does not push rates.
You enter your shipping charges by hand in your own shop's shipping settings, then map each one to a Quiqup service. This applies to domestic, weight-based and international rates alike.
No. Every order carries its own full pickup address, and the API never falls back to an account default. That is what lets an API integration collect from several locations, which a connector cannot.
There is no intermediate page for API orders. If the call returned 2xx, the order exists in Quiqup.
The usual cause is that the order is still pending, which means ready_for_collection was never called. A pending order is invisible to operations and will never be collected.
Nothing exists on the connection to expire, so it is not the same failure as a connector dropping out. Four causes: your key hit the Expiration you chose when you created it, credentials were rotated, an account capability was switched off, or your own deploy changed the payload. Check the expiry first, it is the cheapest to rule out.
No. There is no quote or rate endpoint anywhere in the API.
Not directly. Import the marketplace orders into your Shopify or WooCommerce store, ship them through the connector, then enter the Quiqup tracking number back on the marketplace by hand.
No. Quiqup supports a single merchant shipping from its own locations.
Not supported: C2C, peer-to-peer, and multi-vendor marketplaces. What Quiqup supports is worth reading before you build anything.
No. It is public, no login and no key.
apisupport@quiqup.com. Email only. What to include
For pricing, adding services or activating your account, go to your account manager instead.
What to put in the first email
Coverage differs by service and changes, so ask your account manager for the current list rather than inferring it from the API. An order for an emirate outside coverage is accepted at create and stops later, so the API will not tell you.
Ask your account manager for the table that applies to your services, and check the Cutoff Times page in Quiqdash. Every service has one. An order placed after cut-off is accepted and collected on the next cycle, not rejected, which is why orders sometimes arrive later than expected without any error.
Yes, to GCC destinations. Two things have to happen first: sign the international terms and conditions, and have the export service activated on your account.
Exports use the same POST /orders. Send kind: partner_export, or simply a destination country other than the pickup country: the order becomes an export either way.
Every export order also needs a destination contact_email, an ISO country code such as SA, and a populated products array with the customs fields on every product. What an export needs.
None of that is checked at create. The order is accepted, and the missing fields are refused with a 422 naming them when you mark it ready for collection. The order is still pending then, so cancel it and create it again, ideally before the customer has paid.
Everything below is the direct API. If you use a connector, none of it applies: the connector handles credentials, order creation and webhooks itself.
Two options, and you only need one.
Generate a Bearer token in Quiqdash and send it as Authorization: Bearer <token>. No exchange step, and you can set it to never expire. This is the default.
Or exchange a client_id and client_secret at POST /oauth/token for an access token that lasts seven days, then send that.
Both grant identical access. If you have a Quiqdash token you never call /oauth/token.
No. Those are issued by Quiqup on request and are the one part of access that still needs a human.
You probably do not need them. They do nothing a Bearer token cannot. They exist for middleware and carrier platforms whose setup screens ask for a Client ID and Client Secret and cannot accept a token.
Last mile is https://api.staging.quiqup.com and https://api-ae.quiqup.com. Fulfilment accounts use different hosts, and the dashboard URLs are separate again.
The full table, including which dashboard host is current
If you see stoplight.io/mocks anywhere, that is a mock server returning fake data. Replace the host.
Treat them as not. A Quiqdash key comes from the login service both environments share, so it identifies the same account on either host; generate a production key on the production dashboard and use each key only on the host it was made for. A client id and secret, and the tokens exchanged from them, are per environment: production rejects a staging pair or token with 401, which reads like a bad key rather than a routing mistake. Nothing in a response says which environment answered, so the base URL decides whether an order is real. Which credentials cross environments
Three causes: id and secret swapped, credentials pointed at the wrong environment, or a client_id that has not been activated yet. A client_id ending .apps.quiqup.com is the correct current format.
It is rarely the token. Several capabilities are enabled per account and fail this way when off: payment modes, label generation, ready_for_collection, international export.
Yes, or the order never leaves pending and Quiqup operations never see it.
Three ways to do it: the PUT call, ready_for_collection: true at create time (applied asynchronously, so the create response still says pending), or account-level automatic release (auto-RFC, ready for collection on create).
An integration that stops at create produces "the API returned success but nothing happened".
Yes. There is no account-level default for API orders, and a billing_identifier does not supply one either. Send a full pickup address every time.
On last-mile the field is kind: partner_same_day, partner_next_day, partner_4hr, partner_return, partner_export. partner_store is also accepted and resolves to the same-day class.
On fulfilment the field is service_kind. See Fulfilment orders.
kind decides the service and cannot be changed after creation. A wrong one has to be cancelled and re-booked.
The wire field is state. One table mapping every state to its webhook event.
Handle unknown values gracefully. order.error is subscribable, though no last-mile order enters error today.
You drive two transitions through the API: out of pending with ready_for_collection, and to cancelled while the order is pending or ready_for_collection. Every other state is set by operations and the courier application.
Pending orders are listed, under Pending, so it is not that. In order: is it the right environment, does the dashboard user belong to the same account as the token, and does the date range cover the order. Where your orders appear
If the order is there but never moves, it is still pending: it was never made ready for collection.
The contract declares address1, address2, coords, town and country. address1 is required on both origin and destination. country is a two-letter ISO code, see Country codes. There is no postcode field and no emirate field. The full field table
The request field is coords, and it is [longitude, latitude]. Dubai is [55.16…, 25.05…]: the larger number comes first.
Responses and webhooks use a different shape, coordinates: {lat, lng}. Why
E.164 with a single +, on contact_phone. See Contact fields.
The customer's number is not printed on the label, for privacy.
Two modes. paid_on_delivery needs payment_amount above 1. pre_paid needs no amount on create. Top-level fields
cash_on_delivery and card_on_delivery are retired. They show up in older documentation and in inherited integrations. Do not build against them.
Payment is order-level, not per parcel. COD is not available on international orders.
It identifies a billing account, not a pickup location, and lets one credential set create orders that belong to another account, which Quiqup has linked to yours. If you do not have one, omit the field entirely: a value that is not linked is accepted and ignored, and the order is created in your own account. billing_identifier
Yes, if you send a uuid. Resending the same uuid from the same account returns the original order with HTTP 200 and creates nothing.
Without one, no. partner_order_id does not enforce uniqueness, so a retried create produces a second order and a second AWB (air waybill, the shipping label). And a reference search on its own will not save you: GET /orders leaves out pending orders, which is what a timed-out create leaves behind, unless you also send filters[state]=pending. How to retry safely.
Quiqdash → Integrations → Webhooks → New subscription. HTTPS URL required. The screen also does edit, delete, pause and send-test.
Yes. A staging registration never carries over. Everything passes on staging, then the first real order produces no callbacks at all.
Your secret is on the webhook's configuration page in Quiqdash. The signature is:
HMAC-SHA256(your_secret, "{timestamp}.{raw_body}")Hex-encoded, no prefix, in X-Quiqup-Signature, which every delivery carries. Some older subscriptions also receive a deprecated x-signature: sha1= header; verify X-Quiqup-Signature instead. The headers and the formula.
Yes. GET /orders/{order_id}/history returns every state the order has passed through, with timestamps. Works on staging and production at the matching base URL.
One named event per transition. Three families: order.*, plus inbound.* and inventory.* for fulfilment. order.ready_for_collection does fire, so build for it. The full list, mapped to order states.
Check Quiqdash → Integrations → Webhooks → Delivery logs first. It shows every attempt with its status, HTTP code and error, and you can replay failed ones yourself.
If the log is empty: is a subscription active on this environment, is the URL HTTPS, and did you register before the order was created. Registration is not retroactive.
Webhooks. GET /orders/{order_id} returns the current state only, so a poller misses everything that happens between samples.
To recover missed transitions, use the history endpoint.
Make your receiver idempotent. Events can be redelivered and can arrive out of order, and the payload carries no event id. How to deduplicate
Check the order id. The label endpoint returns 200 and an application/pdf content type even for an order that does not exist, with a zero-byte body. An empty PDF almost always means the id was wrong, not that the label failed. The label call
Same POST /orders endpoint with kind: partner_return. Pickup is the customer's address, dropoff is yours.
An item is a parcel: a box or a bag. A product is a good. They are two separate top-level arrays, not one nested inside the other.
One label is produced per item, so each box can be tracked. Ten garments in one bag is one item and ten products. Send ten items and ten pouches turn up.
products is optional for UAE orders. For export it is not: the HS code, country of origin, weight and dimensions that clear customs all live there.
Neither a missing product sku nor a very long item name is rejected at create, so if either causes trouble it does so further down the line.
On the product, not the parcel. The create response echoes a default 5.0 kg and 10 x 10 x 10 cm per parcel whatever you sent. Product fields
Barely. PUT /orders/{order_id} accepts only payment_mode and payment_amount, sent together, and only while the order is pending. You can also add and remove parcels while pending. Every operation
You cannot change an address through the API at all. Every other edit is made in Quiqdash, and a change in your own system never reaches Quiqup.
PUT /orders/batch/set_cancelled cancels orders in bulk while they are pending or ready_for_collection.
Once a courier is on the way to collect, from out_for_collection onwards, the API cannot cancel it. Cancel it in Quiqdash, and expect to talk to support. This matters because the fix for several other problems is "cancel and re-book", and that instruction only works through the API until collection starts.
One string covering several unrelated commercial restrictions: segmentation, a closed tier, Quiqdash closed for high demand, the hourly order limit, or a 3PL (third-party logistics partner) not accepting orders.
None of them are payload bugs. Debugging your request will not help.
There is no SDK in any language, and no maintained Postman collection. Each API reference page has a download button for its OpenAPI file, which Postman and most HTTP clients import directly.
Avoid collections exported from the old Stoplight documentation: they point at a mock server.
Everything on staging. You can drive a staging order through its statuses yourself from the dashboard, so you can exercise your webhook receiver without asking anyone.