Maystro runs closer to a fulfillment operation than a classic courier: tighter process, more automation, and a stricter rulebook. That rulebook is what trips up integrations, so read the duplicate policy below before you ship.
One credential from the Maystro dashboard:
| Credential | Field |
|---|---|
| API key | apiKey |
curl -X POST https://freeship.dzbuild.com/v1/orders \
-H 'Content-Type: application/json' \
-d '{
"courier": "maystro",
"credentials": { "apiKey": "YOUR_API_KEY" },
"order": {
"reference": "ORD-1003",
"recipient": {
"fullName": "Karim Haddad",
"phone": "0771234567",
"wilayaCode": 25,
"communeName": "Constantine"
},
"deliveryType": "home",
"productList": "Montre classique x1",
"codAmount": 6900
}
}'- Duplicate policy: Maystro rejects a second order for the same customer
name + phone on the same day. This is deliberate on their side (anti-fraud,
anti-double-submit). You'll get a clear
courier_errorexplaining it. Handle it in your UI rather than retrying; retries will keep failing until the next day. - Commune IDs: Maystro's API doesn't take commune names, it takes internal
numeric commune IDs. You still send
communeNameas a string like with every other courier; the resolution to Maystro's ID happens inside dzship. If the name doesn't resolve, you'll get acourier_errornaming the commune, which almost always means a spelling mismatch with the official list. - Status codes: Maystro reports status as bare numbers, and the numbering
is not intuitive; more than one integration in the wild has shown "delivered"
for parcels that were still waiting for pickup. The mapping to the canonical
vocabulary is verified against production, so
deliveredmeans delivered. - Cancel and labels: both available through the API.
Full request/response reference: freeship.dzbuild.com, or docs/endpoints.md in this repo.