Taxi dispatch API integration guide — connecting booking channels, PMS, and payments in 2026

Vendor marketing copy often lists 'API' as a checkbox feature without saying what it actually exposes. In practice there are three distinct surfaces worth separating: a booking API (create, quote, and cancel jobs from an external system), a webhook/event stream (the dispatch platform pushes status changes — assigned, en route, arrived, completed, cancelled — to a URL you control), and a data-export API (pull historical trips, invoices, and driver records for reporting or accounting sync). Some platforms only ship one of the three, usually the booking API, which is enough for a hotel widget but not enough for a corporate client who wants a live status feed or a finance team who wants automated invoice reconciliation.

Authentication matters more than it looks on a spec sheet. Look for per-integration API keys (not one shared secret across every partner), scoped permissions (a hotel widget key that can create bookings but not read other accounts' trip history), and key rotation without downtime. A platform that hands out one static API key for the whole account is a liability the moment a partner's system is compromised or an integration is retired and someone forgets to remove the key from the partner's codebase.

Rate limits and sandbox access are the two things engineering teams ask about first and vendors mention last. A sandbox environment that mirrors production (same endpoints, fake driver pool, no real dispatch) lets a partner's developers build and test without risking a live job being created by mistake. Ask for published rate limits in the docs, not 'contact support if you hit a limit' — an undocumented limit is the kind of thing that surfaces as a production incident during a marketing campaign's traffic spike.

Website and app booking widgets are the most common first integration — an operator's own website, or a partner site, embeds a quote-and-book form that calls the dispatch API directly instead of routing through a phone line or a generic contact form. The value is immediate: bookings that used to require a call handler now create a job automatically, at any hour, with no wait time for the customer.

Hotel and venue front-desk integrations are the next most common, particularly for airport and city-centre operators. A hotel's property management system (PMS) or concierge tool calls the booking API when a guest requests a taxi, tagging the job with the room number and guest name automatically rather than a front-desk staffer relaying details over the phone. For operators running corporate or hotel account relationships, this is usually the integration that unlocks volume — hotels standardise on whichever operator makes their front-desk workflow one click instead of five.

Corporate travel and expense platforms (a company's internal booking tool, or a third-party travel management system) are the highest-value integration for operators chasing B2B account revenue, because the booking API lets the client's own system push the job with cost-centre and employee data already attached, and the data-export API lets the operator's finance team reconcile monthly billing without a manual account-by-account trip pull.

Payment and accounting sync is the integration operators underestimate until they are three years into fast growth and still exporting CSVs by hand. A completed-trip webhook that fires into an accounting package (or a data-export endpoint a finance team polls nightly) removes the manual reconciliation step that otherwise scales linearly with booking volume — it is the integration with the clearest ROI per engineering hour spent, because it replaces recurring manual work rather than adding a one-off feature.

A dispatch platform without webhooks forces every downstream system to poll for status — a corporate travel tool checking every 30 seconds whether a trip is still 'requested' or has moved to 'assigned'. That works at low volume and falls over at scale: more integrations polling more frequently means more load on the dispatch platform's API for information that changed rarely between polls. A webhook model pushes the state change the moment it happens, which is both lower-latency for the partner system and lower-load for the dispatch platform.

The practical failure mode with webhooks is delivery reliability — a partner's endpoint is down for five minutes and the event is lost forever unless the dispatch platform retries with backoff and, ideally, exposes an event log the partner can query to catch up on anything missed. Ask a vendor directly whether webhook delivery retries and whether there's a way to replay missed events; 'we send a POST request' without a retry story is a partner-integration risk you'll only discover the first time their server has a bad afternoon.

Ask for the actual API reference documentation before signing anything — not a sales deck slide that says 'REST API available'. If a vendor can't produce endpoint-level docs (request/response shapes, auth flow, error codes) on request, that is a strong signal the API is thin, undocumented internally, or maintained ad hoc for one existing partner rather than built as a real product surface.

Ask how many live third-party integrations are running against the API today, and for how long the API's request/response shape has been stable. An API that changed its booking payload structure twice in the last year is going to be a maintenance burden for every partner integration you build against it, because you'll be re-testing after every vendor release rather than once.

Ask what happens to API access on a plan downgrade or contract dispute — some platforms gate API access behind their highest pricing tier and will cut it off immediately if an account moves to a lower plan, which is a serious operational risk if a live partner integration depends on it. Get this in writing, not as a verbal assurance from a sales rep.

Ask whether the API supports the specific integration you need today, not just 'API access' in the abstract — a platform with a mature booking API might have no webhook support at all, which matters enormously if the integration you actually need is a live status feed for a corporate client rather than a one-way booking form.

If a fleet is spending real engineering time working around a dispatch platform's API limitations — building a scraper because there's no export endpoint, polling aggressively because there are no webhooks, maintaining a shared API key because there's no scoped-permission model — that engineering cost is worth comparing directly against the cost and disruption of migrating to a platform with a more complete API. It is easy to sink incremental hours into workarounds for a year and never total up what that time actually cost against a migration that would have taken a fraction of it.

Conversely, a platform's API maturity is not usually the deciding factor for an operator with no current integration need — if there is no hotel partner, no corporate client asking for a feed, and no accounting sync pain, API depth is a feature to bank for later rather than a reason to switch today. Prioritise it once a specific integration is on the roadmap, not as an abstract checkbox.

TaxiCloud's API covers booking creation and quoting, webhook events for the full job lifecycle (requested, assigned, driver en route, arrived, in progress, completed, cancelled), and data-export endpoints for trips, invoices, and driver records — available from the Pro plan upward, with sandbox access on request during a trial. Per-integration API keys with scoped permissions are standard, so a hotel widget key and a corporate travel tool key can be issued, monitored, and revoked independently without touching each other.

The existing `/api/driver/v1/*` driver-app contract has been kept stable through the platform's modernisation specifically so operators with custom driver tooling or existing integrations are not forced into a breaking migration on our timeline. For operators evaluating a switch with a live partner integration already built against a previous platform, our migration team scopes the API mapping work as part of the standard 7-10 day cutover rather than leaving it as a separate project.