API
Server API.
The HTTP API covers accounts, files, packages, transfers, and admin. Bytes at speed still go over the data port; the API issues permission (tickets) and manages the portal.
Live OpenAPI on your server
Each Farwing Server serves its own machine-readable description. Sign in (session cookie or API key), then:
GET /api/docs HTML reference (self-contained)
GET /api/docs/openapi.json OpenAPI 3.1 documentAuth required. The document describes the full surface of that server, so it is not left public. Use an admin session or an API key with appropriate scopes.
Credentials
- Session — portal sign-in cookie after password / SSO / TOTP.
- API key — created in the portal; send as the server documents (typically a bearer or dedicated header on
/api/v1/…).
Areas (tags)
| Tag | Covers |
|---|---|
| setup | First start, before any account exists. |
| auth | Sign-in, second factors, sessions, SSO start. |
| profile | The caller’s own account (including TOTP enrol). |
| files | Browse and change files in a storage root. |
| transfers | Jobs and transfer tickets. |
| packages | Send files to people without accounts. |
| automation | Hot folders and scheduled one-way sync. |
| admin | Users, groups, licence, audit, settings, SMTP, SSO. |
| service | Health and the OpenAPI document itself. |
Tickets
Automation that needs a fast copy usually creates a ticket (/api/v1/transfers/ticket and related routes), then runs:
farwing cp --ticket "$TICKET" ./payload.binSee Getting started for the client side andCLI reference for --ticket-host and retry flags.