These examples illustrate how Files.com orchestrates data across different protocols and destinations. While each workflow may vary slightly depending on configuration and destination type, the following outlines represent the most common flows.

File Upload from a Files.com Client to Native Files.com Storage

Here’s a simplified sequence illustrating a file upload from a client to Files.com native storage:

1. A Files.com client (Web App, Desktop App, CLI, or SDK) initiates an upload by making an API request to the Files.com API.
2. The request is routed via geo-DNS to the nearest regional proxy.
   • The proxy terminates TLS, performs first-level WAF and security checks, and forwards the request to the Core API.
3. The API validates the session, applies rate-limit and permission checks, and creates an upload object that includes a securely signed URL pointing to a customer-scoped path in Files.com’s Amazon S3 bucket.
4. The client then opens a direct connection to Amazon S3 using that signed URL and uploads the file data.
   • In this flow, the file data travels directly from the client to S3 and does not traverse Files.com’s internal infrastructure.
5. After the upload completes, the client makes another API request (via the proxy) to confirm completion.
6. The Files.com API validates the uploaded object and triggers background jobs as appropriate (e.g., GPG encryption, metadata indexing, transformations, webhooks, and audit entries).
   • These jobs execute in the regional or central worker pools depending on their scope.
7. Audit logs are generated at every stage — proxy access logs, API logs, and historical user activity logs.

File Upload from an SFTP Client to Files.com Storage

Here’s a simplified sequence illustrating a file upload from a client to Files.com native storage:

1. An external client initiates an SFTP connection (port 22) to app.files.com, or to a customer-specific subdomain or custom domain.
2. The connection is routed via geo-DNS to the nearest regional proxy (or region assigned to the subdomain), which forwards it to the SFTP service in the Regional Services Layer.
3. The SFTP service performs user authentication by opening an API session with the Files.com Core API on the client’s behalf.
   • This session is cached in Redis for reuse in future SFTP connections.
4. The SFTP service then initiates an internal API request to create an upload object, bypassing the proxy layer for efficiency.
   • The API validates the session, rate limits, and permissions, and returns a securely signed S3 upload URL.
5. The SFTP service opens a direct connection to Amazon S3.
6. The client streams file data via SFTP to the regional SFTP service, which forwards it directly to S3 using in-memory buffering — data is never written to disk.
7. Once the upload completes, the SFTP service notifies the API internally, marking the upload complete.
8. The API triggers background jobs and logging, just as in the previous workflows.

File Copy or Sync from Remote Server (i.e. SharePoint, remote SFTP, etc.) to Files.com

Here’s a simplified sequence illustrating the copying of a file from a remote server (such as SharePoint or a remote SFTP) to Files.com.

1. A copy or sync operation is initiated — either manually by a user or automatically through a scheduled sync or automation. This results in a job being created and executed within the central worker pool.
2. The central worker issues two RPC jobs to the Regional Integration Service:
   • Source RPC: Sent to the service worker in the region associated with the source (e.g., SharePoint or remote SFTP).
     • This worker returns a secure signed URL that represents the source file stream.
   • Destination RPC: Sent to the service worker in the region associated with the destination (in this case, the target Files.com region), providing the signed URL returned from the source.
3. The destination service worker connects to the source service worker using that signed URL.
   • The source service downloads the file from its remote endpoint and streams it directly to the destination service.
   • The destination service, in turn, streams the file to its final storage destination (in this case, Amazon S3).
4. The entire operation is streamed in real time with in-memory buffering only — no intermediate files are ever written to disk, even for Box and OneDrive remotes.
5. Upon completion, the central worker job finalizes metadata, triggers other applicable background jobs, and records full audit logs for the transaction.

File Upload from a Files.com Client to SharePoint

Here’s a simplified sequence illustrating a file upload from a client directly to a remote server destination such as SharePoint:

1. The client initiates an upload to a SharePoint-mounted destination via the Files.com API.
2. The request is routed through geo-DNS to the nearest regional proxy, which terminates TLS, performs security checks, and forwards the request to the API layer.
3. The API performs session, rate-limit, and permission validations.
4. The API then issues an RPC job to the Regional Integration Service in the region associated with the SharePoint integration.
   • This service generates a securely signed upload URL and returns it to the API.
5. The API forwards that signed URL to the client.
6. The client opens a new connection to the signed URL, which routes through a Files.com proxy in the target region to a Regional Integration Service worker.
7. The Integration Service accepts the incoming data stream and writes it directly to SharePoint using in-memory buffering.
   • Buffers are discarded immediately upon completion.
8. After data transmission, the API triggers background jobs (as in the previous flow) and emits audit logs for all actions.

Buffered Upload Flow

Uploads to remote destinations in some circumstances use an alternate flow, whereby the file is first uploaded to Files.com Native Storage, and then copied to the remote destination.

This buffered upload flow occurs in the following circumstances:

• Uploads to OneDrive or Box (their APIs require the full file before upload).
• Uploads into folders configured for GPG encryption or decryption.
• Uploads to any remote server which has been explicitly configured by the Site Admin to require buffered uploading via Files.com Native Storage.

These buffer locations are ephemeral and swept daily. In these scenarios, the flow will resemble the File Upload from a Files.com Client to Native Files.com Storage flow above, with the addition of an additional step to move the file to the remote server. That additional step will resemble the File Copy or Sync from Remote Server to Files.com flow described above, except in the reverse direction.