Tediware
Sign In

Overview

Tediware handles EDI translation and delivery between your system and your trading partners. You configure partners, connections, and document types in the Tediware application. Your system then uses the Platform API and webhooks to exchange data – submitting documents for translation, receiving notifications when processing completes, and retrieving the results.

This page explains how the pieces fit together before you dive into the individual endpoints.

How It Works

Tediware sits between your system and your trading partners. EDI documents flow in two directions:

  • Inbound – a trading partner sends EDI to you. Tediware receives it, translates it to JSON, and notifies your system via a webhook. Your system then fetches the translated JSON through the API.
  • Outbound – your system sends JSON data to Tediware. Tediware translates it to EDI and delivers it to the trading partner’s connection (SFTP, AS2, etc.). Your system is notified of the outcome via a webhook.

In both directions, the pattern is the same: Tediware does the heavy lifting of translation and delivery, and your system interacts through a combination of API calls and webhook notifications.

Webhooks are notifications, not data delivery. Tediware’s webhooks send a lightweight payload containing only a resultId and traceGuid – they never include document content. Your system receives the notification, then pulls the full data through the Results and Artifacts API at its own pace. This means your webhook endpoint only needs to acknowledge receipt and queue a background job. It avoids payload size limits, lets your system retry fetches independently of webhook delivery, and keeps sensitive business data off the webhook channel.

Receiving EDI from Partners

flowchart TD
  TP["Trading Partner"] -- "1. EDI via SFTP / AS2" --> TW["Tediware"]
  TW -- "2. Webhook notification" --> YOU["Your System"]
  YOU -- "3. Fetch result + artifact" --> TW

Tediware receives EDI from your trading partners automatically. In most integrations, your partner delivers EDI via SFTP or AS2, and Tediware picks it up without any action from your system. SFTP connections are polled on a configurable schedule; AS2 deliveries are processed as they arrive. Your system’s role begins when Tediware fires a webhook to say “a document has been processed.”

For cases where your system receives EDI directly (e.g., from a vendor portal, email, or another protocol), Tediware also provides an API endpoint to push EDI in for processing. See the Inbound EDI page for details on this endpoint.

Regardless of how EDI arrives, the processing sequence is the same:

  1. Tediware parses the EDI, extracts individual transaction sets, and converts each one to JSON
  2. Tediware calls your inbound webhook with a resultId and traceGuid
  3. Your system calls GET /platform/results/:id using the resultId from the webhook payload
  4. The result contains an artifacts array – the artifact with "usage": "output" is the translated JSON
  5. Your system calls GET /platform/artifacts/:id to download the JSON content
  6. Your system processes the JSON data – creating orders, updating records, routing to internal systems, or whatever your business logic requires

From your system’s perspective, the entry point is the webhook. Everything starts when Tediware calls your endpoint to say “a document has been processed.” Your system then pulls the data it needs through the Results and Artifacts API.

Sending EDI to Partners

flowchart TD
  YOU["Your System"] -- "1. JSON via API" --> TW["Tediware"]
  TW -- "2. EDI via SFTP / AS2" --> TP["Trading Partner"]
  TW -- "3. Webhook notification" --> YOU

When your system needs to send an EDI document to a trading partner, it submits JSON data to Tediware. Tediware applies your mapping, generates the EDI, and delivers it.

The full sequence:

  1. Your system calls POST /platform/partners/:key/ts/:code with the transaction data as JSON
  2. The API returns immediately with a traceGuid and the control numbers assigned to the interchange
  3. Tediware applies your mapping and implementation to convert the JSON to EDI, then delivers the EDI file to the partner’s connection
  4. If delivery succeeds, Tediware calls your outbound webhook with a resultId. You can fetch the result to get the generated EDI content and confirm the control numbers.
  5. If processing fails at any step, Tediware calls your error webhook instead. The result’s errorMessage field describes what went wrong.

The traceGuid returned by the API links all results from this processing run. You can store it to correlate the initial submission with the webhook callbacks that follow.

Designing Your Integration

A typical integration has three parts: an API client for submitting data and fetching results, webhook endpoints for receiving notifications, and background processing to handle the data.

Webhook Endpoints

Set up three HTTP endpoints in your application, one for each webhook type:

  • Inbound results – called when EDI from a partner is processed. This is where most of your integration logic lives: fetching the result, downloading the JSON artifact, and processing the translated data.
  • Outbound deliveries – called when EDI you submitted is successfully delivered. Use this to confirm delivery, record control numbers, or update internal status.
  • Errors – called when processing fails in either direction. Use this to log errors, alert your team, or trigger retry logic.

Your webhook endpoints should accept the request and return a 200 response immediately. Perform any processing (fetching results, downloading artifacts, updating your database) asynchronously in a background job. Tediware expects a response within 10 seconds.

Verifying Webhook Authenticity

Every webhook delivery includes an X-Webhook-Signature header that you should verify to confirm the request came from Tediware. The Webhooks page covers the verification process in detail.

Working with Results and Artifacts

When your webhook receives a notification, the payload includes a resultId. Use it to fetch the result, which contains metadata and references to artifacts. The artifacts are the actual files – download the one with "usage": "output" to get the translated content (JSON for inbound documents, EDI for outbound documents).

The Results & Artifacts page covers the API details for fetching results and downloading artifacts.

Storing the Trace

Every processing run produces a traceGuid that links all related results together. Store this value in your system alongside the records you create from the processed data. It is useful for debugging – you can look up the trace in the Tediware UI to see every processing step, or query GET /platform/results?trace=... to retrieve all results programmatically.

Multi-Step Flows

Many EDI workflows involve receiving a document from a partner and sending a response back. Tediware handles each direction through its own flow, and your system ties them together with your business logic.

Example: Responding to a Load Tender

  1. Your carrier partner sends a 204 (Motor Carrier Load Tender) via SFTP or AS2
  2. Tediware processes it and fires your inbound webhook
  3. Your system fetches the translated JSON, reviews the load details, and decides to accept
  4. Your system submits a 990 (Response to Load Tender) via POST /platform/partners/PARTNER_KEY/ts/990 with the acceptance data
  5. Tediware translates it to EDI and delivers it to the partner. Your outbound webhook confirms delivery.

The inbound and outbound steps are independent API operations with separate traces. Your system provides the business logic in between – deciding whether to accept, reject, or counter the tender. Correlate the inbound and outbound traces in your own system if you need to link the original document with the response.

What You Need Before Starting

Before your system can exchange data through the API, the following must be configured in Tediware:

  • A partner with a connection, internal and external envelopes, and at least one transaction setting for the direction you need (inbound, outbound, or both)
  • Active flows built for the partner – these are the processing pipelines that handle translation and delivery
  • Webhooks created and assigned to the partner – at minimum an inbound webhook for receiving data, and ideally an outbound and error webhook as well
  • An API key for your organization – used to authenticate all API requests