Add Cloud File Storage to Your Application With REST API

Published 2026-09-24 04:08:38.215719 by Carsten Blum

Most business applications eventually need somewhere to store files. Customers upload documents. Your application generates PDFs. An ERP exports reports. Users attach images. A workflow produces files that another system needs to process. The application requirement is usually straightforward:

Upload a file → store it safely → retrieve it when needed → delete it when it is no longer required.

But implementing the storage behind that workflow can quickly become an infrastructure project of its own. With ftpGrid, your application can use a REST API directly against managed cloud file storage. You can upload, list, download, move and delete files over HTTPS without operating the underlying storage infrastructure yourself. The basic architecture is deliberately simple:

Your Application → REST API → ftpGrid Cloud Storage

Let's look at what that means in practice.

View larger infographic (AI generated image)

Step 1: Create REST API access

The ftpGrid Storage API uses token-based authentication.

Your application starts with API credentials consisting of an Association Key, Access Key and Secret Key. These credentials are used to authenticate against the ftpGrid Management API and obtain a temporary JWT access token.

Conceptually:

API Credentials → Authentication → JWT Token → Storage API

An authentication request contains:

{
  "AssociationKey": "YOUR_ASSOCIATION_KEY",
  "AccessKey": "YOUR_ACCESS_KEY",
  "SecretKey": "YOUR_SECRET_KEY"
}

The authentication endpoint returns a token:

{
  "token": "eyJhbGc..."
}

Your application then includes that token with subsequent Storage API requests:

Authorization: Bearer YOUR_TOKEN

The important architectural point is that the long-lived API credentials should remain on your backend. They should never be embedded in browser JavaScript, mobile applications or public source repositories.

From the application's perspective, authentication becomes a normal server-to-server integration rather than storage infrastructure that your team has to operate.

Step 2: Give the application only the access it needs

Storage API access is scope-based. Instead of giving every integration unrestricted access, an API user can be assigned scopes matching the operations it actually requires.

Available file scopes include:

• file.list — list files and directories

• file.read — download files

• file.create — upload files and create directories

• file.rename — move or rename files

• file.delete — delete files

This makes it possible to design access around the application.

For example, an application receiving customer documents might require:

file.list
file.read
file.create

while a cleanup or document-management process may additionally require:

file.delete

For business applications, this is preferable to treating storage as one shared administrative credential with unrestricted access.

Step 3: Upload a file

Once authenticated, your application can upload files directly to its assigned ftpGrid storage server. Uploads use multipart/form-data.

A simplified HTTPie example looks like:

http --form POST https://webN.ftpgrid.com/api/upload \
    Authorization:"Bearer YOUR_TOKEN" \
    file@"./invoice.pdf"

Without additional metadata, the file is uploaded to the storage root.

Applications can also specify destination directories. For example, a SaaS application could organize documents by customer:

/customers/1842/invoices/
/customers/1842/contracts/
/customers/3921/invoices/

Destination directories can be created automatically as part of the upload workflow, so your application does not need to provision every directory in advance. This makes a common application workflow straightforward:

Application generates invoice → REST API upload → /customers/1842/invoices/invoice-2026-1042.pdf

The application remains responsible for its business logic. ftpGrid handles the file storage behind it.

Step 4: List stored files

Applications frequently need to know what is already stored. The Storage API provides endpoints for listing files, directories or complete directory trees.

A request to list files in a directory can look like:

http POST https://webN.ftpgrid.com/api/list/files \
    Authorization:"Bearer YOUR_TOKEN" \
    Params="/customers/1842/invoices/"

The response contains file information such as:

[
  {
    "lastModified": 1778904174199,
    "name": "invoice-2026-1042.pdf",
    "size": 184642,
    "type": "file"
  }
]

Your application can use that information to build its own business functionality.

For example:

• Display documents belonging to a customer

• Verify that an export exists

• Show generated reports

• Process incoming integration files

• Synchronize application state

• Build administrative file views

The storage API supplies the file operations while your application determines what those files mean.

Step 5: Download a file

Files can be downloaded directly through the REST API. A single-file request specifies the full file path:

http POST \
    "https://webN.ftpgrid.com/api/download/single?path=/customers/1842/invoices/invoice-2026-1042.pdf" \
    Authorization:"Bearer YOUR_TOKEN"

The file is streamed directly from storage. This allows your backend to retrieve files when they are required for application processing.

A typical workflow might be:

User requests document → Application authorizes user → Backend retrieves file → Application returns document

That separation is important.

Your application remains in control of its own customer authentication and business permissions, while ftpGrid provides the underlying file storage.

Step 6: Delete files when they are no longer required

Files can also be removed through the API. For example:

http POST https://webN.ftpgrid.com/api/delete \
    Authorization:"Bearer YOUR_TOKEN" \
    Filelist[]="/customers/1842/invoices/invoice-2026-1042.pdf"

Multiple files or directories can be included in a single delete request. This means the complete application lifecycle can be managed through the API:

Create → Store → List → Read → Move → Delete

Your application does not need a mounted filesystem, FTP client or storage server to perform those operations.

A practical business architecture

The result is a straightforward architecture:

┌──────────────────────┐
│ Business Application │
└──────────┬───────────┘
           │
           │ HTTPS / REST API
           ▼
┌──────────────────────┐
│       ftpGrid        │
│  Cloud File Storage  │
└──────────────────────┘

That architecture works well for applications that need to store:

• Customer documents

• Generated reports

• PDF files

• Application exports

• Images and assets

• Integration files

• Data extracts

• Backup files

The development team gets an application interface to storage without having to turn file storage into another infrastructure platform.

REST API does not have to be the only interface

This is where business file storage often becomes more interesting. Your application may use the REST API, but other systems interacting with the same business process may not.

A legacy ERP might already support FTP:

ERP → FTP ────────┐
                  │
Application → API ├──→ ftpGrid Storage
                  │
Supplier → SFTP ──┘

There is no requirement to rewrite the ERP or ask a supplier to build an API integration simply because your new application uses REST. Different systems can use the interface appropriate for them while ftpGrid provides the managed file platform behind those integrations. That can be particularly valuable when modern software needs to coexist with older business systems.

React to new files with webhooks

Some applications need to do more than store files. Imagine a supplier uploads a file through SFTP. Your application needs to process it as soon as it arrives.

The traditional solution is polling:

Application → Check storage → Nothing → Wait → Check again

With webhooks, the workflow can instead become event-driven:

Supplier → SFTP → ftpGrid → Webhook → Your Application

Your application receives notification of the file event and can then begin processing. This allows REST API storage, traditional file transfer and event-driven application integration to work together on the same platform.

Learn more about ftpGrid webhooks.

Store with the API, deliver through HTTPS

There is another common requirement: your application creates a file, but the person receiving it should not need API access. For example, your application generates a customer report.

It can upload that report through the REST API:

Application → REST API → ftpGrid

The customer can then receive it through HTTPS:

ftpGrid → HTTPS → Customer

This can be useful for:

• Customer reports

• Invoices

• Data exports

• Generated documents

• Product files

• Partner deliveries

Your application uses the API because it is software. Your customer uses HTTPS because they are a customer. The storage platform supports both sides of the workflow.

Learn more about File & web Hosting.

Automate file retention

Applications are usually good at creating files. They are not always as good at removing them again. Temporary exports, generated reports and integration files can accumulate indefinitely unless the application contains its own retention logic. ftpGrid can automatically delete files based on age, allowing retention to be handled by the storage platform instead.

For example:

Application → Create report → Store for 30 days → Automatic deletion

This can reduce custom cleanup code and help businesses implement defined file lifecycle policies.

Learn more about Automation.

Keep storage credentials in the backend

There is one architectural rule worth emphasizing when integrating storage into a business application:

Do not expose your storage API credentials directly to end users.

The Access Key and Secret Key should be treated as backend credentials.

A typical architecture should therefore be:

Browser / Mobile App
        │
        ▼
Your Application Backend
        │
        │ REST API
        ▼
ftpGrid Storage

Your backend controls:

• User authentication

• Business authorization

• Which files a user can access

• File naming

• Directory structure

• Application metadata

ftpGrid provides:

• Managed file storage

• Storage API

• FTP/SFTP access

• Webhooks

• Retention

• HTTPS file delivery

That creates a clear boundary between application logic and storage infrastructure.

Cloud file storage without building a storage platform

Adding file storage to an application should not necessarily require building an entire cloud architecture around it. If the requirement is:

“Our application needs somewhere reliable to store and retrieve files.”

then the architecture can remain:

Application → REST API → Managed Storage

With ftpGrid, the same storage can also participate in wider business workflows through FTP, SFTP, webhooks, automatic retention and HTTPS file hosting. That means you can start with the simple requirement — storing files from your application — without creating a storage architecture you then have to operate yourself. And if another business system needs to interact with those files tomorrow, you are not limited to the REST API. Use REST where REST makes sense. Use FTP or SFTP where they already work. Let the storage platform connect the two.

For more examples and API integration patterns, see the REST API tutorial.