For developers
A real REST API, in every installation
ProjectSend ships with a JSON REST API: list and download files, upload new ones, share them with clients and groups, and manage accounts — from your own scripts and tools, with tokens that never do more than you allow.
- Base URL
- https://your-install/api/v1
- Authentication
- Bearer tokens with scopes
- Specification
- GET /api/v1/openapi.json
- Contract
- v1 is frozen — additive changes only
Three steps to your first call
- 1
Create a token
Sign in and go to Settings → API tokens. Tick only the permissions the tool needs and give it an expiry. Copy the token immediately — it is shown once and only a hash is stored.
- 2
Call /me
The first call worth making: it tells you who the token belongs to, which abilities it effectively has, which edition the installation runs, and which optional modules are available.
- 3
Import the spec
GET /api/v1/openapi.json is public by design — a client needs the specification before it has a token. Import it into Postman, Insomnia or a code generator; every operation names the ability it requires.
Your first request
curl -H "Authorization: Bearer YOUR_TOKEN" \
-H "Accept: application/json" \
https://your-install.example.com/api/v1/meEndpoints
What you can automate
The API mirrors the web interface: the same permissions, the same boundaries, the same behavior.
Files
Upload, list, download and delete files, manage versions, set expiration dates and download limits. Uploads go through the same resumable, chunked pipeline the web interface uses.
Sharing
Assign files to clients and groups — or remove access — with the same rules as the web sharing tab.
Clients & groups
Create, edit and delete client accounts and groups, and manage group membership.
Comments
Read and write comments on files, and work the moderation queue when you hold that permission.
Staff & roles
Create and manage staff accounts, and list the roles you are allowed to assign.
Activity
Read the activity feed — what happened, not just what exists now. Together with updated_since filters on every list, it is the supported way to react to changes.
Optional modules add their own endpoints under /api/v1/modules/{module} — same authentication, same rules. GET /api/v1/me lists the modules an installation actually carries.
Scoped by design
A token never does more than you allow
Every request checks three things: the token carries the ability, its owner still holds the permission today, and the edition has the feature. The mechanisms are concrete:
Live permission checks
Abilities are granted per token and re-checked against the owner's account on every request — a demoted account's token loses the ability immediately, without anyone revoking it.
Expiry by default
Tokens expire after 90 days unless you choose otherwise, up to a year. “Never expires” exists but is off by default.
No passwords on the API
There is no password-login endpoint. Tokens are created in the web interface by a signed-in person who confirmed their password — passwords stay off the API entirely.
Per-token rate limits
Each token gets its own allowance, so one integration cannot exhaust another's. Every response carries X-RateLimit headers, and a 429 tells you when to retry.
Errors you can branch on
Errors are RFC 7807 problem documents with a stable type slug — validation_failed, forbidden, too_many_requests — so your code branches on a contract, not on prose.
A frozen contract
/api/v1 only changes additively: new endpoints, new optional parameters, new response fields. Breaking changes would arrive as /api/v2, announced with Deprecation and Sunset headers first.
Where it stands today: v1 is staff-only — client accounts cannot hold tokens — and webhooks are not built yet. Polling with updated_since and the activity feed are the supported way to react to changes.
Documentation
Everything is written down
The guides travel with each release — and are published on this site, pinned to the version you download.
API guide
The narrative guide: authentication, abilities, pagination, polling, uploads and versioning — everything the specification does not say in prose.
Read the guide
OpenAPI specification
Served live at /api/v1/openapi.json on every installation, and committed to the repository so you can diff it between releases.
Browse the spec
Zapier, Make & n8n
There is no official Zapier app yet, but you do not need one: the API works with Webhooks by Zapier today — and with Make, n8n, Pipedream or anything that can call an HTTP endpoint.
See the recipes
Module endpoints
How optional modules mount their own API surface under /api/v1/modules — the same pattern available to anything built on the extension system.
Read about modules
The same API, wherever ProjectSend runs
Install ProjectSend on your own server — free forever under GPL v2 — or let ProjectSend Cloud handle the hosting. The API travels with both editions.