.png)
Tradeshift Integration Guide
Connect Tradeshift invoicing, procurement, supplier, and document workflows with enterprise systems through REST APIs, OAuth authorization, and selected event notifications.
Tradeshift integration options at a glance
Tradeshift primarily integrates with enterprise systems through REST and platform APIs secured with OAuth-style authorization and access tokens. These APIs can support business document submission, invoice and purchase-order retrieval, status queries, company information, and permitted document content or attachments. Tradeshift also supports webhook-style notifications for selected platform activities, although event coverage depends on the product and tenant. Document workflows may be asynchronous, so status polling and reconciliation can be required. Martini can consume the APIs, receive supported notifications through a Martini API, transform JSON or XML payloads, manage workflow state, and route results to downstream systems.
| Integration point | Supported by Tradeshift? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Submit business documents, retrieve Invoices and Purchase Orders, query status, access Companies or supplier information, and retrieve permitted document content. | Martini can consume Tradeshift REST APIs from workflows, transform requests and responses, expose an abstraction API, and persist synchronization state. |
| Webhooks and outbound callbacks | Limited | Receive notifications for selected Tradeshift platform activities or document state changes where the relevant product and tenant support them. | Martini can expose an API to receive notifications, validate and deduplicate requests, retrieve authoritative resources, and invoke downstream workflows. |
| Bulk, asynchronous, and batch processing | Limited | Support document-oriented submissions and asynchronous processing where a product-specific API provides batch, job, or status operations. | Martini can orchestrate submissions, poll status endpoints, model intermediate states, and apply controlled retries; a universal Tradeshift bulk API is not confirmed. |
| File and attachment APIs | Limited | Process structured business documents and associated invoice or document files where the applicable Tradeshift API exposes attachment operations. | Martini can transform JSON, XML, or file-based source data, call document or attachment endpoints, and route returned content to downstream systems. |
| Authentication | Yes | Authorize applications through OAuth-style flows, access tokens, scopes, permissions, and tenant or company context. | Martini can store client credentials and tokens in environment-specific secrets and use configured authentication when consuming Tradeshift APIs. |
| Scheduled synchronization | Yes | Reconcile Invoices, Purchase Orders, Companies, Users, or Documents through recurring retrieval and status checks when event coverage is incomplete. | Martini workflows can run on schedules, maintain cursors or high-water marks, compare source and target state, and retry transient failures. |
| Database and analytics access | Not confirmed | Direct access to Tradeshift-managed production data was not confirmed; supported APIs, exports, reports, or other vendor interfaces should be used instead. | Martini can integrate with supported APIs and downstream databases without requiring direct access to Tradeshift-managed storage. |
How Tradeshift exposes data and business events
Tradeshift REST APIs
REST is Tradeshift's primary confirmed integration mechanism. It can support business document submission, invoice and purchase-order retrieval, status queries, company information, and permitted document or attachment access. Available operations depend on the applicable product, tenant, and permissions.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates against Tradeshift, calls the required endpoint, validates the response, maps the payload into a canonical model, applies business rules, and writes the result to a downstream application or state store.
Implementation sequence
Tradeshift Webhook Notifications
Tradeshift supports webhook-style or event-driven notifications for selected platform activities. Event coverage, delivery format, retry behavior, signature validation, and subscription configuration must be confirmed for the relevant product and tenant.
Martini implementation pattern
Martini implementation pattern: a Martini API receives the notification, validates the request, checks for duplicates, and invokes a workflow that retrieves the authoritative Invoice, Document, or status from Tradeshift before downstream processing.
Implementation sequence
Tradeshift Asynchronous Document Processing
Tradeshift document workflows may be asynchronous, meaning acceptance of a submission may precede validation, routing, or final business processing. A general-purpose bulk API for all objects was not confirmed.
Martini implementation pattern
Martini implementation pattern: a workflow submits the document, stores the submission and correlation identifiers, polls a supported status endpoint or consumes a selected event, and routes terminal failures to an exception process.
Implementation sequence
Tradeshift Files and Attachments
Invoices and other business documents can include structured data and associated files or attachments. Exact attachment endpoints, formats, permissions, and size limits depend on the applicable Tradeshift API.
Martini implementation pattern
Martini implementation pattern: a workflow receives or retrieves structured data and files, validates formats and required relationships, transforms the content as needed, and sends or stores each component while preserving the Tradeshift document identifier.
Implementation sequence
Tradeshift OAuth Authentication
Tradeshift integrations generally use OAuth 2.0-style authorization and access tokens. Required scopes, tenant or company context, permissions, token lifetimes, and authorization flows depend on the API and deployment model.
Martini implementation pattern
Martini implementation pattern: credentials are kept in environment-specific secrets, the workflow obtains or uses an access token, supplies the required context, and separates authorization failures from transient API errors.
Implementation sequence
Common Tradeshift integration patterns
Pattern 1: Synchronize Tradeshift invoices with an ERP
When to use this pattern
Use this pattern when finance teams need recurring synchronization of Tradeshift Invoices into SAP S/4HANA, Oracle NetSuite, Workday, or another accounting platform. It combines incremental retrieval with validation, duplicate prevention, and reconciliation.
Integration direction
Example Mapping
| Tradeshift Field | Canonical Field | Target Field |
|---|---|---|
| invoiceId | sourceDocumentId | ExternalInvoiceId |
| invoiceNumber | invoiceNumber | SupplierInvoiceNumber |
| lineItems | invoiceLines | InvoiceItems |
| totalAmount | grossAmount | GrossAmount |
Martini implementation pattern
A scheduled Martini workflow retrieves changed Invoices using the endpoint's supported pagination or filter model, maps tax, currency, parties, lines, and totals into the ERP structure, validates mandatory fields, checks the source-to-target identifier mapping, and submits only eligible invoices. Transient failures are retried with backoff, while validation and duplicate errors are recorded for review and reconciliation.
Martini capabilities used
- workflows
- API consumption
- scheduling
- data mapping
- business rules
- error handling
Pattern 2: Match Tradeshift purchase orders and invoices
When to use this pattern
Use this pattern when procurement or finance processes require comparison of Tradeshift Purchase Orders and Invoices before posting or approval. It is useful for identifying missing orders, supplier mismatches, quantity differences, and total or tax variances.
Integration direction
Example Mapping
| Tradeshift Field | Canonical Field | Target Field |
|---|---|---|
| purchaseOrderId | purchaseOrderNumber | PurchaseOrder |
| supplier.companyId | supplierId | VendorId |
| lineItems[].quantity | orderedQuantity | OrderQuantity |
| totalAmount | invoiceTotal | InvoiceAmount |
Martini implementation pattern
Martini retrieves related Purchase Orders and Invoices, normalizes supplier identifiers, line items, currencies, tax values, and totals, then applies configurable tolerance and relationship rules. Matched documents continue to the ERP, while missing orders or mismatches are routed to an exception queue or exposed through an API with correlation identifiers.
Martini capabilities used
- workflow orchestration
- API consumption
- data mapping
- business rules
- validation
- exception handling
Pattern 3: Process event-driven Tradeshift documents
When to use this pattern
Use this pattern when the relevant Tradeshift tenant provides notifications for a document or status activity and downstream processing should begin without waiting for the next scheduled poll. Polling remains useful for reconciliation and events without coverage.
Integration direction
Example Mapping
| Tradeshift Field | Canonical Field | Target Field |
|---|---|---|
| event.documentId | sourceDocumentId | u_tradeshift_document_id |
| event.status | documentStatus | u_document_status |
| event.eventId | notificationId | correlation_id |
Martini implementation pattern
A Martini API receives the notification, validates the request, checks event or document idempotency, and retrieves the authoritative Document or Invoice from Tradeshift. Business rules determine whether to continue, update downstream status, or create a ServiceNow exception. The workflow records the notification and supports recovery through scheduled reconciliation.
Martini capabilities used
- API exposure
- webhook consumption
- workflow orchestration
- deduplication
- business rules
- monitoring
Pattern 4: Synchronize Tradeshift companies and suppliers
When to use this pattern
Use this pattern when master data must be aligned between Tradeshift Companies or Users and an enterprise application such as Salesforce, Workday, or SAP S/4HANA. The flow should distinguish creation, update, deactivation, and relationship changes.
Integration direction
Example Mapping
| Tradeshift Field | Canonical Field | Target Field |
|---|---|---|
| companyId | externalOrganizationId | SupplierReference |
| name | organizationName | SupplierName |
| users | associatedUsers | Contacts |
| status | organizationStatus | SupplierStatus |
Martini implementation pattern
A scheduled workflow retrieves changed Companies and permitted Users, applies tenant and company-context rules, maps them to the target master-data model, and checks existing external identifiers before creating or updating records. Invalid relationships and authorization issues are isolated from valid changes, with durable state supporting restart and reconciliation.
Martini capabilities used
- workflows
- scheduling
- API consumption
- data mapping
- state management
- error handling
Applications commonly integrated with Tradeshift
Tradeshift can be connected to adjacent enterprise applications when procurement, supplier, invoicing, document exchange, or exception processes span multiple systems. These relationships are implementation patterns rather than confirmation of productized partnerships or native connectors.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| SAP S/4HANA | Synchronize suppliers, purchase orders, invoices, tax data, and payment status between SAP and Tradeshift. | SAP S/4HANA → Martini → Tradeshift | Martini orchestrates bidirectional REST-based workflows, maps SAP procurement and finance structures to Tradeshift documents, validates mandatory fields, stores source-to-target identifiers, and routes rejected or unmatched documents for review. |
| Oracle NetSuite | Send supplier and purchasing data to Tradeshift and return electronic invoice data for accounts-payable processing. | Oracle NetSuite → Martini → Tradeshift | Scheduled or event-assisted workflows retrieve NetSuite data, transform it to Tradeshift document structures, submit eligible documents, poll processing status where needed, and write accepted or rejected results back to NetSuite. |
| Coupa | Exchange procurement documents and invoice information when Coupa manages purchasing and Tradeshift supports supplier or invoicing workflows. | Coupa → Martini → Tradeshift | Martini normalizes Coupa purchase orders and Tradeshift invoices into a canonical procurement model, applies document ownership and matching rules, and sends exceptions to an operational workflow. |
| SAP Ariba | Coordinate supplier, procurement, and invoicing data across procurement networks. | SAP Ariba → Martini → Tradeshift | Martini consumes available APIs from both systems, maps supplier and document identifiers, coordinates submission and status updates, and uses durable state to prevent duplicate document creation. |
| Salesforce | Synchronize company, supplier, or commercial relationship information with Tradeshift-related processes and selected status updates. | Salesforce → Martini → Tradeshift | A Martini workflow retrieves Salesforce account or relationship data, maps it to Tradeshift Companies or Users where appropriate, and exposes selected Tradeshift status results through an API or Salesforce update flow. |
| Workday | Synchronize supplier or financial-process data with Tradeshift invoice and procurement workflows. | Workday → Martini → Tradeshift | Martini coordinates Workday and Tradeshift API calls, transforms supplier and invoice fields, applies company-context rules, and records processing outcomes for finance reconciliation. |
| ServiceNow | Route invoice, supplier, or integration exceptions into service-management workflows and return resolution status. | Tradeshift → Martini → ServiceNow | Martini receives rejected or unmatched document outcomes, creates or updates ServiceNow cases through its APIs, correlates case and document identifiers, and sends resolution updates back to the relevant workflow. |
How to build a Tradeshift integration in Martini
Objective
Establish the Tradeshift API connection with the required OAuth application, scopes, permissions, and tenant or company context.
Instructions in Martini
- Configure the applicable Tradeshift API endpoint and authorization flow.
- Store OAuth client credentials and tokens in environment-specific Martini secrets.
- Confirm permissions, scopes, token expiry, and non-production versus production credentials.
Objective
Select an event-driven, scheduled, or API-led entry point based on the Tradeshift process and its available event coverage.
Instructions in Martini
- Use a Martini API for supported Tradeshift notifications or inbound requests.
- Use a scheduler for incremental retrieval, status polling, and reconciliation.
- Document which object states are event-driven and which require polling.
Objective
Obtain the authoritative Tradeshift resource rather than relying solely on a notification or partial submission response.
Instructions in Martini
- Receive and validate supported webhook-style notifications.
- Call the relevant REST endpoint for Invoices, Purchase Orders, Companies, Users, Catalogs, or Documents.
- Implement the documented pagination, filtering, cursor, or status-retrieval model.
Objective
Coordinate Tradeshift calls, downstream calls, state management, and business decisions in a maintainable Martini workflow.
Instructions in Martini
- Separate transport, authentication, validation, business, and downstream-processing stages.
- Store correlation identifiers, cursors, submission identifiers, and source-to-target mappings.
- Branch accepted, rejected, pending, duplicate, and retryable outcomes.
Objective
Transform complex procurement and invoicing structures into the canonical and target models required by downstream systems.
Instructions in Martini
- Map parties, line items, tax, currency, totals, payment terms, document types, and attachments explicitly.
- Validate mandatory fields, identifiers, relationships, formats, and business tolerances.
- Use reusable mappings and transformations for related document flows.
Objective
Enforce document ownership, duplicate prevention, matching, tenant context, and routing rules before writing data.
Instructions in Martini
- Check stable invoice, purchase-order, document, or company identifiers before creating targets.
- Apply purchase-order matching and amount or tax tolerance rules where required.
- Route missing suppliers, mismatches, invalid documents, and unsupported states to exceptions.
Common Tradeshift data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Invoices | Exchange electronic invoices containing headers, line items, tax information, totals, payment terms, and status. | SAP S/4HANA, Oracle NetSuite, Workday, Coupa | Martini validates invoice structure, maps tax and currency fields, applies duplicate checks, submits or retrieves invoices, and records processing status. |
| Purchase Orders | Represent buyer-originated purchasing documents sent to suppliers. | SAP S/4HANA, Coupa, SAP Ariba, Oracle NetSuite | Martini maps order headers, supplier identifiers, lines, quantities, and totals, then coordinates submission, retrieval, matching, and exception handling. |
| Companies | Represent buyers, suppliers, and other organizations participating in the Tradeshift network. | SAP S/4HANA, Salesforce, Workday, Oracle NetSuite | Martini synchronizes company data using stable identifiers, distinguishes creation and update flows, and applies tenant or company-context rules. |
| Users | Represent individuals associated with companies, accounts, or platform access. | Salesforce, Workday, identity and access processes | Martini retrieves permitted user information, maps account relationships and status fields, and applies environment-specific access and privacy rules. |
| Catalogs | Provide product and service information used in procurement processes. | Coupa, SAP Ariba, SAP S/4HANA, Oracle NetSuite | Martini transforms catalog items, supplier references, pricing, and classification fields and routes changes to procurement applications. |
| Documents | Represent business documents exchanged through Tradeshift, including invoices, purchase orders, credit notes, and related documents. | ERP, procurement, finance, document-management applications | Martini uses document identifiers and types for routing, retrieves authoritative content, handles attachments where exposed, and tracks lifecycle state. |
Authentication and security considerations
OAuth and environment isolation
Tradeshift integrations generally use OAuth 2.0-style authorization and access tokens. Required scopes, permissions, token lifetimes, and tenant or company context depend on the applicable API and deployment model.
- Store client credentials, tokens, refresh credentials, and notification-validation secrets in protected Martini secrets.
- Use separate credentials and endpoint configuration for development, testing, and production.
- Plan for token expiration, credential rotation, revoked authorization, and least-privilege scopes.
- Do not assume that an access token alone selects the correct company or business context.
Operational considerations for Tradeshift integrations
Reliability and document processing
Tradeshift document workflows may be asynchronous, and event coverage is limited to documented product and tenant capabilities.
- Implement endpoint-specific pagination, filtering, cursors, or high-water marks for incremental retrieval.
- Confirm tenant-specific rate limits, request sizes, attachment limits, and asynchronous status behavior.
- Use stable identifiers and source-to-target mappings to prevent duplicate invoices and documents.
- Retry transient transport and throttling failures with backoff, but route validation and authorization errors for correction.
- Test complex tax, currency, line-item, party, payment-term, and attachment structures before production release.
- Run scheduled reconciliation to identify missed callbacks, partial failures, rejected documents, and downstream discrepancies.
- Monitor schema changes and preserve Tradeshift correlation or document identifiers in logs.
Why use Martini instead of scripts or point-to-point integrations?
Maintainable integration orchestration
Direct scripts can become difficult to operate when Tradeshift document lifecycles, asynchronous status changes, authentication, and multiple downstream systems must be coordinated.
- Martini centralizes REST API consumption, OAuth configuration, workflow orchestration, mappings, validation, and business rules.
- Reusable workflows and APIs reduce duplicated logic across invoices, purchase orders, companies, and documents.
- Event-driven processing can be combined with scheduled polling and reconciliation for more reliable operations.
- Durable state, structured error handling, retries, logs, and correlation identifiers support recovery and troubleshooting.
- Martini can expose controlled APIs that abstract Tradeshift-specific payloads from downstream applications.
Frequently asked questions
Tradeshift can be integrated primarily through REST and platform APIs secured with OAuth-style authorization. Enterprise workflows can submit and retrieve Invoices, Purchase Orders, Companies, Users, Catalogs, and Documents, query status, and process permitted document content or attachments. Selected Tradeshift activities may also produce webhook-style notifications, while scheduled polling and reconciliation can cover processes without event support.
Yes. Martini can integrate with Tradeshift by consuming its REST APIs, using OAuth-based authentication, receiving supported webhook-style notifications through Martini APIs, transforming document data, and orchestrating downstream workflows. A Martini-native Tradeshift connector is not documented in the supplied materials.
No. A dedicated Tradeshift connector is not required. Martini can use Tradeshift's confirmed native integration mechanisms, including REST APIs, OAuth authorization, selected webhook-style notifications, and applicable document or attachment endpoints.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Tradeshift with Martini. Integrations are subject to the provisioned capacity of the Martini environment. Separate costs may apply from Tradeshift, cloud infrastructure, or other third-party systems depending on subscription, usage, and deployment model.
REST APIs are the primary confirmed method for new Tradeshift integrations. OAuth-style authorization should be configured with the required scopes and tenant or company context. Selected webhook-style notifications, scheduled retrieval, status polling, and product-specific document or attachment operations can complement the REST integration. GraphQL and current SOAP APIs were not confirmed.
Tradeshift supports webhook-style or event-driven notifications for selected platform activities, but coverage should not be assumed for every object or state transition. The event types, delivery format, retry behavior, validation requirements, and subscription model should be confirmed for the relevant product and tenant. Polling and reconciliation may still be necessary.
Martini can use scheduled workflows, supported filters, modification timestamps, pagination, or cursors to retrieve changed Tradeshift objects. It can store high-water marks and source-to-target identifier mappings, transform payloads into canonical models, and reconcile submitted, accepted, rejected, and downstream results. Event-driven processing can be combined with polling for recovery.
Martini can separate transport, authentication, validation, duplicate, throttling, and business-status failures. Stable invoice, purchase-order, document, or company identifiers can support idempotency, while transient failures can use controlled retries and backoff. Correlation identifiers and durable workflow state support troubleshooting, reconciliation, and safe restart. Martini can also expose an API façade that hides Tradeshift-specific details from downstream applications.
Related Martini documentation
APIs
Workflows
Connect Tradeshift with your enterprise systems
Use Martini to build maintainable Tradeshift integrations that combine REST APIs, selected event notifications, document transformation, workflow orchestration, and operational controls.