What this means for your team

An API instead of a server

No host to patch, no firewall change, no public endpoint to defend. Your partner uses df-agent from their cron job or pipeline, or calls the API directly, with a secret key made for automation rather than a shared password everyone knows.

Access scoped to one folder

Each partner gets their own identity in your organisation and sees only what you share with them. They cannot pass it on to anyone else, and you can withdraw access without touching anyone else's.

Every transfer on record

Who collected which file, and when. On an FTP server that answer lives in logs nobody keeps; here it is a searchable record, and if the record cannot be written the download is refused.

Links that expire, networks you choose

Download links are time-limited. Restrict storage access to approved IP addresses and a link that escapes by email is useless outside your partner's network. Files under retention cannot be altered by either side.

Against the usual arrangement

Setup time

An SFTP exchange needs a host, accounts, keys, firewall rules and a test cycle with the partner's IT team. Here you create an identity, share a folder and send them the command.

Credential sprawl

Shared FTP passwords end up in scripts, wikis and inboxes, and outlive the people who created them. Automation identities can be shut off one at a time, and every access is attributable.

What happens afterwards

Files dropped on an FTP server sit there until someone tidies up. Here they carry a retention period, versions are kept, and nobody can quietly replace yesterday's file with a different one.

How the access actually works

  • You create an identity for them in your organisation — something like backendreports.acme@yourcompany.com — and share the folder with it.
  • Sharing works inside one organisation. There is no link between two separate DataFrugal accounts.
  • Recipients cannot re-share. What you grant is what exists, and every grant is recorded.
  • DataFrugal does not expose S3 endpoints. Everything goes through the DataFrugal API or df-agent.

In practice that is simpler than it sounds, and it puts you in charge: you are giving a vendor, auditor or client a narrow door into your own space rather than building a shared house between two companies. One identity per engagement, named so anyone can see what it is for.

Ending it is one action — close that identity. No firewall rule to unwind, no shared password to rotate for everyone else, and the record of everything they collected stays with you.

Frequently Asked Questions

Does our partner need their own DataFrugal subscription?

No. They use an identity inside your organisation, so there is nothing for them to buy and nothing to connect between two accounts. Pricing follows the data you protect, not the number of identities.

Can they send files to us as well as collect them?

Yes — uploads work the same way, through the API or df-agent, and are subject to the same roles and retention rules as anything else you store.

How do we cut them off when the contract ends?

Close the identity or remove the share. Their access stops immediately, nobody else is affected, and the record of what they collected stays with you.

What if their script needs to run unattended?

That is the intended use. An automation identity has a secret key rather than a person's password, so it can run from cron or CI without anyone storing a human login in a script.

Move one exchange off FTP

Pick the flow that breaks most often, set it up alongside the existing one, and switch when it has run clean for a week.

Talk to us