Deploying

Appending files

Subscribers can add files to a live drop by appending: send only the new or changed files to the drop’s slug, up to 10,000 files per drop. A single POST /deploy already takes all 10,000 on a paid plan, so append is for growing a drop that is already live.

On this page

The endpoint

POST

/deploy/<slug>

sp_ key or ID token

Adds the request body’s files to an existing drop you own. All three body formats work, and the ?ttl= story doesn’t change — appended files inherit the drop’s existing expiry and password protection. Paths that already exist on the drop are overwritten.

bash

curl -X POST https://ship.page/deploy/vast-juice-c2dse \
  -H "Authorization: Bearer sp_QffDmo0…" \
  -H "Content-Type: application/zip" \
  --data-binary @assets-batch-2.zip

json200 OK

{
  "slug": "vast-juice-c2dse",
  "url": "https://vast-juice-c2dse.ship.place/",
  "files": ["img/photo-901.webp", "img/photo-902.webp", …],
  "total_files": 1800,
  "plan": "pro",
  "expires_at": null
}

total_files is the running count after this batch — handy for scripting big uploads.

Status	Description
401`unauthorized`	No credential. Appending always needs an API key — see Authentication.
402`payment required`	Valid key, but no active subscription.
404`not found`	The slug doesn’t exist — or belongs to someone else. Ownership is never disclosed.
400`bad request`	No files, more than 10,000 in one batch, or an unparseable body.
413`payload too large`	This batch would push the drop past 10,000 files total, or the body breaks the usual zip and size caps from Deploy a drop.
429`rate limited`	120 deploys/min per account on paid plans. 429s carry Retry-After: 60 — back off and retry.

Scripting big asset trees

File count alone never needs a split: one request takes up to 10,000 files. A build over the 100 MB zip cap does: split it into smaller zips and loop. The first batch goes to POST /deploy, every following batch to POST /deploy/<slug> with the slug from the first response.

Last updated Jun 12, 2026