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
Frequently asked 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.
Platform walkthrough
See how Renaro handles your real operating workflow.
Bring a booking scenario, a dispatch policy, a pricing edge case, or a migration concern. The walkthrough should prove how the platform behaves under actual operator pressure.