Skip to main content
Antideploy has no CLI to install. Deploys are a single HTTP request, which means anything that can run curl, including a coding agent, can ship your project without extra tooling.

​
Get a credential

You have two options, and which one you want depends on who is driving. An agent is doing the work. Let it run the terminal login. It gets an account token, creates the application over the API, and deploys, all without you copying anything. You approve one browser prompt the first time and never again. You are doing it by hand, or setting up CI. 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.
Either credential can deploy and write environment variables. Treat both like deploy credentials. Secrets are write-only over the API: nothing, including a valid credential, can read values back.
An account token is entitled to more than one project, so it must name the one it is acting on: ?applicationId=<id> on /api/v1/deploy and /api/v1/secrets. Every example below uses a project key, which does not.

​
Deploy

Run this from the project directory. Send the whole tree, not just the entry point.
Pushing only index.html (or any single entry file) succeeds. It builds, deploys, and serves a page whose scripts, styles and images all 404. This is the most common mistake on this API. Antideploy warns you when a page references files that were not in the upload, but the deploy still goes through; check the files array in the response.

​
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.
Nothing is dropped silently. A file over the per-file limit fails the whole push with 400 too_large and names it in a files array, so a 202 means every file you sent is in the build.
An identical push returns 200 with {"status": "unchanged"} and builds nothing. Add -F "force=true" to rebuild anyway.

​
Send environment variables

Accepts a .env-formatted string or a JSON object. Applied to the deploy in the same request.

​
Poll to completion

Poll until 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. One files part and one paths part per file, in the same order.
Mismatched counts are rejected with 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.

​
Machine-readable contract

Returns the whole contract as JSON: endpoints, request shapes, error codes and current limits. No key required. If you are an agent that has been handed a key and nothing else, start here.