curl, including a coding agent, can ship your
project without extra tooling.
Get a key
Create a project in the dashboard and copy its API key. Keys are scoped to one application, so the key itself identifies where the code goes; you never pass an application id.Deploy
Run this from the project directory. Send the whole tree, not just the entry point.Response
files is the manifest of what was actually stored, capped at 50 entries with
the remainder counted in filesTruncated. Check it. If you expected a
project and see one file, the upload was wrong.
An identical push returns 200 with {"status": "unchanged"} and builds
nothing. Add -F "force=true" to rebuild anyway.
Send environment variables
.env-formatted string or a JSON object. Applied to the deploy in
the same request.
Poll to completion
status is succeeded or failed. The response carries per-step
progress, the analyzed spec, and two fields worth reading rather than ignoring:
warnings: things that will work but probably aren’t what you meant. Missing referenced assets, no lockfile, two deployables in one repository.hazards: structured facts about what won’t work once live. Uploads written to a temporary disk, scheduled tasks that never fire.
If you are an agent reporting back to a user: relay warnings and hazards. A
deploy can be
succeeded and still not do what its author expects, and the
person who asked you to ship has no other way to find out.Alternative: per-file form
Supported for existing clients. Onefiles part and one paths part per
file, in the same order.
paths_mismatch rather than silently
flattening your directory structure. Prefer archive: it cannot get this
wrong.
Errors
Every error includes a
documentation URL.
Limits
Build output and dependency directories (
node_modules, .git, dist,
.next) are excluded server-side regardless of what you send.