Share links

A share link hands one specific deployment to someone who has no deploybase account: a client, a designer, a stakeholder who wants to look before you promote.

https://app.deploybase.eu/draft/0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef

The token is 64 random hex characters. The example above is deliberately not random, so do not expect yours to look tidy.

Create one

From the dashboard, open any deployment and press Share. Or:

curl -X POST https://api.deploybase.eu/api/v1/draft-shares \
  -H "Authorization: Bearer $DEPLOYBASE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "deployment_id": "'"$DEPLOYMENT_ID"'",
    "password": "correct-horse-battery",
    "expires_in": "7d"
  }'

Field	Required	Notes
deployment_id	Yes	Must be deployed. A failed or in-progress build has no files to share
password	No	Minimum 8 characters. Viewers get a password form before the site
expires_in	No	24h, 7d or 30d. Omit it and the link does not expire

The deployment does not have to be one that was ever in production, and promoting or rolling back does not affect the link. It stays pinned to the deployment you created it from.

With a password, and without

The two cases behave differently, and the difference matters when you are deciding what to send:

With a password, the site is proxied through the deploybase backend. Viewers enter the password once and get a cookie that lasts an hour, after which they enter it again. Nothing reveals where the files actually live.

Without a password, the response also carries a CDN-direct address, which is what makes an unprotected share fast. It is unguessable, and it is not proxied.

Either way the viewer sees no project name, no dashboard and no way into your account. If the content is genuinely sensitive, set a password: that is the case that keeps everything behind the backend.

Revoke one

curl -X DELETE "https://api.deploybase.eu/api/v1/draft-shares/$SHARE_ID" \
  -H "Authorization: Bearer $DEPLOYBASE_API_KEY"

Revocation takes effect on the next request to us, including for someone who already entered the password. Their browser may serve pages it has already loaded for up to five minutes. If you need someone to lose access with certainty and immediately, revoking is not sufficient on its own.

Share link or preview URL?

Both point at a deployment. They are for different audiences.

	Share link	Preview
Created	By you, deliberately	Automatically, on every push to a non-default branch
Points at	One fixed deployment, forever	Whatever built most recently on that branch
Password	Optional, one per link	Optional, one per project, covering every preview. See who can open previews
Expiry	Optional	Lives until the branch is redeployed or deleted
Good for	Sending one agreed build to someone outside the team	Your team reviewing work in progress

The distinction that usually decides it: a preview URL moves under you. Push again and whoever holds the link sees the new build. A share link is pinned to the deployment you created it from, which is what you want when a client is reviewing something specific.

Limits

The number of active share links depends on your plan, starting at 3 on Free and unlimited on paid plans. Revoking a link, or letting one expire, frees the slot. Current limits are on the pricing page.

Expired and revoked links are deleted a week later, so they disappear from the list on their own.

A share link points at one deployment, so it lives as long as that deployment does. See how long deployments are kept.