Plex and Tradeshift integration

What moves between them

The main flow moves from Plex into Tradeshift. Purchase orders and supplier invoices from Plex are translated into Tradeshift invoices and receipt documents and posted to the Plex suppliers' corresponding Tradeshift network connections. Once invoiced and matched in Tradeshift, matched invoices and remittance advice flow back into Plex to validate GL account mappings and post labor cost and material expense journals. Reference data such as suppliers, cost centers, and GL accounts are aligned in both directions so AP allocations land on valid Plex financial dimensions. Reconciliation data from Tradeshift is read-only in Plex, so ml-connector posts GL entries but does not modify them after creation.

How ml-connector handles it

ml-connector stores both OAuth credential sets encrypted and refreshes Plex bearer tokens when a REST call returns 401, and similarly refreshes Tradeshift tokens when needed. On each side, it polls on a configurable interval (typically 5-15 minutes) using modified_date filters to discover new and changed records without re-scanning history. Plex suppliers are matched to Tradeshift network connections by name or supplier code, and Plex GL accounts are translated into Tradeshift UBL line-item dimensions so AP entries land on valid cost centers and expense accounts. Because both Plex and Tradeshift are poll-based with no outbound webhooks, ml-connector uses exponential backoff on Plex HTTP 429 responses and handles Tradeshift's requirement for the X-Tradeshift-TenantId header on every request. Every record carries a full audit trail, so a failed downstream GL posting can be replayed once the root cause is fixed.

A real-world example

A mid-sized discrete manufacturer runs Plex ERP for production and finance across two plants and uses Tradeshift to manage supplier invoicing and AP automation with its 300+ suppliers. Before the integration, the procurement team received purchase orders from Plex, manually entered them into Tradeshift for matching, and then exported matched invoices from Tradeshift and re-entered payment details and GL allocations into Plex by hand. With Plex and Tradeshift connected, each new purchase order from Plex flows automatically into Tradeshift for matching, matched invoices come back into Plex with supplier confirmations intact, and the manual re-entry step is eliminated. Month-end AP close starts with invoices already matched and GL-allocated.

What you can do

• •Send Plex purchase orders and supplier invoices to Tradeshift as structured UBL documents, matched to the correct supplier network connections.
• •Receive matched invoices and remittance advice from Tradeshift and post them into Plex GL accounts for reconciliation.
• •Map Plex suppliers to Tradeshift network connections and Plex GL accounts to Tradeshift UBL line-item dimensions.
• •Poll both Plex and Tradeshift on a configurable schedule, with exponential backoff and retries on rate limits.
• •Maintain a full audit trail on every record so failed GL postings can be replayed or rolled back.

Questions

How does the integration handle Plex and Tradeshift's different authentication schemes?

ml-connector manages both OAuth credential sets separately. Plex uses OAuth 2.0 bearer tokens, which are refreshed when a call returns 401. Tradeshift uses OAuth 1.0a (two-legged) plus a required X-Tradeshift-TenantId header on every request. Both credentials are stored encrypted, and ml-connector handles the refresh cycle automatically.

Which direction does data move between Plex and Tradeshift?

The main flow is Plex into Tradeshift. Purchase orders and invoices from Plex are posted to Tradeshift for AP matching. Once matched, invoices and remittance advice flow back into Plex for GL posting and reconciliation. Suppliers and GL accounts are aligned in both directions.

How does polling work when neither Plex nor Tradeshift has native webhooks?

ml-connector polls both systems on a configurable interval (typically 5-15 minutes) using modified_date or changedAfter filters to find new and changed records efficiently. Because Plex rate limits are not public, ml-connector implements exponential backoff on HTTP 429 to avoid overloading the systems.