Automating Secure File Transfer: the SRIFT REST API and SDKs

Whatever service you call, the same handful of design questions decide what an integration can leak. They are worth asking before writing any code against a transfer API.

• Where encryption happens. If your code uploads the plaintext over HTTPS, the provider can read it. Only encryption performed before the request (client-side or end-to-end) keeps the provider out; see client-side vs server-side encryption.
• What the credential can do. A long-lived API key in a CI job or an agent sandbox is a standing liability. Prefer scoped, short-lived credentials, or designs that need none.
• Link lifetime and revocation. A download link is a bearer secret. The API should let you set a download cap and an expiry when you create it, and revoke it afterwards.
• Streaming. Files should be read and sent in chunks. An API that wants the whole file in one request body, or base64 inside JSON, will fail on large files and multiply memory use.
• Events instead of polling. Transfers take time. A push channel for progress and incoming requests is simpler and cheaper than polling a status endpoint.
• Retention. Find out whether the provider stores the file, for how long, and whether deleting the link deletes the bytes.

The srift CLI starts a background daemon on first use. It listens on 127.0.0.1:3822 only (set SRIFT_DAEMON_PORT to change the port) and exposes the same operations as the CLI and the MCP server: quick-share links, sessions, in-session transfers, chat, diagnostics and an event stream. The daemon holds the keys and reads files directly from disk, so your code passes a path, not bytes.

Because it only listens on loopback, there are no API keys. The flip side is that every program on the machine can call it, so on a shared multi-user host treat it as available to all local users, and stop it with srift daemon stop when it is not needed.

The endpoints most integrations need:

Start the daemon once (srift daemon start, or any srift command starts it), then create a link. The request names a local path; the response carries the URL to hand to the recipient.

curl -s http://127.0.0.1:3822/quick-share \
  -H 'Content-Type: application/json' \
  -d '{"filePath":"/srv/exports/report.pdf","encrypt":true,"maxDownloads":1,"ttlMs":3600000}'

{
  "success": true,
  "token": "<token>",
  "downloadUrl": "https://srift.app/d/<token>#k=<key>",
  "fileName": "report.pdf",
  "encrypted": true,
  "maxDownloads": 1,
  "expiresAt": 1791460800000
}

With encrypt set, the file is sealed with AES-256-GCM in the daemon and the key exists only in the part of downloadUrl after #k=. Treat the whole URL as a secret: do not log it. The link works while the daemon runs, and POST /pubshare/revoke with the token ends it early.

Python

pip install srift installs the CLI and the Python SDK together. The SDK uses only the standard library.

from srift import Srift

s = Srift()  # http://127.0.0.1:3822, or SRIFT_BASE_URL
link = s.quick_share("/srv/exports/report.pdf", encrypt=True, max_downloads=1, ttl_ms=3_600_000)
print(link["downloadUrl"])

Node.js

The Node.js SDK is a single dependency-free file, published at https://srift.app/sdk/node/srift.mjs; it needs Node.js 18 or later for the built-in fetch.

import { Srift } from "./srift.mjs"

const s = new Srift()
const link = await s.quickShare("/srv/exports/report.pdf", { encrypt: true, maxDownloads: 1 })
console.log(link.downloadUrl)

The Go, Rust, Java, .NET, PHP, Ruby, Bash and PowerShell clients follow the same method names and are linked from llms.txt. All of them are thin HTTP clients: none bundles the daemon, so the srift CLI must be installed on the machine.

To receive a file from a person, a script opens a session, waits for them to ask to join, admits them, and accepts their offer. The event stream drives the whole flow without polling:

from srift import Srift

s = Srift()
session = s.start_session(name="uploads")
print("Send this link to the sender:", session["joinUrl"])

for ev in s.stream_events():
    if ev["event"] == "join_request":
        # Check who it is before admitting: anyone with the link can ask.
        s.approve_join(ev["data"]["tempUserId"])
    elif ev["event"] == "file_offer":
        s.accept_transfer(ev["data"]["fileId"], save_dir="./incoming")
    elif ev["event"] == "transfer_progress" and ev["data"].get("status") == "completed":
        print("received", ev["data"]["fileId"])
        break

Chunks that pass through the relay are sealed with AES-256-GCM under a key the two sides agree with ECDH. When both ends are scripts or agents, pass the same room_secret to start_session and join_session: it is mixed into the keys and never sent to the server, which closes the key-substitution gap described in the SRIFT security architecture.

The daemon serves three interfaces over the same core. Pick by who is driving it:

• Shell scripts and CI: the CLI. srift quick-share file --encrypt --once --json prints one JSON line, and it can run without a background daemon in sandboxes. See sharing CI/CD build artifacts.
• Applications and services: the REST API or an SDK, especially when you need events or several operations in one process.
• AI agents: the MCP server, which exposes the same operations as tools with typed schemas. See setting up SRIFT in MCP clients.

In each case the security properties come from the daemon: what is encrypted, what the relay sees and how links expire do not change with the interface. What a relay can see lists the metadata that remains.