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.
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.
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.
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.
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.
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.
This connector listing is developed, published, and supported by Fibric. It describes integration with Stedi through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy