Tokens, scopes & the sandbox

Personal tokens

An owner makes a token in Settings → Developer for their own scripts and automations: a name, the scopes it may use, and an expiry of 30, 90 or 365 days. It is shown once. Daysli keeps only its SHA-256 and last four characters, so a lost token cannot be recovered — make a new one and revoke the old.

Authorization: Bearer dsl_pat_…

Revoking a token stops it on its very next call; it is checked in the database every time.
The owner is notified on their devices whenever a token is made, so one they did not make is noticed.
Deleting the account revokes every token first. Recovering the account does not bring them back.
Daysli’s own sign-in tokens are refused by the API, and API tokens are refused by everything else.

What each credential looks like

Prefix	What it is
`dsl_pat_`	Personal token, live
`dsl_test_`	Personal token, test mode (the sandbox)
`dsl_whsec_`	A webhook endpoint’s signing secret

The prefixes exist so a leaked credential is recognisable. If you find one in a log or a repository, revoke it.

The sandbox: test tokens

A test token (dsl_test_) is the same API over the owner’s own data, with one difference that matters: nothing it creates can reach a real person.

Requests it sends never email the requester, whatever notifyRequester says, and arrive in the owner’s inbox marked Test.
GET /me answers "mode": "test", and every webhook it receives carries "test": true, so your code can tell.
Rate limits are the same, so what works in the sandbox works live.

Build against a test token, then make a live one with the same scopes. Nothing else changes.

Scopes

A token can do only what its scopes allow, and the owner chose them. A missing scope is 403 insufficient_scope, with the scope named in WWW-Authenticate.

Scope	What the owner reads	Never included
`profile:read`	See your name, username and timezone	Email address, bio, settings.
`availability:read`	See your appointment types and when you’re free	Why a time is not free; event titles; which calendar is busy. Nothing while booking is off.
`events:read`	See your calendar events and appointments	Notes, participants, busy time imported from other calendars, repeat rules.
`tasks:read`	See your to-dos	Requesters’ contact details.
`requests:read`	See requests people send you	Requesters’ email, phone and handles (they need requests:contact); owner-side states.
`requests:contact`	See the email and phone number of people who send you requests	—
`requests:create`	Send requests to you, which you accept or decline	Any direct change to the calendar or to-dos; other tokens’ requests.
`webhooks`	Be told when these things change	Events for scopes the token does not have.

requests:contact goes with requests:read and means nothing on its own. And beside every token, the owner reads the same fixed line: “Tokens and webhooks can never see your journal.”

Account ids

accountId (acct_…) identifies the owner to your integration and never changes. It is derived for your integration alone, so two different apps never see the same id for the same person. Store it to tell owners apart; do not try to parse it.

Apps for other people

Personal tokens are for an owner’s own automations. Apps that other Daysli owners connect through OAuth are designed (PKCE, per-app consent, revocation in Settings → Connected apps) and open once the Developer Terms are published.