MYOB and Stedi integration

What moves between them

MYOB purchase orders and sales invoices flow into Stedi. ml-connector polls MYOB on a schedule you define, filters for new or updated records using the LastModified timestamp, and pushes each one to Stedi as a JSON mapping of line items, quantities, and account codes. Stedi converts the JSON into standard X12 EDI (850 for purchase orders, 810 for invoices) and routes the files to your trading partners via SFTP, FTPS, or AS2. Inbound supplier confirmations (855 PO Acknowledgments) and customer 810 invoices arrive at Stedi as webhooks and are routed back into MYOB to update order status and create AR records. The sync respects MYOB's company file credential requirements and Stedi's 5-second webhook timeout.

How ml-connector handles it

ml-connector stores MYOB OAuth tokens and company file credentials encrypted and refreshes the OAuth token before each poll cycle when the 20-minute expiry approaches. It uses OData $filter on the LastModified field to find only the records changed since the last sync, reducing API load against MYOB's rate limits. When sending to Stedi, each outbound call carries the required Idempotency-Key header with a unique value so retries do not create duplicate transactions. On the inbound side, ml-connector registers its webhook endpoint with Stedi to receive transaction.processed events after EDI parsing, validates the eventId for deduplication, and creates or updates matching MYOB purchase orders and AR invoices within 5 seconds so Stedi's webhook retry does not occur. Because MYOB enforces both OAuth expiry and company file credential validation on every call, ml-connector pre-validates the company file token and re-authenticates if needed. For MYOB records locked by RowVersion conflicts, ml-connector retrieves the latest RowVersion and retries the update. Rate-limit backoff on both sides uses exponential delay to respect MYOB's 8 req/sec ceiling.

A real-world example

A mid-market Australian distributor uses MYOB for accounting and has trading relationships with 30 suppliers managed through an EDI network. Before the integration, the procurement team exported purchase orders from MYOB once a day, manually mapped them to X12 format using a separate EDI tool, and uploaded them to Stedi. Inbound 855 acknowledgments from suppliers arrived in Stedi but required manual download and re-entry into MYOB to update order status. With MYOB and Stedi connected, each new purchase order in MYOB is automatically converted and sent to Stedi within minutes, supplier confirmations flow back into MYOB to update order status, and the daily manual mapping step is eliminated.

What you can do

• •Send MYOB purchase orders and sales invoices to Stedi for X12 conversion and EDI delivery to trading partners.
• •Receive inbound EDI acknowledgments and invoices from Stedi and create or update corresponding MYOB records.
• •Poll MYOB on a schedule using LastModified filtering to detect only changed records and minimize API calls.
• •Manage MYOB OAuth token refresh and company file credential validation, and handle Stedi Idempotency-Key deduplication on outbound writes.
• •Track EDI translation and delivery status with full audit logging and replay failed transactions on demand.

Questions

How does ml-connector handle MYOB OAuth token expiry and company file credentials?

MYOB requires three authentication elements: an OAuth2 bearer token that expires in 20 minutes, an API Key, and separate company file credentials sent as a Base64-encoded header on every API call. ml-connector stores all three encrypted, monitors the OAuth token expiry, and refreshes it before each poll cycle to avoid 401 errors mid-transaction. Company file credentials are validated on every call and re-authenticated if needed.

Why does Stedi require an Idempotency-Key header, and how does ml-connector use it?

Stedi deduplicates outbound requests within a 24-hour window using the Idempotency-Key header. If a network failure causes a retry, sending the same key tells Stedi to return the prior result instead of creating a duplicate EDI file. ml-connector generates a unique key per outbound transaction and resends the same key if the call must retry, ensuring each MYOB record produces exactly one EDI file.

What happens if Stedi takes longer than 5 seconds to accept a webhook?

Stedi webhook endpoints must respond within 5 seconds or Stedi will retry up to 4 times with 90-second intervals before queuing the event for 14 days. ml-connector acknowledges the webhook immediately and processes the inbound EDI asynchronously in the background, ensuring the 5-second timeout is not exceeded while still guaranteeing that every inbound EDI transaction is created in MYOB.