Crowdshipping platforms: can your order survive the handoff?

Your checkout accepts a paid order, the platform says the request was created, and then nobody at the store knows which bag to hand over. That is the kind of failure a merchant can test before a full launch. The useful comparison is not simply which supplier has an app or an API. It is whether every stage gives the next person enough information to act.

This is an acceptance checklist for a shop owner working with an ecommerce partner or developer. It uses Roadie, Stuart and Shopopop documentation checked on 19 October 2026. They are examples of different service designs, not a claim that the same integration or coverage is available on every crowdshipping platform.

Can the platform reject an unsuitable order before you sell the delivery? #

Start with eligibility at checkout. Stuart’s setup guidance says both pickup and delivery addresses must be valid and within its zone coverage. It points to zone and address-validation tools and says delivery distance is restricted by the package size and location in the request. Ask your integration partner to show how those checks affect the option your customer sees.

A postcode check alone can miss the actual basket. A shop might prepare a small item normally but combine several items into a larger package on this order. Your dispatch rule should use the goods and packed size you will hand over. If the provider cannot serve that combination, the shop should resolve it before presenting a confirmed delivery choice.

Keep separate records for order payment and delivery eligibility. The customer paying for goods does not turn an invalid address into an accepted courier request. Agree who contacts the buyer when a delivery option fails validation, and what alternative your shop can actually provide. This is especially useful when local delivery is only one choice alongside ordinary parcel shipping.

Will staff recognise the order when a person arrives? #

Stuart’s guide recommends a unique client_reference for every active delivery. It advises a simple, readable identifier of no more than ten characters and avoiding a special character at the start. This is an operational recommendation, not permission to shorten your internal order number by cutting off the part that makes it unique. Have your partner map the two references deliberately.

Its contact guidance calls for a valid phone number in E.164 format and a usable company or person name. For multiple pickup sites, it recommends a store-level identifier in the company field. Give the courier a real collection contact and give that person the same visible reference. A head-office name shared by several locations is poor evidence that the right order is waiting at the right counter.

Ask staff to rehearse the handover using the information they will actually see. Can they identify the order without opening a separate inbox? Can they distinguish it from another order for the same buyer? Can the person collecting verify the correct goods? Those checks are about preventing the wrong physical handover, not making a status dashboard look complete.

What happens if your shop submits the request twice? #

A slow response creates uncertainty: the first request may have succeeded even if your shop did not receive its confirmation. Ask the provider how to look up the original request and what duplicate protection is available. Do not assume that a retry creates no second task merely because the two requests refer to the same customer purchase.

Roadie’s API requires an access token and HTTPS. Its published rate-limit guidance gives 10 requests per second per user as the current limit, explicitly says this can change, and tells integrations to follow Retry-After on a throttled response. Have your partner demonstrate both an authentication failure and a request that must wait. Repeatedly resubmitting a queue without respecting the response is not a recovery plan.

The money consequence is easy to isolate. AirPost’s constants checked on 19 October 2026 give recommended small-parcel preparation plus the platform fee of €3.10. If an operational error led to two separately completed preparations instead of one, those components would total €6.20, before labels and other costs. This illustrates duplicate completed work; it does not claim that an API retry or cancelled request automatically attracts a charge.

Can you tell a booking from an accepted delivery task? #

Get the integration partner to populate this table with the provider’s real events. A screenshot of one successful order is not a complete answer. You also need an order that remains unaccepted, one whose details change and one that needs support. Keep a named person responsible for following those open cases in your shop.

If a status stops updating, staff should still know which provider reference to use and where the goods last were. Make that information available without asking the customer to explain the entire journey again. Tracking is useful when it supports the next action; a link by itself cannot decide whether you should resend an order.

Who gives the buyer the delivery information? #

Shopopop’s retailer help page describes requests arriving either automatically through its API or manually through Shopopop Pro. It says customers receive confirmation, subsequent email or SMS updates and a tracking link. Before connecting any platform, identify which messages come from the provider and which your shop still needs to send. The two message streams should describe the same actual stage.

For scheduled work, Stuart distinguishes instant requests from requests for a predetermined pickup time. Its setup guide says scheduled pickups must be in the future and that the customer’s delivery window should be supplied through the designated fields. A checkout promise, the store’s preparation schedule and the provider’s requested timing need to agree. Do not let the customer choose a slot your collection workflow cannot support.

Test a changed phone number and a corrected address as well as the original purchase. Establish which changes can still reach the booked task and which need support or a new request. Your store updating its own order record is not evidence that a person already on the way has received the correction.

What extra handoff does stock-based fulfilment introduce? #

AirPost’s published workflow begins with a shop agreeing with a sender and sending its products and packaging. The sender then accepts an order, prints its label, packs and drops it at a parcel point. That means your operating checklist needs to establish available stock and packing instructions before the outward carrier event. A courier connection starting at collection would leave those earlier tasks unanswered.

Use the Shopify fulfilment guide for that shop-specific setup, rather than assuming any delivery API is a fulfilment connection. Confirm the current supported workflow for your own store. The platform checklist here does not promise that AirPost exposes the Roadie or Stuart interfaces or that those couriers can be booked through AirPost.

Before releasing a new sales channel, walk a real order through your chosen handoffs and retain its references, final evidence and total cost. If you need someone to pack stock near your customers, AirPost’s local fulfilment page gives you the appropriate starting point. Set the customer promise only after the people and systems doing the work can support it.