We have introduced a unified reasons API that serves configurable failure reasons across the platform in a single, consistent format. Two categories are live today — stop failure reasons and package failure reasons.

This gives operators and integrators one predictable shape to build against: each reason exposes a stable machine-readable key, a localised label suitable for display, the contexts it applies to, and a properties bag carrying any category-specific flags. Clients can now render reason pickers with the same code regardless of the category, and new reason categories can be added on the server without requiring client changes to the response shape.

Stop failure reasons — returned by GET /api/reasons/stop_failure — are the predefined reasons a driver can pick from when failing a booking stop. They are sourced from a platform-maintained catalogue and localised in all supported languages.

Package failure reasons — returned by GET /api/reasons/package_failure — are the tenant-configurable reasons already used at package pickup and delivery. They are the same reasons previously served by the legacy GET /api/hailing/failure_reasons endpoint, now reshaped to fit the unified format. The legacy endpoint continues to work and is scheduled for removal — see the related deprecation announcement for the field mapping and migration details.