Real-time EDI Processing over SFTP Using Webhooks

Real-time EDI processing over SFTP means using file events to trigger EDI processing as soon as a file is uploaded, instead of polling an SFTP folder on a schedule.

For high-volume or time-sensitive EDI workflows, waiting for a scheduled folder check can slow down processing and add unnecessary operational work. Webhooks reduce that delay by sending an event notification when the file action happens.

In SFTP To Go, webhooks can notify a receiving endpoint when file events occur. From there, an EDI processing system, iPaaS platform, or custom integration service can retrieve the file, validate it, transform it, and start the next business process.

SFTP To Go handles secure file transfer and webhook notification. The EDI or integration system handles parsing, validation, transformation, acknowledgments, and business-system updates.

This guide explains how that setup works with SFTP To Go, what infrastructure is required, and where webhooks improve EDI over SFTP workflows.

How webhooks enable real-time EDI processing over SFTP

Webhooks are HTTPS callbacks that notify another system when a defined event occurs. In an EDI over SFTP workflow, the event is usually a file upload to SFTP To Go storage.

When a partner uploads a new EDI file, SFTP To Go can send a webhook notification to your configured endpoint. That endpoint is usually a webhook receiver connected to your EDI processing system or integration platform.

The webhook receiver reads the event metadata, such as the file path, upload time, file size, and user or credential involved. The receiver can then pass that information to the EDI system so it knows which file to retrieve and process.

The EDI system identifies the message type, validates the file against the expected format, extracts and transforms the data if needed, and passes the result into the relevant business system.

For example, if the file is a purchase order, the EDI system may validate the document, create or update an order record, and return an acknowledgment or response file.

This automation accelerates everything by reducing the time between file upload and processing. The value increases as file volume grows. Instead of waiting for the next polling cycle, the workflow can begin as soon as the upload event is received and validated.

Real-time EDI over SFTP webhook flow

A typical webhook-based EDI workflow looks like this:

1. A trading partner uploads an EDI file to SFTP To Go.
2. SFTP To Go sends a webhook notification to the configured HTTPS endpoint.
3. The webhook receiver validates the request and reads the event metadata.
4. The EDI or integration system retrieves the uploaded file.
5. The EDI system parses, validates, transforms, and processes the document.
6. The system writes an acknowledgment, response file, error file, or business-system update as required.

This keeps the file transfer event separate from the EDI business process. SFTP To Go records and notifies the file event.

Triggers and notifications

In SFTP To Go, webhooks can be configured for file and directory events, such as creation, deletion, and download. For EDI processing, the most common trigger is a new file upload in a defined folder.

The webhook shouldn't process every file blindly. Use folder paths, filename patterns, partner credentials, or other routing rules to decide which files should start an EDI workflow.

Webhook security considerations

Webhook security shouldn't depend only on a hidden URL.

The receiving endpoint should require HTTPS, validate the authorization header or shared secret, log received events, handle duplicate notifications safely, and confirm that the referenced file is ready before processing.

SFTP To Go supports HTTPS webhook endpoints and lets users define an authorization header value for webhook requests. That gives the receiver a way to verify that the notification came from the expected source before triggering downstream processing.

Infrastructure for real-time EDI over SFTP using webhooks

A real-time EDI over SFTP workflow needs three parts: a managed SFTP endpoint, an EDI processing system, and a webhook receiver.

1. Managed SFTP endpoint, aka SFTP server:

SFTP To Go provides the managed SFTP environment where trading partners can upload EDI files securely.

For EDI over SFTP, the managed endpoint should support secure transfer, controlled access, encrypted storage, audit records, and separate partner folders. SFTP To Go provides managed SFTP and FTPS, Amazon S3-backed storage, HTTPS web portal access, credentials, permissions, audit logs, APIs, and webhooks.

2. EDI processing system:

The EDI processing system handles the document logic. It should parse, validate, transform, and route EDI files according to the business process.

Software selection

Use an EDI processing system, iPaaS platform, or custom service that supports the formats and workflows your partners require. The system should retrieve files from SFTP storage, validate the EDI document, transform it where needed, write acknowledgments or error files, and update the relevant ERP, WMS, billing, inventory, or supply chain system.

Cloud-based processing can reduce the need to expose internal servers to inbound traffic, but it still needs proper access controls, logging, and secure credential management.

Validation and transformation

The EDI system should validate each file against the expected format or standard, such as ANSI X12 or EDIFACT. It should also transform the data into the format required by the receiving business system.

3. Webhook receiver:

The webhook receiver is the HTTPS endpoint that receives webhook notifications from SFTP To Go. It sits between the file transfer event and the EDI processing system.

SFTP To Go does not provide a built-in webhook receiver. You need to provide the receiving endpoint, either through an existing integration platform, an iPaaS workflow, a serverless function, or a custom service.

Webhook setup in SFTP To Go

In the SFTP To Go dashboard, create a webhook and provide the HTTPS endpoint URL that will receive notifications. Configure the event type and filters so only relevant file activity triggers the EDI workflow.

For EDI, filters are useful when different partners, folders, or filename patterns should trigger different processing routes.

Webhook notification handling

The webhook receiver should accept HTTPS POST requests, validate the request, read the JSON payload, and pass the relevant file metadata to the EDI or integration system. It should also handle duplicate events, errors, retries, logging, and failure alerts.

Custom webhook receiver development

If you build a custom receiver, keep it narrow. It should validate the notification, extract the file details, trigger the next process, and record what happened.

The EDI system should still handle parsing, validation, transformation, acknowledgments, and business updates. Keeping that split clear makes the workflow easier to support and less likely to break when file transfer rules or EDI rules change.

Webhooks vs. polling for EDI over SFTP

Polling checks an SFTP folder on a schedule. Webhooks notify the next system when a file event occurs.

Polling can work for low-volume or low-urgency workflows, but it adds delay and creates unnecessary folder checks when no new files are available.

Webhooks are better when EDI files need to move quickly, file volumes are high, or processing should start as soon as an upload is complete. With filtering, SFTP To Go can trigger webhooks by user, folder, or filename pattern, so only relevant file events start EDI processing.

In conclusion

Real-time EDI processing over SFTP works best when each part of the workflow has a clear job.

SFTP To Go provides the managed file transfer environment: secure SFTP and FTPS access, storage, partner credentials, permissions, audit logs, APIs, and webhook notifications.

The webhook receiver validates the event and passes the file metadata to the next system. The EDI processing system handles the document work: parsing, validation, transformation, acknowledgments, errors, and updates to business systems.

That setup reduces reliance on scheduled folder polling and helps teams process EDI files sooner after upload.

SFTP To Go - Managed File Transfer. Secure, compliant, scalable.

Frequently asked questions