This functionality is available on all plans.

Once you configure a trading partner, Stedi automatically parses and validates inbound EDI files in real time.

After Stedi successfully parses a file, you can review the transaction data manually in the UI or configure a Destination webhook to automatically forward it to an API endpoint.

Generate test files

You can upload inbound test files to simulate receiving a file from your trading partner. This can be useful for testing your downstream integration, since the inbound file will trigger any configured webhook.

When creating your test file, include T in the Usage element of the ISA header to indicate that the file is a test file and should not be processed by your downstream integration. If you have configured a Destination webhook, this ensures it will include “mode”: “test” in the payload.

To process an inbound test file:

  1. Go to the File executions page.
  2. Drag and drop a test EDI file onto the browser window or click Upload EDI and select a test EDI file from your computer.

Stedi automatically processes the file. The processed test file will appear in File Executions, and any transactions parsed successfully will appear in Transactions.

Inbound processing flow

Stedi automatically processes all new files that arrive over a partnership’s connections.

When a new EDI file arrives over a connection, Stedi automatically:

  1. Confirms that the information in the file’s ISA headers matches the corresponding partnership. If not, the file will error, and you can retry after creating the required configuration.
  2. Identifies all available transaction sets in the file and validates them against the transaction settings for the partnership, either using the specified guide or the base X12 specification.
  3. Translates the EDI transaction into Guide JSON, using the JSON Schema defined by the guide.
  4. Persists the original EDI file and the Guide JSON for review and retrieval. Files are retained for 10 years.
  5. Displays the transaction set data in the UI for inspection.

Send transactions to destinations

Stedi can deliver transactions and other events to any API endpoint using a Destination webhook. For example, you can configure a destination that automatically sends inbound transactions to an API endpoint, or you can configure a destination that sends a notification to a ticketing system when a file fails to parse.

The transaction.processed.v2 event contains a URL that you can use to fetch processed transaction data from Stedi.

Other file types

Stedi can also route non-EDI formats like CSV, JSON, and XML for further processing. When a non-EDI file arrives, the file will appear in the UI, and Stedi will emit an event that contains a summary of the file execution. This event can be used to trigger additional processing.

How Stedi processes non-EDI files depends on the file extension:

  • Stedi emits a file.processed.v2 event for all files with .json, .csv, .xml, .xls, .xlsx or .pdf file extensions, which can be used to trigger additional processing.
  • Stedi attempts to process any other file extension, such as .txt or .edi, as EDI. If parsing fails, it attempts to parse the file first as JSON and then as CSV. If parsing still fails, it will mark the execution as failed and emit a file.failed.v2 event, which can be used to trigger additional processing.

Limits

Stedi can process EDI files that are gigabytes in size, and there is no hard restriction on the maximum file size you can attempt to process. If you run into issues processing a large file, please reach out and our engineers will help remove any limitations that you’re encountering.

Was this page helpful?