Deploying
Appending files
A single deploy request caps at 100 files on the free plan and 900 on paid plans — every stored file is one subrequest, so the 900 sits just under Cloudflare’s per-invocation ceiling. Subscribers go past it by appending: create the drop with POST /deploy, then keep adding batches to the same slug until the drop holds 10,000 files.
The endpoint
/deploy/<slug>
sp_ key or ID tokenAdds 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.
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{
"slug": "vast-juice-c2dse",
"url": "https://vast-juice-c2dse.shipped.run/",
"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 |
|---|---|
401unauthorized | No credential. Appending always needs an API key — see Authentication. |
402payment required | Valid key, but no active subscription. |
404not found | The slug doesn’t exist — or belongs to someone else. Ownership is never disclosed. |
400bad request | More than 900 files in one batch, or an unparseable body. |
413payload 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. |
429rate limited | 120 deploys/min per account on paid plans. 429s carry Retry-After: 60 — back off and retry. |
Scripting big asset trees
Split the build into ≤900-file zips and loop: the first batch goes to POST /deploy, every following batch to POST /deploy/<slug> with the slug from the first response. At 900 files per request, a maxed-out 10,000-file drop is 12 requests.
Last updated Jun 12, 2026