Observations about the documentation
- Sending reciever data and proof of delivery is not mandatory, but almost all carriers available on our platform guarantee proof of delivery. Therefore, it is expected that your integration also provides this.
- Few carriers send real-time driver location. This is a feature of extreme importance for the final customer experience. If you have the technology for it, it is a significant advantage against other competitors
Here you have a checklist to understand which data is being sent
- Do you send driver data, such as name and document? This should preferably arrive at the /driver-assigned or /collecting endpoint.
- Do you send the reason for the failure correctly? It is recommended that the reason for the failure is sent in the "failure_driver_message" or "observation" field as a complete string, depending on what the carrier's app supports.
- Do you send ETA (Estimated Time of Arrival)?
- Do you send recipient data and/or proof photo? They can arrive together with the success event at the /successful endpoint or later at the /receiver endpoint.
Flows to be validated during homologation
All flows were thought to validade the integration both technical and operationwise. If the flow does not apply to your case it will be reconsidered by both teams how it would affect the final customer experience
- STANDARD: This is the expected flow in most deliveries
- NEW REQUEST: In case the brand or the transporter needs to cancel the delivery, it should be possible to make a new request for the same order without errors
- CANCELLATION: This flow is possible in case of loss. The most common scenario is a delivery failure followed by a return (where you send a return report), but you may need to cancel the delivery to finalize it
- RETURN
- SECOND ATTEMPT
