REST API for FTP/SFTP cloud storage

Published 2026-05-18 08:26:13.556359 by Carsten Blum

Today we launched a major new feature for ftpGrid.com - REST API for management and storage. This features further establishes ftpGrid as a enterprise grade file integration platform, which also happens to support FTP and SFTP protocols. Our core business has always been cloud storage with FTP and SFTP access, but with REST API we are slowly evolving into something broader: an asynchronous data exchange platform between systems, services and workflows. That may not roll off the tongue quite as elegantly as "cloud FTP", but technically speaking, that is increasingly what ftpGrid is becoming.

Why we built REST API

FTP and SFTP are fantastic protocols for file exchange. They are battle tested, universally supported and deeply integrated into enterprise systems across banking, healthcare, manufacturing, logistics and government infrastructure.

But modern software stacks increasingly expect REST interfaces.

Developers want:

• JWT authentication

• scoped access tokens

• JSON payloads

• direct browser integrations

• webhook workflows

• API automation

• infrastructure-as-code

• microservice integration

We did not want to replace FTP and SFTP. We wanted to complement them. The result is a hybrid platform where systems can interact using the protocol that makes the most sense for the specific workload.

Core REST API features

Management API

The Management API allows applications to manage ftpGrid resources programmatically.

At launch, the Management API primarily focuses on FTP account lifecycle management.

This includes full CRUD functionality for FTP accounts:

• Create FTP accounts

• Retrieve FTP accounts

• Update FTP accounts

• Delete FTP accounts

This enables powerful automation scenarios such as:

• automatically provisioning customer accounts

• creating temporary upload credentials

• rotating credentials dynamically

• integrating ftpGrid into onboarding systems

• generating access credentials from ERP or CRM systems

• creating isolated upload endpoints per customer or workflow

A single API call can create a fully isolated FTP/SFTP account with:

• username

• password

• SSH public key

• access rights

• chroot path

• description

• enabled/disabled state

The Management API uses JWT authentication and scoped API users to ensure applications only receive the permissions they actually need.

Storage API

The Storage API is where things become really interesting.

The Storage API allows applications to interact directly with ftpGrid cloud storage using REST instead of FTP or SFTP.

In practice, this means your applications can:

• upload files

• download files

• list files

• list directories

• retrieve metadata trees

• create directories

• move files and directories

• delete files and directories

All using standard HTTPS requests. This effectively turns ftpGrid into a programmable distributed storage layer. Unlike traditional object storage APIs, the ftpGrid Storage API intentionally keeps filesystem semantics intact.

That means:

• hierarchical directories

• recursive paths

• move operations

• rename operations

• metadata trees

• filesystem-style workflows

This is important because many enterprise integrations fundamentally operate around directory structures and file workflows.

Technical implementation

JWT authentication

The REST API uses signed JWT access tokens.

Applications authenticate using:

• Association Key

• Access Key

• Secret Key

Once authenticated, ftpGrid returns a short-lived JWT token used for all subsequent API requests.

Example authentication request, we're using HTTPie here:

http POST https://api.ftpgrid.com/apiaccess/auth \ 
    AssociationKey="YOUR_ASSOCIATION_KEY" \ 
    AccessKey="YOUR_ACCESS_KEY" \ 
    SecretKey="YOUR_SECRET_KEY"

We intentionally chose short-lived tokens to reduce exposure risk and improve operational security.

Scopes

One of the most important aspects of the implementation is scopes.

Every API user can be restricted to a very precise set of capabilities.

Examples:

• ftpaccount.create

• ftpaccount.delete

• file.read

• file.create

• file.rename

• file.delete

This makes it possible to build highly isolated integrations.

For example:

• an upload-only camera system

• a read-only reporting integration

• a temporary customer dropbox

• an automated archive service

• a webhook-driven document processor

without exposing unnecessary access.

This becomes especially important when ftpGrid is used as middleware between multiple systems.

Endpoint design

One thing we cared deeply about was keeping the API intuitive. A lot of storage APIs become unnecessarily abstract. We intentionally stayed close to filesystem semantics.

Examples:

• /api/list/files

• /api/list/dirs

• /api/list/tree

• /api/upload

• /api/download/single

• /api/download/multi

• /api/mkdir

• /api/move

• /api/delete

The result is an API that feels predictable to developers already familiar with storage systems.

Storage metadata engine

One of the more interesting endpoints is:

/api/list/tree

Unlike direct filesystem traversal, this endpoint operates against the metadata engine.

This means:

• faster recursive listings

• full storage trees

• checksum support

• timestamp support

• protocol source tracking

• scalable metadata traversal

The tradeoff is eventual consistency.

Endpoints such as:

• /api/list/files

• /api/list/dirs

operate directly against physical storage.

Meanwhile:

• /api/list/tree

operates against metadata state.

This gives developers the ability to choose between:

• physical storage accuracy

• metadata speed and scalability

depending on the workload.

Multipart uploads

Uploads use standard multipart form-data requests.

This allows direct browser uploads without custom binary protocols.

The upload engine supports:

• multiple files per request

• recursive directory creation

• overwrite handling

• metadata-based path mapping

Example upload flow, we're using HTTPie here:

http --form POST https://serverN.ftpgrid.com/api/upload \ 
    Authorization:"Bearer YOUR_TOKEN" \ 
    f1@"./invoice.pdf" \ 
    meta='{ 
        "files":[ 
            { 
                "field":"f1", 
                "path":"customers/2026/"  
            } 
        ] 
    }'

This makes browser integrations extremely straightforward.

Download workflows

Downloads support both direct file streaming and multi-file ZIP generation.

Single file downloads stream directly:

/api/download/single

Multi-file downloads use a prepare-and-download workflow:

• prepare download

• receive temporary download ID

• retrieve generated archive

This design avoids enormous request payloads while keeping downloads stateless and scalable.

Documentation

We invested heavily in documentation from day one.

Every endpoint includes:

• HTTPie examples

• raw JSON payloads

• request structures

• response examples

• scope requirements

• edge case behavior

The full documentation is available here: https://docs.ftpgrid.com/intro

The full integration engine

With REST API, webhooks and AWS S3 integration, ftpGrid is increasingly becoming a full asynchronous integration engine.

Different systems can now exchange files using entirely different protocols while ftpGrid acts as the middleware layer.

Examples:

• SFTP inbound

• REST outbound

• S3 archive

• webhook notifications

• browser uploads

• automated processing pipelines

all within the same platform.

Example use cases

Use case 1 — security cameras and surveillance

Security camera systems often only support FTP uploads. Modern monitoring systems often expect REST APIs or cloud webhooks. ftpGrid can now bridge that gap.

Flow example:

• security cameras upload footage using FTP

• ftpGrid stores files

• webhook triggers processing workflow

• application retrieves footage using REST API

• archive is mirrored to S3

No custom middleware required.

Use case 2 — ERP and accounting integrations

Many ERP systems generate reports as files. Traditionally these systems require SMB shares, FTP servers or manual workflows.

Using ftpGrid:

• ERP exports reports via SFTP

• accounting platform consumes files via REST

• webhook signals processing completion

• archive automatically moves to cold storage

This creates loosely coupled integrations between systems that otherwise would never communicate cleanly.

Use case 3 — browser uploads at scale

Traditional FTP is awkward in browsers. The REST API changes that entirely.

Applications can now:

• upload directly from frontend applications

• map uploads into isolated directories

• generate temporary credentials

• process uploads asynchronously

• retrieve files later through REST or SFTP

This opens up entirely new frontend use cases for ftpGrid.

REST API changes how we think about ftpGrid

Internally, this release changes how we think about the platform itself. Historically, ftpGrid was: "cloud storage with FTP and SFTP access"

Increasingly, it is becoming: "a distributed asynchronous file exchange engine"

The protocols are becoming implementation details. The actual product is reliable, secure movement of data between systems. REST API is a major step in that direction.

Final thoughts

FTP and SFTP are not going away. If anything, we believe they are massively underestimated technologies. But modern integrations require flexibility. REST API gives developers a modern interface into the same battle-tested storage and transfer engine already powering ftpGrid.

This is only the beginning. More endpoints, more integrations and more automation capabilities are already on the roadmap.

Relevant links

• Building file integrations with FTP, APIs and webhooks

• Cloud FTP

• Cloud SFTP