Celigo-hosted SFTP file server: give every trading partner a folder, not a server -- who would you onboard first?

Somewhere in most file-based integrations there's a server nobody wanted to own. A retailer, 3PL, or bank says "we only push to SFTP," so IT provisions a box, creates a user, opens the firewall, and patches it forever -- all so a partner has somewhere to drop files a flow picks up minutes later. Or the partner hosts, you get read-only access, and you can't rename a file to mark it processed. Or there's no server at all, and the supplier's price list arrives as an email attachment. If you run a server like that, pay an MFT vendor for one, work around someone else's, or have told a partner "we can't receive files that way," this post is for you.

The Celigo-hosted SFTP file server is now in production. Below: what it is, five patterns it makes straightforward, and a few questions. The questions are the point -- the next phase is being sequenced now, and I'm after the partner setups I haven't seen.

What it is

You turn on a file server for an environment and choose a file server identifier, a short suffix that is unique in your region and becomes part of every partner's sign-in. Then you create a file server account per partner: a username, a password you set, and a home folder, which is any Celigo Storage folder. The partner connects to a regional Celigo endpoint on port 22 with any standard SFTP client -- OpenSSH, WinSCP, FileZilla, a bank's scheduler -- signs in as <username>@<identifier>, and sees the home folder as their root. They can't navigate above it, and inside it they have full access: list, download, upload, create folders, rename, overwrite, delete.

Every file they upload is an ordinary Celigo Storage file the moment the transfer completes: on the File storage page, counted in your allowance, readable by flows through the Celigo APIs connector. Everything your flows write into the folder is there for the partner to download. The partner needs no Celigo sign-in, and you need no connection.

Partner (any SFTP client)                        Celigo Storage                          Your flows
acme-inbound@<identifier>   ── upload ──►   /partners/acme/inbound    ── Transfer files out ──►  parse 850s, route, load orders
acme-outbound@<identifier>  ◄── download ── /partners/acme/outbound   ◄── Transfer files into ── generate 856s, invoices, reports

Concepts in full: Celigo-hosted file server overview.

Five patterns

1. The partner who will only push to SFTP. The retailer's onboarding packet says "provide an SFTP endpoint." Create an account acme-inbound with home folder /partners/acme/inbound, set a password, and send them the connection details plus the connect article linked below. Their 850s land in the folder; a scheduled flow with Transfer files out of source application on the Celigo APIs connector parses them -- EDI X12 against your EDI profile if you have B2B Manager -- and loads the orders. The step that used to wait on IT is a few minutes of configuration.

2. The pickup shelf. The mirror image. Your flow writes 856s, 810s, or a daily inventory file with Transfer files into destination application to /partners/acme/outbound, and the partner's scheduler downloads on its own cadence. Because the folder is yours, a flow can archive what's been picked up with the record-based Celigo Storage steps (list, move, rename, delete). The Relative path option takes Handlebars, so /partners/{{partnerCode}}/outbound lets one flow serve every partner.

3. Flip the read-only partner server. A workaround EDI teams have described to us: the partner hosts, you have read-only access, so you can't move or rename files to mark them processed, and you stage copies in S3 or Google Drive to route on document type. When you host, the flow moves each file to /processed when it's done and routing runs on your own storage. Instead of asking the partner for write access to their server, ask them to push to yours.

4. One account per partner, per direction -- and revocation in one action. acme-inbound and acme-outbound are two accounts on two folders, so a partner who should only drop files can't browse what you're staging for them. Offboarding a partner, or responding to a leaked password, is Revoke access on the account: new sign-ins are refused and active sessions end within seconds, while the folder and its files stay put. Replacing the password does the same until they reconnect with the new one. Deleting the account destroys the credential and leaves the files.

5. Files from people, not only systems. A supplier's finance team sending a monthly price list, a customer's IT group dropping a one-off extract, an auditor picking up a report: each gets an account and a folder, connects with FileZilla, and never needs a Celigo sign-in or any idea what a flow is. Home folders are ordinary folders -- rename or move them freely, accounts follow -- and the folder's Used by view shows which accounts are homed there. You can't delete a folder that is someone's home folder; the platform lists the blocking accounts instead of stranding a partner.

Where it's not the right tool

  • The partner already hosts a server you can write to: keep using the FTP connector. Hosting is for when the partner needs you to provide the endpoint.

  • Your own flows need the partner's folder: don't point an FTP connection at your own file server -- validation refuses it on purpose. The Celigo APIs connector reads the folder directly.

  • Files moving between your own flows with no outside party: that's plain Celigo Storage, no server or account needed. AS2 partners stay on AS2 in B2B Manager.

How to start

  1. Resources > File storage > File server > SFTP server > Set up file server. Enter a File server identifier -- 3–30 lowercase letters, numbers, or hyphens, unique in your region, permanent once the server is on -- then Turn on file server. The connection details block shows the host, port 22, and the sign-in format. (Enable a Celigo-hosted SFTP file server)

  2. Accounts > Create account: a Username, the Home folder, and a Password -- copy it now, because Celigo never displays it again. Send the partner the connection details and the article written for them, Connect to a Celigo-hosted SFTP file server. (Create and manage file server accounts)

  3. In the consuming flow, add Transfer files out of source application on your Celigo APIs connection, select the home folder, and choose whether to parse; for outbound, Transfer files into destination application on the partner's outbound folder. (Use Celigo Storage as a file source or destination in flows; new to files in flows? Start with Working with files in Celigo.)

  4. Confirm arrival on the File storage page. Troubleshoot file server connections is the "my partner can't sign in" checklist.

Everything the UI does is also available through the management API, so a team that provisions partners from its own systems can create the account and set the password when the partner record is created.

The file server is an add-on, licensed independently of B2B Manager and off by default. If you don't see File server at the top of the File storage page, it isn't on your account yet, and your account team can add it. Account owners and administrators turn the server on and manage accounts, and Celigo Storage -- so the file server too -- needs the multiple-environment account structure. An activity log of partner sign-ins and file operations, SSH public key authentication, and per-account permissions (write-only drop boxes, read-only pickup folders) are planned as fast-follows; what you post here helps order them.

Your turn

I read every reply on this thread. Tell me:

  1. Who would you onboard first? Which partner's onboarding is stuck on "provide an SFTP endpoint" today, and what are they sending?

  2. What would this replace? A box your IT team patches, a standalone MFT product, a partner's read-only server you work around, or spreadsheets arriving by email -- show me the shape of it.

  3. What do your partners' security teams require? SSH keys, IP allowlisting on either side, write-only drop boxes -- name what blocks an onboarding, not what would be nice.

  4. What do the files look like? Sizes and daily counts, whether any partner appends to a running daily file or overwrites the same name every run, and whether anything downstream reads file modification times. These answers decide what gets built next.

  5. What would stop you from turning it on? A missing capability, a limit, or a setup step that doesn't fit how your team onboards partners.

Screenshots of the folder layout you'd use, or the onboarding checklist you send partners today, are welcome. If a pattern posted here is one we can build a template or an article around, I'll say so in the thread.

1 Like