Expiry

Where the deadline lives

Every expiring drop carries its deadline as object metadata, and the deploy response’s expires_at echoes it (null means never). While a drop is live, the deadline is also exposed on every response via the x-drop-expires header:

curl -I https://vast-juice-c2dse.ship.place/
HTTP/2 200
content-type: text/html;charset=utf-8
cache-control: public, max-age=60
x-drop-expires: 2026-06-19T14:00:00.000Z

Past the deadline

At the deadline every expiring drop answers 410 Gone. An anonymous drop remains privately claimable: whoever holds its spc_... claim token can recover it (dashboard → Drops → claim, POST /drops/<slug>/claim, or the claim_drop MCP tool) onto their account, where it stays expired until it's restored. Owned drops stay restorable: on Pro the owner can restore from the dashboard or via POST /drops/<slug>/restore, and a restored drop doesn't expire while they're on Pro. There's no deadline for claiming or restoring. The endpoints behind all of this live in Managing drops.

Warning emails

Signed-in accounts get one email about 48 hours before an owned drop expires, with its expiry time and how to keep it online. A redeploy or claim starts a fresh drop lifetime and a fresh warning. Toggle it under dashboard → Settings → Drop-expiry reminders (on by default). Drops without an expiry never trigger one.

Cleanup

Every expired drop serves 410 from the deadline on; only a restore on Pro can bring it back.

Keeping things alive

Claiming an anonymous drop before its deadline gives it a 30-day free-account lifetime; claimed after it expires, it joins your account expired. Owned drops that already expired can be restored on Pro, and then never expire. Beyond that there's no "extend" call; redeploy with a fresh ?ttl= instead. Claiming extends a lifetime but does not make a page permanent; removing expiry entirely is a paid named-drop feature. Subscribers redeploying a named drop keep the same URL while resetting content and lifetime in one shot.