Trust and requester credentials

Public scheduling separates identity from permission.

Identity travels. Permission stays local.

A requester credential can prove who an external requester is. It does not grant access to the owner's calendar. The public link, meeting type visibility, audiences, allocations, and booking policy still decide what the requester can see or do.

In beta, public scheduling trust configuration is admin-only. In personal accounts, the calendar owner is also the admin. Non-admin workspace members can use the public requester flows where applicable, but they do not manage verified domains, requester identities, credentials, audiences, or allocations from the dashboard.

Overview

The trust model has four pieces:

Piece	Job
Verified domain	Proves a domain is controlled by the current customer.
Requester identity	Names an external requester, optionally tied to a verified domain.
Requester credential	A one-time secret for that identity, prefixed with rc_.
Audience	An allow or block group made from domains, identities, or pending domains.

Anonymous requesters can still use meeting types visible to everyone. Verified requester flows use a requester credential only to identify the requester.

Verified domains

Admins add a domain in Scheduling links -> Trust -> Verified domains.

Openavail creates a DNS TXT challenge. Add the TXT record to DNS, then click Check DNS.

Domain states:

State	Meaning
Pending	Challenge exists, but DNS has not been verified yet.
Verified	DNS check succeeded. This domain can be assigned to identities and used in audience rules.
Failed	DNS check failed. Fix the TXT record and check again.

Only verified domains appear as selectable domains when creating a requester identity. Pending or failed domains still appear in the domain list so you can inspect, recheck, or remove them.

Requester identities

A requester identity is an admin-managed record for an external requester, integration, partner, or team.

Admins create one in Trust -> Requester identities. The form is collapsed by default so the page can be used as a list when you only want to inspect existing identities.

Fields:

Field	Required	Notes
Display name	Yes	Human-readable name, such as QA Requester.
Verified domain	Optional	Must already be verified before it can be selected.

If no identities exist, the dashboard shows an empty state instead of opening the create form by default.

Requester credentials

Requester credentials are secrets for requester identities.

They are different from owner-agent API keys:

Credential	Prefix	Used by	What it proves
Owner-agent API key	ak_	Private owner-scoped agent APIs	The agent is allowed to act inside the owner's Openavail account.
Requester credential	rc_	Public scheduling requester flows	The external requester identity.

Admins issue credentials from Trust -> Requester credentials after selecting an identity.

The raw credential is shown once. Copy it immediately. Later, the dashboard only shows a credential reference, status, display name, created time, and revoke action.

Use a requester credential as an optional bearer token when calling public scheduling endpoints:

Authorization: Bearer rc_1234abcd_...

If the token is missing, invalid, revoked, or tied to an inactive identity, the public flow falls back to anonymous requester context.

Audiences

Audiences group requesters for meeting type visibility.

An audience has:

Field	Meaning
Name	Human-readable group name.
Behavior	allow or block.
Members	Verified domains, requester identities, or pending domains.

Use selected audiences on a meeting type when only certain partners, domains, or identities should see it.

Pending-domain members are useful when you know a domain should become part of an audience but DNS verification is not complete yet.

Allocations

Allocations expose bookable capacity for a selected public meeting type.

An allocation has:

Field	Meaning
Label	Internal dashboard label.
Window	The date/time range requesters can book from.
Booking limit	Optional cap, such as a limit per requester domain.
Status	Active or disabled.

Allocations can also feed suggested times when Show suggested times is enabled for the meeting type.

Common setup patterns

For a fully public link:

1. Create a public link.
2. Publish a meeting type with visibility Everyone.
3. Keep requester credentials optional.

For partner-only scheduling:

1. Verify the partner domain.
2. Create a requester identity for the partner.
3. Issue an rc_ credential for their integration.
4. Create an allow audience with that identity or domain.
5. Set the meeting type visibility to Selected audiences.

For a human-only public request form:

1. Publish a visible meeting type.
2. Keep auto-book off unless policy clearly allows it.
3. Use owner review.
4. Enable suggested times only if requesters benefit from seeing proposed options.