Integrating Multiple Carrier Systems Into One Bot

Build an Abstraction Layer First

Don't connect your bot directly to carrier APIs. You'll regret it. Instead, create an abstraction layer — a middle service that sits between your bot and each carrier's system.

This layer translates everything into one standardized format. Canada Post's tracking data becomes the same structure as UPS data. A FedEx shipment and a local courier shipment both return identical JSON objects to your bot. Your bot never needs to know which carrier it's talking to.

We built ours as a microservice. When a tracking request comes in, it routes to the right carrier adapter, gets normalized data back, and returns it to the bot. When we added a new carrier last year, we didn't touch the bot code once.

Standardize Your Data Structure

Every carrier gives you tracking data differently. Canada Post includes estimated delivery windows. UPS gives you precise timestamps. FedEx splits data across multiple endpoints. Local couriers sometimes just give you "in transit" with no details.

Define one canonical tracking object that your bot understands. Include fields like current status, last update timestamp, estimated delivery date, current location (if available), and carrier-specific notes. When a carrier doesn't provide a field, leave it null — don't invent data.

This standardization lets your bot respond consistently. A user asking "where's my package" gets the same quality of answer whether it's shipped via Canada Post or a small local courier. That consistency matters for user trust.

Handle Tracking Number Formats

This trips up most developers. Tracking numbers aren't universal. Canada Post uses 13-digit alphanumeric codes. UPS uses 1Z followed by 16 digits. FedEx uses 12, 14, 15, or 22-digit numbers depending on service type. Local Montreal couriers might use 8 characters with letters and numbers mixed.

Your bot needs to identify which carrier handles a tracking number before it queries any API. You can't just throw a tracking number at an API and hope it works — you'll get errors and waste time.

Create a format-detection function. Check the tracking number against known patterns for each carrier. Most of the time this works perfectly. For ambiguous cases (some formats overlap), ask the user which carrier or try all matching carriers in order of likelihood.

Plan for Carrier API Failures

APIs fail. Not often, but regularly. A carrier's system goes down for maintenance. Their API rate limits kick in. A connection times out. Your bot needs to handle this gracefully.

Don't let your bot tell users "API error" or "system unavailable." Instead, implement fallback strategies. Cache the last known tracking status. If a fresh query fails, return the cached data with a note that it might be slightly outdated. For truly critical errors, escalate to a human support agent.

We implemented exponential backoff for retries — first retry after 1 second, then 2, then 4, then 8. If all retries fail, we return cached data. This handles temporary blips without overwhelming the carrier's system.

Also monitor which carriers fail most often. If one carrier's API is consistently unreliable, you'll want to know that pattern so you can plan around it or escalate to their support team.