This functionality is available on all plans.

Stedi emits events as it processes and generates EDI files. You can use these events to trigger Destination webhooks that forward processed transaction data, to trigger alerts in systems like Slack or PagerDuty, and to implement more advanced functionality.

Event types

Stedi emits the following types of events.

Transaction processed

The transaction.processed.v2 event is the primary integration point for transactions you receive from your trading partner. Stedi emits one transaction.processed.v2 event for every transaction successfully processed.

Since an EDI file can contain multiple transactions, a single EDI file can result in multiple transaction.processed.v2 events.

You use the transaction.processed.v2 event slightly differently depending on whether you are using Destination webhooks or Functions.

  • When you receive a transaction.processed.v2 event through a Destination webhook, the payload includes an event object that contains the event data, as well as an artifact object that contains the actual transaction payload.
  • Functions event bindings receive only the event data, but you can use the URLs provided in the event to retrieve the transaction payloads from inside the function.

Retrieve transaction data

You can use the URLs in the event.detail.artifacts objects to fetch transaction data from Stedi. You may need to do this if the output is larger than 1MB or if you are using Stedi function event bindings.

  • Use the URL in the artifact with "usage": "input" to fetch the input for the transaction. For inbound transactions, this is the EDI you received from your trading partner.
  • Use the URL in the artfiact with "usage": "output" to fetch the output for the transaction. For inbound transactions, this is processed transaction data in Guide JSON format.

To retrieve transaction data, make a request with the URL and your Stedi API key for authorization.

If your HTTP library automatically follows redirects, you will receive the transaction data in the response body. If it does not follow redirects, the response includes a documentDownloadUrl that you can use to retrieve the transaction data.

The following example shows a cURL request to retrieve transaction data. This example uses the -L option for following redirects.

curl -L -H "Authorization: Key $STEDI_API_KEY" \$TRANSACTION_ID/output

File processed

You may want to consume file.processed.v2 events when you want to route non-EDI files that arrive on Stedi for additional processing.

Stedi emits a file.processed.v2 event for all successful file executions. You can view details on the File Executions page.

For files with the following extensions, Stedi emits a file.processed.v2 event, but does not attempt to parse them as EDI: .json, .csv, .xml, .xls, .xlsx or .pdf file extensions.

File delivered

Core emits the file.delivered.v2 event every time a file is successfully delivered to a connection for an outbound transaction set. This event is only emitted for generated EDI (outbound) files, and is not emitted for inbound files.

File failed

Core emits file.failed.v2 events in two scenarios:

  • When a failure occurs while processing an inbound file. Stedi emits the file.failed.v2 event at the file level. If a single transaction set fails, the entire file fails.
  • When am outbound file cannot be delivered to a configured connection.

When are events emitted?

Stedi emits events in the following scenarios.

An entire file has successfully processed

Consider an EDI file that contains two functional groups, and a total of three transaction sets. When Stedi successfully processes all transaction sets, it generates a total of six events:

  • 1x file.processed.v2 - indicating the entire file was processed successfully.
  • 3x transaction.processed.v2 - one event for each transaction set found in both groups.

X12 File where all Transaction Sets are processed successfully

At least one transaction fails to validate

If one or more transaction sets in a file fails validation, Stedi emits a single file.failed.v2 error, indicating that one or more transactions failed to process. Stedi cannot process the entire file until you address those issues.

X12 File where one Transaction Set fails validation, blocking the entire file

Event structure

All Stedi events follow a standard JSON Schema. The event payload itself does not include the contents of a given file or transaction. Instead, it references an API path to retrieve the entire object.

JSON event structure example
  "id": "xxx-05d4-b198-2fde-7ededc63b103",
  "detail-type": "transaction.processed.v2",
  "source": "stedi.core",
  "time": "2021-11-12T00:00:00Z",
  "detail": { ... }

In addition to their version, id, and time, events have the following fields:

  • detail-type - Indicates the type of event, such as transaction.processed.v2 or file.failed.v2
  • source - Indicates the component that generated the event. All Core events use source: “stedi.core”.
  • detail - The JSON payload. The schema for each payload is determined by the detail-type.

Event levels

Stedi events are split into two different levels, each representing a different level of granularity. Events are also categorized by their result states, representing success or failure during processing.

  1. file: Events with information about a file that has been detected. File events contain summary information about the data type in the file, like X12 EDI, JSON, CSV, XML, etc.
  2. transaction: Events with information about a single transaction within an X12 EDI file.

Event categories

  1. processed: Events are emitted for each event level, but only when Stedi has processed the entire file successfully.
  2. failed: Events are only emitted at the file level because Stedi stops processing a file immediately when it finds an invalid transaction set.