PUBLIC API
Publish from a script with the API
A small REST API for creating sites, uploading a deployment and reading what happened, with an OpenAPI description you can generate a client from.
Free plan, free SSL, no credit card.
Plan availability
Which plans include public API
Raw API tokens start on Pro. The first-party extensions sign in separately and work on every plan.
- Free Not included
- Starter Not included
- Pro Included
- Business Included
- Enterprise Included
Read from the plan records this account is billed against, not from a page someone wrote, so it cannot disagree with what happens when you click the button. See every plan and its limits.
What it does
The same publish, without the browser
A token, a POST with your build, and the site is live. It is the dashboard's publish path with a different front door.
You create a token in the dashboard, then call the API to list your sites, create one, and upload a deployment to it. The response tells you the live address and what state the deployment is in, so a script can wait for it rather than guessing. The whole surface is described in the API reference and in a machine-readable OpenAPI 3.1 document, which is enough for most generators to produce a client without you writing one.
The obvious use is a release step: your build runs wherever it already runs, and the last line publishes the output here. That is deliberately different from a Git integration. We do not watch a repository and we do not run your build, so nothing here needs access to your source; you build where you already build and hand us the folder. Rate limits are per plan and per token, so a runaway loop in a script hits a ceiling rather than your bill.
How to use it
Three steps
-
Create a token
Tokens live in the dashboard under API tokens, and each one is named and revocable on its own.
-
Call the API
Create a site if you need one, then upload your built folder as a deployment. The reference has the exact calls.
-
Read the result
The response carries the live address and the deployment state, so your script can fail loudly instead of assuming it worked.
Where it earns its keep
When people reach for this
A release step at the end of your build
The last command in your pipeline publishes the output. See the framework build guides for what each toolchain writes and where.
Publishing generated reports on a schedule
A nightly job that renders HTML and posts it, so the same address always has yesterday's numbers on it.
A tool of your own that hands users a link
An internal generator that needs somewhere to put its output. Publish through the API and give the person a URL instead of a download.
The alternative
Doing this without us
The comparison that matters is not another API, it is the Git-based platforms this deliberately is not.
| Droply | A Git-connected platform | |
|---|---|---|
| What triggers a publish | Your call, whenever you decide. | A push to a watched branch. |
| Access to your source | None. We never see the repository. | Repository access is the integration. |
| Where the build runs | Wherever it already runs. | On their builders, in their environment. |
| Publishing without a repository at all | Normal. There is no repository in the model. | Usually needs a CLI path instead. |
| What you send | The finished folder. | The source, plus a build configuration. |
Compared against the Git-integration model used by the developer platforms, not against a specific vendor. Checked September 2026.
When this is not the right tool
This publishes static output. It is not a build service and it is not a general file API.
- There is no Git integration, no webhook on push and no build step. You build, then you upload.
- It serves what you upload. It cannot run server-side code, so an API that needs to execute your application is out of scope.
- Raw tokens are a paid feature. If all you want is to publish from an editor or a browser, the VS Code extension does that on every plan.
- Rate limits and plan limits apply to API calls exactly as they do in the dashboard.