Workday Financial Management and Stedi integration

What moves between them

The flow runs from Workday Financial Management into Stedi. ml-connector polls Workday daily for purchase orders and supplier invoices using date-range filters, translates them into X12 850 and 810 EDI documents, and sends them to Stedi via REST API. Stedi then routes the files to your trading partners through SFTP, FTPS, or AS2 connections. Inbound EDI from suppliers can also be pushed from Stedi as webhooks for optional reply flows back into Workday, though the primary direction is outbound procurement documents.

How ml-connector handles it

ml-connector stores both credential sets encrypted: the Workday Integration System User account and OAuth2 refresh token for the SOAP/REST APIs, and the Stedi API key. On the Workday side, it issues OAuth2 token refresh requests whenever a call returns a 401, and it polls using date-range filters to fetch new and modified POs and invoices since the last run. On the Stedi side, it maps each Workday PO to an X12 850 and each invoice to an X12 810, signs each call with the required Idempotency-Key header for deduplication, and sends them to the configured SFTP or AS2 connection. Because Workday has no native webhooks, polling is the only viable sync mechanism; ml-connector retries on transient failures and carries the full audit trail of every record so a replay can correct a downstream Stedi routing failure.

A real-world example

A mid-sized manufacturer runs Workday Financial Management for procurement and accounts payable across multiple plants, and relies on Stedi to translate and route purchase orders to suppliers via EDI. Before integration, the procurement team exported POs from Workday as CSV, manually converted them to X12 format using a spreadsheet template, and uploaded them to Stedi for routing, an error-prone weekly process. With Workday and Stedi connected, each purchase order created or modified in Workday is automatically polled, formatted as X12 850, and sent through Stedi to suppliers within hours. Supplier invoices received via inbound EDI can also be matched back to Workday POs, reducing manual reconciliation.

What you can do

• •Poll Workday Financial Management daily for new and modified purchase orders and invoices using OAuth2 and SOAP/REST APIs.
• •Translate Workday purchase orders into X12 850 EDI documents and supplier invoices into X12 810 format.
• •Route translated EDI files to your trading partners through Stedi via SFTP, FTPS, or AS2 connections.
• •Sign every outbound Stedi API call with the required Idempotency-Key header and handle token refresh on the Workday side.
• •Poll on a daily schedule with retries, full audit trail, and replay capability if a Stedi routing call fails.

Questions

Which direction does data move between Workday Financial Management and Stedi?

The primary flow is from Workday Financial Management into Stedi. Purchase orders and supplier invoices are polled from Workday, translated into X12 850 and 810 EDI documents, and sent to Stedi for routing to your trading partners. Stedi can also push inbound EDI from suppliers as webhooks back to your systems for optional reply flows.

Why does ml-connector poll Workday instead of using webhooks?

Workday Financial Management has no native webhooks for procurement entities, only optional Outbound Messaging that requires manual per-process admin setup. Polling with date-range filters is the standard approach for connecting Workday to downstream platforms, with recommended intervals of 15-60 minutes for transactions and daily for stable master data.

Does Stedi require special headers or credentials for outbound calls?

Yes. Every outbound write to Stedi must carry an Idempotency-Key header with a unique value valid for 24 hours to deduplicate retries. Stedi uses API key authentication with no token expiry; the key must be manually revoked in the portal if compromised, and ml-connector stores it encrypted.