Branding and domains

By default a signer opens SignSealer's page on signsealer.com, with the business's logo, when it has one, above the document. White label puts the business's name and colors on the page, and its own domains move the links and the mail onto hosts it owns. The host is the part that changes what the API hands you.

What a business can set

All of it is set in the dashboard, under Settings → Brand, by an owner or an admin. The API reads it and has no route to change it.

White label is an add-on to the membership, $25 a month drawn from credit, and not offered on Free (pricing). A platform can put its own name on the businesses it brings, at no charge (Platforms and partners).

Where signing links point

Every link the engine sends for a business, by email or by text, and every url the API answers with, is on the first of these that applies:

1. A signing domain the business has verified: https://sign.example.com/s/{token}.
2. With white label on, its address on signsealer.com: https://yourbusiness.signsealer.com/s/{token}.
3. Otherwise https://signsealer.com/s/{token}.

A partner's branding does not change the host. POST /v1/documents/{id}/send answers a url per signer, as do the signer's /embed and /link routes: use it as given. POST /v1/workflows/{id}/start answers tokens only (with send_link, SignSealer sends the person theirs itself), so build the address from signingHost, and ask for it when you need it rather than storing it for good, because a newly verified domain moves it and white label starting or ending can:

const { signingHost } = await signsealer.branding();   // GET /v1/branding
const url = "https://" + signingHost + "/s/" + encodeURIComponent(token);

GET /v1/workflows/{id}/qr is the exception: it answers the form's address on signsealer.com, which keeps working; the same form also answers at /f/… on the business's own host.

A business's host serves only that business's signing links (/s/), party links (/p/), public forms (/f/), the certificate check (/verify), logos (/brand/) and a health check. Everything else is a 404 there, the API included: your calls, and the key-less signing routes a page of your own makes, go to https://api.signsealer.com. Another business's link on that host is a 404 too. A link on signsealer.com still opens after the business moves to its own host.

Framing the page on your own site

The embed route's url (Signing inside your product) is on the signing host too, so check a message's origin against new URL(url).origin, never a fixed https://signsealer.com.

A verified signing domain lets the page be framed on that host and the hosts under it: sign.example.com adds https://sign.example.com and https://*.sign.example.com to frame_origins, not www.example.com. To frame it on your main site, prove example.com as a company sign-in domain or connect an app that lives there. An address on signsealer.com adds nothing. The same verified domain may take a return_url (Waivers and workflows).

A signing domain of your own

With white label on, an owner or admin types a host under Your own domains (in Settings, and at the foot of Settings → Brand). Use a subdomain such as sign.example.com: a host that is a CNAME to us cannot also serve your own site. Then publish what the panel shows:

The checks run every few minutes, and the panel ticks off three stages:

Under them the panel says what the last look found: no TXT record, one without the token, or a host that did not answer as us. A serving host is not checked again; leave the CNAME where it is.

A host is refused when it is signsealer.com or under it, when it is also the sending domain, or when another business has claimed it (write to us if it is yours). Changing it starts all three stages again, and until the new one serves, links go to the next host in the list above. An empty field withdraws it.

Mail from your own domain

Mail from, in the same panel, takes a second subdomain such as mail.example.com, so its records leave your main domain's mail alone. We register it with our mail provider, and within a few minutes the panel lists the records to publish. It reads checking until the provider sees them, then in use; records not found means the provider reported a failure, and the panel gives the reason. A failed domain is asked about again hourly.

Only mail on the business's behalf changes; sign-in links, team invitations and billing mail stay SignSealer's. Inside the mail, the button goes to the signing host, and the logo and the certificate check (signsealer.com/verify) stay on SignSealer's.

White label, and a partner's branding

A business's own white label wins over its partner's. Under all three, a business's texts go from its own toll-free or local number, registered under its own name, and that is coming soon (Texting and consent); the certificate stays SignSealer's, checked at signsealer.com/verify: it is the evidence, not the branding.

Reading the brand: GET /v1/branding

Scope signing:read; signsealer.branding() in the Node client. It is what our tablet app themes itself with, and its keys are camelCase.

Without white label the answer is already SignSealer's look: the business's own name, our colours, no dark logo and no opening picture, even when the business has saved its own ready for the day it switches white label on. whiteLabelEnabled says which you have. Logos are public by address, /brand/{tenantId}/logo.png and logo-dark.png (or .svg), cached for an hour.

Webhooks

Nothing in a webhook changes with the brand or the host: a payload carries no link and never a token (Webhooks). To put a signer in front of their page after an event, mint a link with the embed route, which answers it on the current host, or send a reminder, which carries a fresh one there.