Onboard a Customer
Take one company live end to end, from naming it to a first endpoint that answers, with checks anyone can repeat.
On this page (7)
Onboard a Customer Documentation
This takes one company live. At the end, that company's first endpoint holds a routable IPv6 address out of Whisper-held address space, published in public DNS and in the public registry, and anyone can verify it with no key and nothing installed on the machine.
Before you start
Your role has to carry the provision capability; your team and roles says which roles do. The book also has to be readable. The page will not add a company while the book cannot be read, because it cannot then check whether that company is already there, and a duplicate splits one company's endpoints across two rows.
Step 1: name the company
Enter the company name and choose its adoption shape: one account for the whole company, or an account for each person who works there. An email domain is optional and is recorded beside it.
The portal records the customer through the control plane's partner operation, as op:'customer.add'. The new row appears in the book immediately, carrying nothing yet.
Step 2: grant an account
Name the Whisper principal whose estate the endpoints will live in. The portal records the grant as op:'grant.add'.
The authority itself is that account's own key, which looks like whisper_live_... and is supplied in the custody panel on the customer. The portal resolves which account a key belongs to on the server, stores it there, and does not show it again; it never reaches your browser. Customer keys and grants covers what that authority is, what it can see, and how the customer ends it.
Step 3: register the first endpoint
The step mints a resolve-only device credential and its address, and shows the result once:
| column | what it holds |
|---|---|
token | the device credential |
doh_url | the encrypted-DNS URL for this device, with the token inside it |
dot_host | the DNS-over-TLS host name to paste into a device's private DNS setting |
resolver_ip | the account's dedicated resolver address, when it has one |
address | the endpoint's routable IPv6 /128 |
label | the name you gave it |
Capture the token before leaving the page. Treat doh_url as a password: the token is inside the URL, and anyone holding it resolves names as that device.
Hand the customer whichever deploy option fits the machine: the encrypted-DNS URL, the DNS-over-TLS host name, or the resolver address when the account has a dedicated one. Set up a device has the per-platform steps.
Step 4: watch it check in
The page polls the customer's fleet and shows the new row. Registered is not reporting: the row only goes green once it carries an actual observation, so a row that stays registered with nothing behind it means the device holds the credential and is not sending its lookups through it.
Step 5: hand the customer the checks
These run from any machine, with no key and no account here. Substitute the address and the name from step 3.
dig -x 2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478 +short
dig <the endpoint's name> AAAA +short
curl -s https://rdap.whisper.online/ip/2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478
The first two must agree: the reverse lookup returns the endpoint's name, and that name resolves back to the same address. The third returns the public registry record for the allocation. A customer who runs all three has verified the identity without trusting your screenshot, and verify an identity is the page to send them to.
Where the customer goes next
The estate now appears in the queue with everything it is carrying, and its resolver answers under the policy you set for it. To put a sensor on a machine in that estate rather than a resolve-only credential, start at endpoint security.