Accounting API Integration

Tai exposes an accounting sync surface designed around a middleware model: the third-party integrator (an ERP connector, an in-house sync service, a factoring platform) sits between Tai and the target accounting system, consumes Tai's Public API, and pushes records into the target system. The third party owns both directions of data flow and is responsible for closing the loop back to Tai on every record it touches.

• Version: v2
• Base URL: https://{sitecode}.taicloud.net — replace {sitecode} with your Tai site code (the subdomain assigned to your brokerage; check with your Tai administrator or look at the URL you use to log into Tai).
• Auth: x-api-key header on every request — pass your Tai-issued API key as the value. See the API Reference for the full request-header contract.

Six record types

Regardless of which accounting system is on the other side, the same set of records move between Tai and the third-party system — four transactional types and two master-data types that the transactional records reference.

Transactional (accounting activity):

• AP records — Bills (money the broker owes to vendors/carriers).
• AR records — Invoices (money owed to the broker by customers).
• AP payment records — Bill Payments (checks/ACH the broker sent to vendors).
• AR payment records — Invoice Payments (customer remittances applied against the broker's invoices).

Master data (the entities transactions reference):

• Customer records — Customer organizations that receive invoices.
• Carrier / Vendor records — Carriers and vendors that get billed and paid.

Each type flows in both directions: outbound when Tai is the source of truth, inbound when the target system is the source of truth. Master-data flows follow the same pattern as transactional flows but skip the sync-status close-the-loop step and the per-shipment activity log fallback (those apply only to accounting records tied to shipments).

Workflow patterns

Regardless of record type or direction, every sync follows one of two patterns. Learn these two, and the child docs become variations on a theme.

Pattern A · Outbound — Records flowing from Tai to the third party

Used for all four record types when Tai is the source of truth — AP, AR, AP Payments, AR Payments.

1. Record leaves Tai. Tai fires a webhook on create (available for Bills and Invoices), and/or the third party polls a GET batch endpoint filtered by SyncStatus=None as backup or as the primary channel for Payments.
2. Third party pushes to the target system. Middleware receives the Tai payload and attempts to write it into the destination (SAP, QuickBooks, custom ERP, factor platform, etc.).
3. Report the outcome to Tai. PUT /Sync stamps the Tai record with Status=Complete + the target system's TransactionId, or Status=Failed + a datetime stamp. This removes the record from the batch queue.
4. Write a human-readable log. POST /ShipmentActivityLogs writes the outcome to the shipment: on success the target TransactionId; on failure the exact error text. Tai users see this inline on the shipment.

Full outbound details: Outbound Data Transmission.

Pattern B · Inbound — Records flowing from the third party into Tai

Used when the target system is the source of truth — Bills (via Approve), Invoices, Bill Payments, or Invoice Payments generated in the third-party system and pushed into Tai.

1. Third party POSTs the record to Tai. Middleware calls the create/approve endpoint with the record body.
2. Tai returns the new Tai-side ID. Response includes the newly-assigned BillId, InvoiceId, BillPaymentId, or InvoicePaymentId. Store it locally.
3. Cross-reference the two systems. PUT /Sync stamps the Tai record with the third-party system's TransactionId, so both sides can look each other up later.
4. Write a human-readable log. POST /ShipmentActivityLogs logs the creation on the shipment.

Full inbound details: Inbound Data Transmissions.

Choose your delivery cadence

For the outbound direction (Pattern A), the third party has two viable strategies. Both use the same endpoints — the difference is only when they're called.

Option 1 (Recommended) — Webhooks live + end-of-day batch as safety net

Register the webhook endpoints for Bills and Invoices to receive records the instant they're created in Tai — near-real-time sync. Then run a nightly (or hourly) GET ?SyncStatus=None to catch anything the webhook didn't deliver (endpoint offline, network hiccup, integration briefly paused). Best of both worlds: fastest sync in the common case, guaranteed delivery in the failure case.

Option 2 (Simpler) — Batch only

Skip webhook registration entirely and just poll the GET ?SyncStatus=None endpoints on a schedule (every 15 minutes, hourly, nightly — whatever the target system's tolerance allows). Simpler to build and operate — no public HTTPS endpoint to host, no webhook-signature verification, no retry logic.

Trade-off: records are stale by up to one poll interval, and volume per pull is proportional to how long you wait between polls.

Shared operations

Two operations are used by every record type in both directions. They get their own docs so the child pages can link back instead of repeating themselves:

• Sync Status Updates — how you tell Tai "I got the record, here's what happened." The mechanism that keeps the batch queue clean.
• Shipment Activity Logs — the human-readable audit trail that Tai users watch when something goes wrong.

Where to go next

• Outbound Data Transmission — records leaving Tai.
• Inbound Data Transmissions — records being pushed into Tai.