Developer guide · 6 min read
Taxi dispatch API evaluation guide
An API should make dispatch data useful without weakening tenant isolation or forcing partners to poll for every update.
- Resources
- Bookings, drivers, vehicles
- Auth
- API key boundaries
- Events
- Outbound webhooks
- Safety
- Tenant-scoped access
Check resource coverage
A useful dispatch API should cover the core objects partners need while preserving internal business rules.
- Review booking, driver, passenger, vehicle, quote, zone, and webhook endpoints.
- Ask how response envelopes and errors are shaped.
- Confirm tenant scoping and sensitive data boundaries.
Prefer webhooks to polling
Polling can create latency and load. Webhooks help partners react to events as the operation changes.
- Ask how delivery attempts are tracked and retried.
- Confirm endpoint validation and SSRF protections.
- Use idempotency keys or event IDs when processing events downstream.
Tie API access to audit
External access should not become an invisible back door into passenger, payment, or booking data.
- Require API-key management and scoped access.
- Audit sensitive access and operational mutations.
- Document how deleted or archived records behave.
Related resources
Common questions
Are these resources meant to replace a product demo?
No. They are designed to help operators understand the evaluation criteria before a demo, then link to the product pages that show where Renaro fits.
Why include resources in the first landing scaffold?
Resource pages build topical authority, support internal linking, and give search crawlers helpful content beyond high-conversion product pages.
See Renaro with your own trips.
Bring a few of your real reservations. We'll show you how your office would handle them in Renaro, from the first phone call to the paid invoice.