How does it work?

1. Choose the Jitterbit route. Use Studio FTP activities for SFTP reads and writes, API Manager when SFTP To Go should call a custom API, Jitterbit EDI for trading-partner document exchange, and SFTP To Go File Automations for file preparation or follow-up handling.
2. Create a dedicated SFTP To Go credential for Jitterbit. Bind it to the correct home directory and limit folder permissions to the paths this workflow actually needs.
3. Copy the host, username, authentication details, and port from the SFTP connection setup. Use SFTP port 22 unless your SFTP To Go endpoint needs another supported SFTP port.
4. In Jitterbit Studio, create an FTP connection for SFTP To Go. Configure the host, port, login details, authentication method, runtime environment, and folder path according to your connector and agent setup.
5. For inbound processing, add an FTP Read activity to the Studio operation and point it to the SFTP To Go folder that receives the source files. Use a clear file name or pattern so unrelated files are not picked up.
6. For outbound files, add an FTP Write activity and send the result to the correct SFTP To Go folder. Use a filename pattern that makes the output easy to identify, route, and audit.
7. Use SFTP To Go File Automations when file handling should happen before Jitterbit reads the file or after Jitterbit writes it. Common actions include copy, move, delete, PGP encrypt, PGP decrypt, delay, notifications, and webhook requests.
8. If SFTP To Go should trigger Jitterbit, build and deploy the Studio operation first. The operation should accept the incoming request, inspect the event data, retrieve the file over SFTP if needed, and return a suitable response.
9. In Jitterbit API Manager, publish the deployed operation as a custom API. Configure the service URL, method, security profile, environment, operation to trigger, and response behavior.
10. In SFTP To Go, create a webhook notification or File Automation webhook action that calls the Jitterbit custom API URL. Select only the event topics and filters needed for this workflow.
11. Keep file-event triggers narrow. Filter by folder, file pattern, actor, or event type, and exclude folder events where the operation should only process files.
12. In Jitterbit, branch on the payload data. For example, use file.created for ingestion or transformation, file.downloaded for audit actions, and file.deleted for status updates or review tasks.
13. If the operation needs file content after a webhook, use the SFTP path from the payload to read the file through the configured FTP connection. Decode Data.Path first if the webhook payload uses URL encoding.
14. For Jitterbit EDI, configure the FTP/SFTP communication settings according to the trading-partner workflow. Set the remote download folder, remote upload folder, file naming, automation frequency, retrieval mask, duplicate transaction checks, and delete-after-download behavior carefully.
15. Use the SFTP To Go REST API only for supported management tasks such as credentials, webhooks, share links, audit logs, and audit log exports. Use SFTP, FTPS, HTTPS, or S3 for file content.
16. Test the exchange from both sides. Confirm that Jitterbit can read inbound files, write output files, receive API-triggered events where used, and process EDI communication settings where relevant.
17. Before production, review Jitterbit operation logs, API Manager logs, EDI transaction activity, connector errors, and retry behavior alongside SFTP To Go file activity, automation history, webhook delivery, credential access, and audit logs.

You can find further insight into managed SFTP connection setup, SFTP file automations, SFTP webhook notifications, SFTP management APIs, Jitterbit Studio FTP connector, Jitterbit FTP connection setup, Jitterbit API Manager custom APIs, publishing Jitterbit operations as APIs, Jitterbit EDI workflows, and Jitterbit EDI FTP/SFTP communications.