Reference · built on requestConnectorInventory, WMS & procurement

Stedi

X12 transactions translated to JSON, file executions, and delivery events from the Stedi EDI platform.

About

Stedi is an EDI platform. You send JSON to Stedi and it generates X12 files and delivers them to your trading partners over Stedi-hosted SFTP/FTPS, remote SFTP/FTPS, or AS2. Files from your trading partners arrive the same way and come back to you as JSON, one transaction at a time. Partnerships hold the connections, the transaction settings, and the 997 or 999 acknowledgments Stedi generates for inbound transactions.

Through Fibric, an operator watches processed transactions and file executions, matches them to the purchase orders and shipments in your ERP or WMS, and proposes an outbound transaction, a retry of a failed delivery, or a chase when an expected document never arrives. You approve. Each send happens once, never twice, and leaves a receipt: what changed, why, and how to undo it.

This is a reference listing. It documents what Fibric would read from Stedi and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • transaction.processed.v2 webhook events, one per transaction in a received file, with download URLs for the translated JSON and the original EDI
  • file.processed.v2, file.delivered.v2, and file.failed.v2 events for inbound processing and outbound delivery outcomes
  • Processed transactions through GET /transactions, filtered by partnershipId, transactionSetId, direction, mode, status, and a from/to time range
  • Poll transactions (GET /polling/transactions) as an alternative to webhooks, ordered by processedAt, with a pageToken that does not expire
  • File executions and their transactions through GET /file-executions and GET /file-executions/{executionId}/transactions
  • Input and output artifacts for a transaction through GET /transactions/{transactionId}/input and /output
  • businessIdentifiers and translationErrors carried on every transaction record

Proposed actions

  • Target capability: propose an outbound transaction through Create Outbound Transaction (POST /partnerships/{partnershipId}/transactions/{transactionSettingId}) from Guide JSON
  • Target capability: propose generating a full interchange through the Outbound interchange endpoint (POST /x12/partnerships/{partnershipId}/generate-edi)
  • Target capability: propose a retry of a failed file execution, or redelivery of failed webhook events through POST /events/retry

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Chase a purchase order that was never acknowledged

    An outbound file shows file.delivered.v2 but no inbound acknowledgment follows within your window. The operator drafts a chase to the supplier and proposes it for your approval, with the fileExecutionId attached.

    With PO Chase

  • Match inbound invoices to receipts

    Inbound invoice transactions arrive as JSON with businessIdentifiers already extracted. The operator pairs each with the purchase order and receipt in your ERP and flags the ones that do not tie out.

    With Three-Way Match

  • Recover a failed delivery

    file.failed.v2 fires after the third delivery attempt. The operator reads the file execution, names the connection that failed, and proposes a retry once the remote host is reachable.

    With Integration Health, Webhook Replay

  • Flag late inbound shipments from ship notices

    Ship notices from suppliers arrive as processed transactions. The operator compares the dates on each notice against the open purchase order and flags inbound lines that are running late.

    With Inbound Delay

Requirements

  • A Stedi account on a plan with production API, SFTP, and webhooks; the free Sandbox plan issues test keys only
  • A local profile and profiles for your trading partners, each with an ID Qualifier, Interchange ID, and Application ID, joined by partnerships
  • A connection on each of those partnerships: Stedi SFTP/FTPS, Remote SFTP/FTPS, or AS2
  • Transaction settings for each X12 transaction set you exchange
  • An HTTPS endpoint with a publicly trusted certificate to receive webhook events, or a polling schedule in its place
Authentication
A Stedi API key generated in the portal in Test or Production mode and sent in the Authorization header; production keys inherit the permissions of the account member who created them.

Limits

  • Webhook endpoints must answer within 5 seconds. Non-2xx responses retry 4 times, 90 seconds apart, then sit in an error queue for 14 days.
  • Delivery is at-least-once, so duplicate events are possible, and the error queue is not ordered.
  • Create Outbound Transaction accepts Guide JSON under 5 MB, or under 4 MB with a mapping; delivery is attempted 3 times, 6 minutes apart.
  • Poll transactions omits the most recent 15 seconds and returns at most 500 items per page.

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Stedi ↗

Questions and answers

Does Stedi push events or do you poll?
Both. Webhooks deliver transaction.processed.v2 and file events to an HTTPS endpoint with Basic or API Key authorization. Poll transactions (GET /polling/transactions) returns newly processed transactions after a startDateTime or pageToken, ordered by processedAt. Stedi recommends paging by pageToken rather than by startDateTime alone.
What does the connector get for each inbound transaction?
A transaction record with transactionId, fileExecutionId, status, direction, mode, processedAt, the sender and receiver profiles, x12 metadata, extracted businessIdentifiers, translationErrors, and artifacts with download URLs for the input EDI and the output JSON.
Does Stedi send acknowledgments back to your suppliers?
Yes, when configured on the relevant partnerships. Stedi can generate a 997 Functional Acknowledgment or a 999 Implementation Acknowledgment for each inbound transaction. The connector does not send acknowledgments itself.
Ask about Stedi

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.