Most of the bugs on taxi websites happen where the booking form meets the dispatch system. Here’s what to watch for and how to avoid them.
If your website takes a booking and your dispatch system doesn’t receive it, you haven’t taken a booking — you’ve taken a complaint. Every firm we’ve worked with has had at least one version of this problem. Here’s what we’ve learned about making it not happen.
The Major Dispatch Systems in the UK
- iCabbi — cloud-based, REST API, well-documented, widely used by larger fleets.
- Autocab / FleetExchange — established, SOAP / REST hybrid, tightly integrated with Cab Exchange for cross-firm referrals.
- Cordic — strong in the North of England; REST API with OAuth.
- CabTreasure — popular with mid-size firms; simpler REST interface.
- Taxi Booker — web-first, straightforward integration.
- Ghost Systems, Magenta, T Dispatch — various, each with its own quirks.
- Bespoke — usually a SQL-ish system behind a scripting layer; doable but budget for discovery time.
The Five Things That Go Wrong
1. The API was designed for in-house apps, not third-party websites
Many dispatch APIs assume the caller is the vendor’s own driver app. Error messages are cryptic, authentication docs assume you know the conventions, and rate limits aren’t published. Solution: set up a proper integration account with the vendor and ask for sandbox credentials before any client-facing work starts.
2. Pricing logic lives in two places
Your website needs to quote fares. Your dispatch system needs to charge them. If the two use different pricing rules, riders see quoted £8.50 on the site and get charged £11.20 on arrival. Solution: your website always calls the dispatch API for fare quotes — never replicate the pricing table.
3. Address resolution disagrees
Rider types “The Crown, Chester”. Your website finds CH1 2AB. Dispatch thinks CH1 3BC. Driver goes to wrong place. Solution: use Google Places on the website and pass the place_id (not the string) to dispatch. Most modern dispatch APIs accept place_id directly.
4. The dispatch system goes offline
It happens. When it does, your website needs to either queue bookings for replay or gracefully fail with a “please call” message. Silent failures into the void are worse than either. Solution: health-check the dispatch API every 30 seconds, and have a fallback queue that auto-retries for 15 minutes before giving up.
5. Timezone and DST
Pre-book a ride for 01:30 on the night the clocks change. Dispatch schedules it twice, or not at all. Solution: always store UTC, always display the rider’s local time, always test around DST transitions.
What a Good Integration Looks Like
- Fare quotes come live from dispatch — no duplication.
- Address resolved on the website using Google Places; place_id passed to dispatch.
- Booking confirmed to rider after dispatch returns a booking ID.
- Dispatch returns ETA; website displays it; website polls every 30 seconds for updates.
- Health checks with graceful degradation to “please call” if dispatch is down.
- End-to-end logs: every booking logged with dispatch response for debugging.
What to Ask Your Dispatch Vendor Before Signing
- Is there a public API? Is the documentation current (not 2018)?
- Are there sandbox credentials available for development?
- What’s the rate limit?
- Is there a webhook for driver status / ride completion, or only polling?
- Is there a status page or incident history?