Integrations and Public API Overview

This article gives a high-level catalog of the kinds of outside systems the Tai TMS connects to — carriers and rating, tracking providers, load boards, accounting, payments, fuel, factoring, and tax-rate lookup — and explains that the Tai TMS also offers a versioned public API so customers and partners can integrate their own systems with it, including how older API operations are being retired.

Overview

The Tai TMS is built to sit at the center of your freight brokerage and exchange data with the outside systems you already use, so information doesn't have to be re-keyed by hand. It connects to carriers for rating and dispatch, to visibility providers for tracking, to load boards for posting available freight, to accounting and payment systems for billing and settlement, and to specialized services for fuel pricing, factoring, and tax rates. In addition to these built-in connections, the Tai TMS publishes its own public API — a documented, versioned interface that lets your team or a technology partner build custom integrations that read from and write to the Tai TMS directly. The current version is v2; older operations from the original version are being retired in stages, and new integration work should use the current version.

How it works

Categories of built-in integrations. The Tai TMS groups its outside connections by what they do. At a high level, these categories include:

Carriers and rating engines — getting live rate quotes and dispatching loads to carriers. This spans real-time carrier and marketplace rate lookups as well as capacity and pricing intelligence services.
Tracking / visibility providers — pulling a shipment's current status, location, and milestone dates. The Tai TMS supports both direct carrier tracking (a large number of carriers) and third-party visibility networks.
Load boards — advertising your available freight to carriers, then updating or removing those postings. The Tai TMS can post, repost, and remove loads across multiple boards.
Accounting systems — syncing invoices, bills, and financial records into your accounting platform.
Payments and settlement — processing carrier and customer payments, including credit-card gateways and carrier-payment services.
Fuel — looking up fuel-surcharge and fuel-related invoice amounts from a fuel-pricing service.
Factoring — working with factoring companies so carrier payments and invoices are routed correctly.
Tax rates — looking up current Canadian provincial sales-tax rates for tax lines on a shipment's pricing. If the lookup is unavailable, the Tai TMS falls back to built-in standard provincial rates, and an unknown or blank province is treated as Ontario.

Alongside these, the Tai TMS integrates with supporting services such as carrier onboarding and compliance networks, document OCR (reading data off uploaded documents), dock/appointment scheduling, and shared-inbox/communication tools.

Each integration is turned on per organization and works quietly in the background: when you rate, dispatch, track, post, bill, or pay, the Tai TMS reaches out to the relevant outside system, brings the result back, and records it on the shipment.

The public API. For customers and partners who want to connect their own software, the Tai TMS offers a public API — a stable, documented web interface. Through it, external systems can perform core operations such as rate quoting, booking and managing shipments, checking shipment status, managing driver-tracking sessions, and working with customers, carriers (including carrier trailers), invoices, bills, payments, commissions, general ledger accounts, sales reps, shipment stops, shipment locations, staff, organizations, and load-board data. Accounting operations include moving a bill or an invoice into variance and, newly, clearing a variance: resolving a bill's variance (buy side) or a shipment's invoice variance (sell side) puts the affected charge lines back to ready without changing any amounts. The public API also accepts inbound notifications (webhooks) from integration partners, so partner systems can push updates into the Tai TMS. Access is controlled with an API key issued to you, and the API is documented so your developers can see exactly what operations and data shapes are available.

Versions and retiring older operations. The public API is offered in more than one version. The current version (v2) carries the full set of operations, and newer capabilities are added there so that the shapes existing integrations depend on don't change. Newer areas exposed through v2 include driver-tracking session management — starting, updating, refreshing, canceling, retrieving, and messaging a driver-tracking session for a shipment from your own system — alongside expanded carrier, organization, and accounting operations. Your integration keeps using the version it was built against, but older operations are being retired in stages:

Operations already removed. Most of the original (v1) operations — such as the older shipment booking, shipment status, status-setting, and document-upload operations — have been removed. Calls to them no longer succeed.
Operations being switched off. The older accessorial-list, shipment-documents, and ZIP-code lookup operations are being turned off in stages. Once one is off, calls to it receive a "not found" response with a message that the operation has been fully deprecated and asking you to move to the updated v2 operations.
Operations still available from v1. The original rate-quote operations (less-than-truckload, truckload, and domestic freight) remain available.
Deprecated but still working. A group of v2 operations is marked "Deprecated" in the API documentation — the older shipment booking, shipment-details, activity-log, reference-number, alert add/resolve, and tracking-update operations, plus older by-ID and by-shipment invoice, bill, and payment lookups and sync confirmations. They still work today but are pending end of life, and the documentation asks developers to move to the newer operations.

If you built an integration against an older operation, review the API documentation and move to the current v2 operations before the older ones are switched off.

Rate limiting. To keep the public API fast and fair for everyone, Tai can track request volume per organization and per API key against limits for per-minute, per-day, and per-month windows, where rate-limit tracking has been switched on. The windows are fixed calendar periods — the minute, the calendar day, and the calendar month — and the day and month periods follow UTC dates, resetting when the period rolls over. Limits are chosen and managed by Tai; a window with no limit set is unlimited. The tracking is done in front of the Tai TMS application and covers the main areas of the API (for example shipping, accounting, broker, customer, carrier, staff, organization, and load-board operations). At present, usage above a limit is recorded and flagged for Tai to review rather than being automatically rejected. Even so, design your integration to stay within its allotment, avoid sending large bursts of traffic, and contact Tai if you expect to need higher volumes.

Business rules & limits

Integrations are enabled per organization. Each connection to an outside system is configured for your organization, so what's available to you depends on which integrations your organization has set up and turned on.
The catalog is broad but not universal. The Tai TMS connects to many carriers, boards, and providers across the categories above, but not to every possible vendor. Whether a specific carrier, board, accounting system, or payment provider is supported depends on the current integration catalog; new integrations are added over time.
The public API is versioned and kept backward-compatible. The Tai TMS publishes its public API under a stable version, and changes within a version are additive only — existing fields and behavior are not changed out from under integrators. When a change would break existing integrations, it is introduced as a new version rather than by altering the current one.
Older operations are retired deliberately, in stages. Operations are first marked deprecated, may be turned off in stages (callers then receive a "not found" response with a deprecation message), and some original operations have already been removed. New work should use the current v2 operations.
The public API is documented and opt-in per operation. The available operations are published in the API's documentation. Not every internal capability is exposed externally; only the operations intended for external use appear in the public API.
API access requires a key. Calls to the public API are authenticated with an API key issued to you; a request without a valid key is rejected as unauthorized. Inbound partner notifications (webhooks) arrive on dedicated partner endpoints rather than the customer API.
Driver-tracking sessions follow rules. Each shipment can have only one driver-tracking session; the tracking source you use must be an external tracking source available to your organization; you can update, refresh, or message only a session that is still active; and you can cancel or retrieve a session in any status. Refreshing a session asks for an update ahead of its normal schedule, and sending a message through the API records the message on the shipment but does not itself deliver it to the driver.
Variance clearing has conditions. You can clear a bill's variance only when the bill actually has charge lines in variance, and you need the matching accounting permissions; clearing only returns the charge lines to ready and never changes an amount. Repeating a clear after a successful one returns an error because nothing is left in variance.
The public API is rate-limited. Request volume is tracked per organization and per API key over per-minute, per-day, and per-month fixed windows, using limits Tai sets for you. Usage above a limit is currently recorded and flagged rather than automatically rejected, but you should still stay within your allotment.
Some integrations are pull-based. Tracking, for example, works by the Tai TMS actively requesting the latest status from the provider or carrier when needed, rather than the carrier continuously pushing updates. That means status reflects the most recent pull.

Frequently asked questions

What kinds of outside systems does the Tai TMS integrate with?

The Tai TMS integrates across several categories: carriers and rating engines (for quotes and dispatch), tracking/visibility providers (for shipment status and location), load boards (for posting available freight), accounting systems (for syncing invoices and bills), payment and settlement services (for carrier and customer payments), fuel-pricing services (for fuel surcharges), factoring companies, and a tax-rate lookup for Canadian provincial sales tax. It also connects to supporting services like carrier onboarding/compliance, document OCR, and appointment scheduling.

Does the Tai TMS have an API I can use to build my own integration?

Yes. The Tai TMS publishes a versioned public API that lets customers and partners integrate their own systems. Through it you can do things like request rate quotes, book and manage shipments, check shipment status, manage driver-tracking sessions, and work with customers, carriers, invoices, bills, payments, commissions, staff, organizations, and load-board data. It also accepts inbound webhooks from partner systems. Access is controlled with an API key, and the operations are documented for your developers. New integration work should use the current version (v2).

Will my integration break when Tai updates the API?

Changes within a version are additive only, so existing fields and behavior stay the same, and a change that would break existing integrations is released as a new version instead. The exception is operations that Tai has announced for retirement: older operations from the original version are being removed or switched off in stages, and some v2 operations are marked deprecated. If your integration calls one of those, plan to move to the current v2 operations.

Why am I getting a "not found" response saying an API has been fully deprecated?

In the Tai TMS public API, some older operations from the original version — the accessorial list, shipment documents, and ZIP-code lookup operations — are being switched off in stages. When one has been switched off, calling it returns a "not found" response with a message that the operation is fully deprecated and that you should move to the updated v2 operations. Update your integration to use the equivalent v2 operations.

Which older API operations have been removed or are being retired?

Most of the original (v1) public API operations — including the older shipment booking, shipment status, status-setting, and document-upload operations — have been removed, and the older accessorial-list, shipment-documents, and ZIP-code lookup operations are being switched off in stages. The original rate-quote operations remain available. Separately, a group of v2 operations is marked deprecated in the API documentation — still working, but pending end of life — and the documentation points developers to newer operations.

Can the Tai TMS post my available loads to load boards?

Yes. Load boards are one of the Tai TMS integration categories. The system can post your available freight to the boards your organization has connected, and it can also update (repost) and remove those postings. Which specific boards are available depends on the integrations your organization has configured.

Does the Tai TMS connect to accounting and payment systems?

Yes. The Tai TMS integrates with accounting systems to sync invoices, bills, and financial records, and with payment and settlement services (including credit-card processing and carrier-payment services) to handle customer and carrier payments. It also works with factoring companies so carrier invoices and payments are routed correctly. The specific systems available depend on your organization's configured integrations.

Is every carrier and vendor supported?

Not necessarily. The Tai TMS supports a broad set of carriers, load boards, tracking providers, accounting systems, and payment/fuel/factoring services, and the catalog grows over time, but it does not connect to every possible vendor. Whether a particular provider is available depends on the current integration catalog and what your organization has enabled.

How does tracking data get into the Tai TMS?

For tracking, the Tai TMS pulls the latest status and milestone dates from the carrier or visibility provider when an update is needed, then normalizes it into the standard Tai statuses. Because it is pull-based, the status you see reflects the most recent pull rather than a continuous live feed.

How is access to the public API secured?

Access to the Tai TMS public API is controlled with an API key issued to you. A request without a valid key is rejected as unauthorized. This keeps your data accessible to your authorized integrations while blocking unauthenticated access.

Are there limits on how many public-API requests I can make?

Yes. The Tai TMS public API tracks requests per organization and per API key against limits for per-minute, per-day, and per-month windows (fixed calendar periods, with the day and month following UTC dates). Tai chooses and manages the limits, and a window with no limit set is unlimited. At present, usage above a limit is recorded and flagged for Tai to review rather than being automatically rejected, but you should keep your integration within its allotment, avoid large bursts, and contact Tai if you expect to need higher volumes.

Can I manage driver tracking through the public API?

Yes. A newer area of the public API (v2) lets your own system manage a shipment's driver-tracking session — starting, updating, refreshing, canceling, retrieving, and sending a message to it — in addition to the core operations for quoting, booking, tracking, invoicing, and working with customers, carriers, and organizations. A shipment can have only one session at a time, and update, refresh, and message calls work only while the session is still active. New areas like this are added under a newer API version so existing integrations keep working unchanged.

Can I clear an invoice or bill variance through the public API?

Yes. The v2 accounting operations include clearing a bill's variance (buy side) and a shipment's invoice variance (sell side). Clearing moves the affected charge lines from variance back to ready without changing any amounts, requires the matching accounting permissions on the API key's user, and returns an error if nothing is currently in variance.