DispatchPro: A Taxi-Dispatch
API Integration

A trip call comes in for a small taxi and livery fleet. Somebody used to read it, work out which driver was closest and least busy, and hand it off, over and over, all day. DispatchPro does that same job on its own: it pulls the call from a service the company does not control, cleans it up, works out which driver can reach the pickup soonest, and assigns it, all without anyone watching.

Put simply, DispatchPro is an automated dispatch system whose core is two API integrations working together: a third-party call feed, the MedAnswering (MAS) service, and the Google Maps API. Built on Laravel, it turns incoming trip calls into clean records, matches them against driver locations to estimate pickup times, and assigns each call to the nearest, least-loaded driver, reliably enough to run unattended. This case study is about the integration problems that made that hard, how we solved them, and the result.

The Starting Point: Two Third-Party APIs, One Fleet to Dispatch

The hard part of DispatchPro was never the screens. It was making two third-party APIs work together reliably enough to dispatch a fleet automatically, replacing a daily manual job. That meant solving a specific set of integration problems.

• No live feed to subscribe to. The MedAnswering service does not push new calls, so we could not simply receive them. We had to pull them ourselves without missing or duplicating any.
• Calls did not arrive as clean data. The incoming call information was semi-structured, not a tidy data object, so it had to be parsed and normalized before the system could use it.
• Addresses, not coordinates. Calls and drivers came with addresses, but the maps API needs coordinates to compute travel time, so locations had to be resolved first.
• The maps API has limits and costs. Estimating every driver’s pickup time for every call can mean many Google Maps calls, which runs into rate limits and cost if done naively.
• Third-party services fail sometimes. A polling call or a maps request can time out or error, and dispatch cannot stall or lose a call when it does.
• One integration, many companies. The same integration had to run as separate instances with different API keys and branding, without forking the code.

The Build: Poll, Normalize, Geocode, Assign

The integration is a resilient Laravel backend. Because MedAnswering offers no live feed, Laravel’s scheduler pulls calls on a set interval instead of waiting to be told, and consuming an external feed cleanly like this is the substance of the custom API development behind the product. Each call is de-duplicated by its trip identifier so nothing is processed twice, even when polls overlap. From there the pipeline runs in order:

1. Laravel’s scheduler polls the MedAnswering API on an interval and keys every call by its trip identifier, so each call is captured exactly once.
2. A parsing layer normalizes each semi-structured call into a clean record, passenger, phone, pickup and dropoff times and addresses, and trip ID.
3. Pickup addresses and driver locations are geocoded to coordinates, since the maps API needs them.
4. The Google Maps Distance Matrix API estimates each active driver’s pickup time, querying only active drivers and batching and caching the lookups.
5. The assignment engine picks the driver with the smallest estimated pickup time while keeping each driver’s number of calls balanced.
6. The call is pushed to that driver’s web app, and drivers see their calls in pickup-time order.

All of this runs in queued jobs with retries and backoff, so a timed-out poll or a failed maps request is retried rather than dropped and dispatch keeps moving. Calls auto-complete after dropoff with admin override, and the whole pipeline leans on Laravel’s scheduler and queues, the kind of backend orchestration that solid Laravel development is built for.

Technical Architecture

The architecture is a Laravel backend that integrates two third-party APIs, MedAnswering for calls and Google Maps for travel time, behind a resilient polling, parsing, geocoding and assignment pipeline, with admin and driver web apps on top. It centres on a handful of subsystems.

• Polling and de-duplication. Laravel’s scheduler polls the MedAnswering API on an interval, and each call is keyed by its trip identifier so it is processed once and only once, even across overlapping polls.
• Parsing and normalization. The semi-structured call data is parsed into a clean, structured record at intake, so the rest of the system works from reliable fields rather than raw text.
• Geocoding and travel time. Pickup and driver addresses are geocoded to coordinates, and the Google Maps Distance Matrix API estimates each active driver’s pickup time from there.
• Efficient maps usage. Travel-time queries are limited to active drivers, batched and cached, so assignment uses as few Google Maps calls as possible and stays within rate limits and budget.
• Assignment engine. The engine assigns each call to the active driver with the smallest estimated pickup time while balancing the number of calls across drivers, then pushes it to that driver in pickup-time order.
• Resilience and multi-instance. External calls run in queued jobs with retries and backoff so failures do not drop calls, and API keys and branding live in per-instance configuration so the integration runs for multiple companies.

Challenges Solved

Each problem was met with a concrete answer. Getting calls with no live feed was solved by polling the API on a schedule and de-duplicating each call by its trip identifier, so every new call arrives automatically and none is processed twice. Messy call data became usable through a parsing and normalization layer at intake, so the whole system works from trustworthy fields instead of raw text. Addresses were made usable to the maps API by geocoding pickups and driver locations first, which produces real, road-based pickup-time estimates.

Keeping Google Maps fast and affordable came down to querying only active drivers, batching the Distance Matrix lookups and caching them, so ETAs stay quick and within rate limits rather than flooding the API. Surviving third-party failures was handled by running every external call in a queued job with retries and backoff, so a timed-out poll or maps request slows dispatch at worst and never breaks it. And running the same system for several companies was solved by moving the MedAnswering and Google Maps keys and the logo into per-instance configuration, the reusability that suits multi-tenant SaaS products where one codebase serves many customers.

The Result

The outcome is dispatch that runs itself. Calls are pulled from MedAnswering with no manual entry and no duplicates, messy call text is normalized into records the system trusts, and Google Maps is used efficiently for real pickup times. Each call goes to the nearest, least-loaded driver, and retries and queues keep dispatch moving through third-party hiccups. Because the API keys and branding are swappable per instance, the same integration stands up for a new company without any code changes, replacing what used to be a daily manual job with a pipeline that assigns every call on its own.

If you are automating an operation that depends on stitching third-party APIs together reliably, you can hire back-end developers who have built resilient polling, geocoding and assignment pipelines, or tell us about your workflow and we will map your feeds and services into a system that runs unattended.

Frequently Asked Questions

Can you pull calls from a service that has no live feed?

Yes. MedAnswering does not push new calls, so Laravel’s scheduler polls its API on a set interval instead. Each call is de-duplicated by its trip identifier, so every new call is captured exactly once even when polls overlap or a call appears across several polls.

How do you turn messy call data into something a dispatch system can use?

A parsing and normalization layer at intake converts each semi-structured call into a clean, structured record, passenger, phone, pickup and dropoff times and addresses, and trip ID. Everything downstream, assignment, notification and reporting, then works from reliable fields instead of raw text.

How do you keep Google Maps costs and rate limits under control?

Travel-time queries go only to active, available drivers, and those driver-to-pickup lookups are batched and cached. That way each assignment uses as few Google Maps Distance Matrix calls as possible, keeping ETAs quick and affordable rather than flooding the API and hitting rate limits.

What keeps dispatch running when a third-party API fails?

Every external call, both the MedAnswering poll and the Google Maps request, runs in a queued job with retries and backoff. A timed-out or failed call is retried rather than dropped, so a third-party outage slows dispatch at worst and never breaks it or loses a call.

Can one dispatch system serve multiple companies?

Yes. The MedAnswering and Google Maps API keys and the company logo live in per-instance configuration, so the same integration runs as separate instances with different keys and branding. A new company is stood up without forking or changing the code.