How does ml-connector handle the different authentication models between Oracle NetSuite and Stedi?

Oracle NetSuite uses OAuth 2.0 Client Credentials with an X.509 certificate; ml-connector refreshes the token every 50 minutes to stay ahead of the 60-minute expiry. Stedi uses a long-lived API key in the Authorization header with manual revocation. Both credential sets are stored encrypted, and ml-connector presents the correct credentials to each API on every call.

What prevents duplicate purchase orders when the same PO is retried?

Every outbound PO to Stedi includes an Idempotency-Key header derived from the PO ID and timestamp; Stedi deduplicates based on that key over a 24-hour window. Inbound acknowledgments from Stedi carry an eventId, which ml-connector uses to avoid re-processing the same acknowledgment if a webhook is retried.

Does Oracle NetSuite's lack of webhook signatures create a security risk?

Oracle NetSuite event subscriptions do not include HMAC signatures. ml-connector validates webhook requests by checking the source IP against the allowlist and verifying the shared secret parameter embedded in the webhook URL, ensuring only legitimate events from Oracle NetSuite are processed.

Oracle NetSuiteStedi

Oracle NetSuite and Stedi integration

Oracle NetSuite stores your vendors, purchase orders, and inventory. Stedi translates your data into X12 EDI format and delivers it to trading partners via SFTP or AS2. Connecting them keeps your supply chain partners aligned with your purchase commitments without re-keying. New purchase orders created in Oracle NetSuite are automatically translated and transmitted to suppliers, and their acknowledgments flow back into Oracle NetSuite as confirmations. ml-connector handles the OAuth2 and API key authentication on both sides, ensures no PO is sent twice, and tracks every transmission in a full audit trail.

How Oracle NetSuite works

Oracle NetSuite exposes vendors, purchase orders, invoices, inventory items, and accounts through REST Web Services (SuiteTalk) and SuiteQL queries, both authenticated with OAuth 2.0 Client Credentials using an X.509 certificate. Tokens are valid 60 minutes and must be refreshed after expiry. Oracle NetSuite supports event subscriptions (webhooks) for purchase order and vendor changes, though the native webhooks do not include HMAC signatures; instead they rely on IP allowlist or a shared secret passed in the URL. Historical or bulk reads use SuiteQL polling. Sandbox accounts require a _SB suffix in the account ID.

How Stedi works

Stedi exposes EDI transaction endpoints (850 Purchase Orders, 855 Acknowledgments, 856 Shipment Notices) and configuration entities (Partnerships, Connections, Guides, Mappings) through REST JSON APIs authenticated with an API key in the Authorization header. API keys do not expire automatically and are revoked manually via the portal. Stedi can push inbound EDI transactions as JSON webhooks (event type transaction.processed.v2) to your endpoint, with up to 4 retries at 90-second intervals and a 5-second timeout per request. Outbound writes require an Idempotency-Key header for deduplication over a 24-hour window. Stedi routes EDI files to trading partners via SFTP, FTPS, or AS2 based on each Partnership and Connection configuration.

What moves between them

Purchase orders flow from Oracle NetSuite to Stedi. ml-connector reads new and modified purchase orders from Oracle NetSuite via SuiteQL polling or event subscriptions, maps them to X12 850 format, and posts them to Stedi for transmission to the supplier via SFTP or AS2. Inbound purchase order acknowledgments (855) from Stedi arrive as webhook JSON events; ml-connector parses them and writes transaction records back to Oracle NetSuite to mark the PO as acknowledged. Vendor master data syncs from Oracle NetSuite to Stedi Partnership records so EDI routing aligns with the active supplier list. Mappings between Oracle NetSuite GL accounts and Stedi transaction types are configured per partner.

How ml-connector handles it

ml-connector stores both credential sets encrypted and refreshes the Oracle NetSuite OAuth2 token every 50 minutes to stay ahead of the 60-minute expiry. On every outbound PO to Stedi, it includes an Idempotency-Key header (generated from the PO ID and timestamp) so that a retried delivery does not duplicate the transmission. Inbound webhook events from Stedi (transaction.processed.v2) include an eventId; ml-connector uses that to deduplicate and prevent re-processing the same acknowledgment twice. Oracle NetSuite's event subscriptions lack HMAC signatures, so ml-connector validates webhook requests by checking the IP source and the shared secret parameter in the webhook URL. Vendor master data changes in Oracle NetSuite trigger updates to Stedi Partnership records via the Stedi API; Stedi routes outbound EDI files to each trading partner based on the AS2 address or SFTP path configured in that Partnership. Retries are handled automatically by Stedi for transient failures, and ml-connector logs every PO transmission and acknowledgment in the audit trail.

A real-world example

A mid-sized manufacturing company runs Oracle NetSuite for order-to-cash and inventory management and relies on SFTP-based EDI to deliver purchase orders to key component suppliers. Before the integration, the procurement team created purchase orders in Oracle NetSuite and manually extracted them to X12 format, then used an SFTP client to send them to each supplier's designated folder. Tracking which POs had been transmitted was error-prone, and supplier acknowledgments arrived as separate EDI files that had to be imported back by hand. With Oracle NetSuite and Stedi connected, each new PO is automatically formatted and sent to the correct supplier within minutes, and acknowledgments flow back into Oracle NetSuite to confirm receipt. The procurement team now sees PO status in one system and can focus on exception handling instead of data transfer.

What you can do

Automatically format and send Oracle NetSuite purchase orders to Stedi as X12 850 EDI files, routed to suppliers via SFTP or AS2.
Receive supplier acknowledgments (855) from Stedi and write them back to Oracle NetSuite as transaction records.
Map vendor records in Oracle NetSuite to Stedi Partnerships so EDI routing aligns with your active supplier list.
Manage OAuth2 refresh cycles for Oracle NetSuite and API key authentication to Stedi, with encrypted credential storage.
Include Idempotency-Key headers on all outbound transactions to prevent duplicate PO transmissions and deduplicate inbound acknowledgments by event ID.

Questions

How does ml-connector handle the different authentication models between Oracle NetSuite and Stedi?: Oracle NetSuite uses OAuth 2.0 Client Credentials with an X.509 certificate; ml-connector refreshes the token every 50 minutes to stay ahead of the 60-minute expiry. Stedi uses a long-lived API key in the Authorization header with manual revocation. Both credential sets are stored encrypted, and ml-connector presents the correct credentials to each API on every call.
What prevents duplicate purchase orders when the same PO is retried?: Every outbound PO to Stedi includes an Idempotency-Key header derived from the PO ID and timestamp; Stedi deduplicates based on that key over a 24-hour window. Inbound acknowledgments from Stedi carry an eventId, which ml-connector uses to avoid re-processing the same acknowledgment if a webhook is retried.
Does Oracle NetSuite's lack of webhook signatures create a security risk?: Oracle NetSuite event subscriptions do not include HMAC signatures. ml-connector validates webhook requests by checking the source IP against the allowlist and verifying the shared secret parameter embedded in the webhook URL, ensuring only legitimate events from Oracle NetSuite are processed.

Connect Oracle NetSuite and Stedi

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started