We have integrated iCabbi with a UK taxi firm website six times. First in 2021, most recently two months ago. That means we have seen iCabbi across two major UI overhauls, several API iterations, and a full cycle of what works and what does not. This post is the honest review, from a website-integrator perspective, not a vendor-sponsored roundup.
If you are considering iCabbi for your firm, or you are already on it and wondering whether the platform is as good as the sales deck suggests, read on. The short version: iCabbi is one of the better platforms we work with, but it has rough edges and sales will not volunteer them. Here they are.
What iCabbi Is Actually Good At
Start with what works. We are picky about dispatch platforms because the website handover is only as good as the platform receiving the booking. iCabbi gets a lot right.
- REST API with real documentation. You can read icabbi.com and get a feel for the product, but the actual API docs (shared with integration partners) are genuinely useful. Endpoints do what the name implies. Error messages are informative. We have not had to guess.
- Reliable webhooks. Booking status changes fire promptly. In six integrations we have seen two missed webhooks total, both inside the first 48 hours of a new firm going live, both explainable. Everything since has been solid.
- Sensible account customer handling. The account portal is strong enough to go head to head with Uber for Business for most mid-size UK firms. That matters more than product demos suggest.
- Driver app UX. Drivers do not complain. That is rare. Most driver apps generate weekly support tickets. iCabbi’s app gets updates, gets used, and does not crash.
- UK and Ireland-based support. The people who answer the phone understand the trade. They know what a hackney plate is, what an airport pre-book looks like, and why a Friday night at 10pm is a bad time to deploy a patch.
Combined, those five points make iCabbi the default mid-size choice for most firms we work with. Nothing below contradicts that.
What Breaks, And How to Plan Around It
Nothing is perfect. Here is what we have seen break, and what to do about each one. These are not show-stoppers. They are the small frictions that firms wish they had known before signing.
Fare Zones Can Get Out of Sync
When your website calculates a fare to show the passenger, it needs to use the same zone logic as iCabbi does on the dispatch side. If the two drift apart, the website will show one price and iCabbi will assign a different price to the driver. The passenger gets quoted £22. The driver accepts a job worth £18. A row follows.
The fix is to always fetch the fare from iCabbi’s fare estimation endpoint, not to rebuild the logic in the website. When we build a booking form for an iCabbi firm, the form calls iCabbi to get the quote, displays that, and then submits the same quote back. No drift.
Sandbox Access Is Not Automatic
To test a website handover properly, your integrator needs a sandbox iCabbi environment with a test fleet. iCabbi provides this, but you have to ask. If the firm does not request sandbox access during onboarding, the integrator ends up testing against the live fleet, which is risky.
Ask for sandbox access in writing during setup. Include API keys, a test fleet with three dummy drivers, and a clear statement that bookings created in sandbox will not generate charges. iCabbi are fine with all of this. They just do not always think to offer it.
API Rate Limits Are Real
For busy firms, the fare estimation endpoint has a rate limit. If a website page loads a fare on every postcode search, a very busy site can hit the limit on a Friday evening. The symptom is sporadic fare display failures.
The fix is caching. We cache fare estimates for three minutes at the postcode-pair level. That drops API calls by roughly 80 percent and the passenger never notices. If you are working with another integrator and your fare form flickers at peaks, ask them whether they have caching turned on.
Webhook Retries Need Idempotency
iCabbi retries failed webhooks. If your website handler is slow and times out, iCabbi will send the same webhook again. Without idempotency handling, you end up processing the same booking update twice. We saw this once on a new build where the status endpoint was acknowledging too slowly.
Every booking webhook has a unique event ID. A properly built handler stores each ID and ignores duplicates. Basic, but easy to miss. If your integrator does not talk about idempotency when quoting the dispatch handover, raise it.
SMS Delivery Can Lag
iCabbi’s SMS notifications to passengers are reliable, but on rare occasions they lag by two or three minutes. For a pre-booked airport run, that does not matter. For a “your driver will be there in 5 minutes” message, it does. The passenger has walked outside before the SMS arrives.
The workaround is to also push a status update to the passenger through your website (a “track your driver” page) as a backup channel. Most firms do not need this, but it is useful for premium bookings and account work.
Six Integrations, Six Lessons
Every time we integrate iCabbi with a WordPress site, we learn something. Here is one lesson from each of the six builds we have shipped, in order.
- Build 1. Do not store the iCabbi API key in the WordPress options table. Use environment variables. We learned this after a security audit flagged it.
- Build 2. The “driver assigned” webhook is not the “on route” webhook. Treat them as separate status transitions for passenger messaging.
- Build 3. iCabbi’s distance calculation is straight line by default. For fare estimates shown to the passenger, ask iCabbi to enable route-based distance if that matches how your fares actually work.
- Build 4. Account customer booking needs the account ID in the booking payload. Miss that and the job lands as a private hire booking, not an account job, and finance get a surprise at month end.
- Build 5. Time-of-booking matters. A booking made for “as soon as possible” has a different payload shape than a booking for a specific future time. Write both paths, not just the ASAP one.
- Build 6. Passenger phone number formatting. iCabbi prefers E.164. If your form collects 07 format, convert before submitting. We lost two hours debugging this on the most recent build.
These are not warnings. They are the normal footnotes of working with any mature SaaS platform. Every other platform has an equivalent list. iCabbi’s list is shorter than most.
Ask iCabbi Sales These Before You Sign
If you are in procurement mode with iCabbi, put this list of questions in front of your account manager. Write their answers down. We give this list to every firm we help through dispatch evaluation.
- What is the fully-loaded cost for my fleet size over three years? Licence, driver app fees, setup, SMS at my typical volume. One number.
- Is the driver app fee per vehicle or per driver? Get this answered in writing. It is the single biggest hidden cost.
- What is the notice period on contract exit? And in what format do I get my customer and booking data back?
- Can my web integrator get sandbox access during onboarding? What are the API keys, the test fleet setup, and the API rate limits?
- What is the CPI escalation clause? Is there a cap? Most vendors will cap at 5 percent if you ask before signing.
- Which modules are optional and which are bundled? Account portal, passenger app, SMS gateway, card processing. Get the list.
- How does fare estimation work on the API? Real-time or cached? Does it match what the dispatch system assigns to the driver?
- What is the SLA on webhook delivery? Any written commitment or best-effort?
- Who is my day-to-day support contact? Named person, email, phone. Not a ticket portal.
- Can I have two reference customers of my size? Ring both.
Ten questions. Get them answered. Sign when eight of them are answered well and the other two have honest workarounds. Do not sign when half of them are “we will come back to you on that”.
How iCabbi Compares to the Others
Short summary of how iCabbi stacks up against the other three platforms we work with on UK taxi firm websites.
| Dimension | iCabbi | Autocab | Cordic | TaxiCaller |
|---|---|---|---|---|
| API quality | Very good | Good, slower to access | Good | Good, simplest |
| Driver app | Polished | Stable, dated | Functional | Clean |
| Account portal | Strong | Strong | Basic | Basic |
| Support responsiveness | High | Medium | High | Medium |
| Price transparency | Medium | Low | High | Very high |
| Integration friction | Low | Medium to high | Low | Very low |
For the full side-by-side on all four platforms, see the comparison post on taxi booking system comparison. For the broader decision framework by firm size, the dispatch integrations guide covers which platform to pick given your fleet.
Would We Pick iCabbi for Our Own Firm?
If we ran a 20 to 50 vehicle firm tomorrow, we would pick iCabbi. Six integrations in, we know the product, we know the rough edges, and we know how to work around them. The support team is competent, the API is strong, and the driver app keeps drivers happy.
If we ran a 5-vehicle firm, we would probably pick TaxiCaller or Cordic instead. Not because iCabbi is bad at small fleets, but because the per-vehicle cost is harder to justify below 10 vehicles. If we ran a 100-plus fleet with heavy airport or contract work, we might move to Autocab for the Ghost network and the enterprise reporting. iCabbi lives comfortably in the mid-market, which is where most of our clients sit.
For accessibility considerations that apply across any dispatch platform and its driver and passenger apps, the WCAG 2.2 standard at w3.org is the starting point. Your website needs to meet this, and the passenger-facing parts of any dispatch platform should too.
Your Move This Week
You do not need to switch to iCabbi this week, or away from it. You need to check whether it is doing its job for your firm. Three actions, about 30 minutes.
- Submit a test booking from your website. Time the gap between the passenger clicking book and the job appearing in iCabbi. Anything over 30 seconds suggests your integration is not real-time.
- Check a fare on your site, then submit the booking. Compare the fare shown to the fare iCabbi assigns the driver. If they differ, you have a zone mismatch. Fix it before your next driver row.
- Book a free booking funnel audit. We will check your iCabbi handover, the fare sync, and the webhook handling. You get a one-page PDF with the three biggest fixes. No pitch attached. Request your audit here.
For pricing on a rebuild that includes a proper iCabbi handover, see the pricing page. For live examples of UK firms running iCabbi with a Taxi Elite site, the portfolio is worth a browse. And if you want the broader overview of a good taxi site before you worry about dispatch, the taxi website design piece is a good primer.
iCabbi is not perfect. No dispatch platform is. After six integrations, it remains the one we reach for first when a UK firm in the 15 to 80 vehicle range asks what to run. Ask the right questions, plan for the rough edges, and it will earn its keep.