Getting access
Haven does not issue API credentials on request. Every application is reviewed by a person, and that review decides the maximum set of permissions the application may ever ask a host for. This page explains what the process is, what it asks of you, and how to build without waiting for it.
Why access is gated
An approved application can read a host's guest list and change their calendar. The blast radius of a compromised or careless integration is somebody's business, and hosts have no practical way to audit the software they connect. Review is the control that makes granular scopes meaningful: scopes bound what an application can do once a host consents, and approval bounds what it is allowed to ask for in the first place.
Practically, it also means Haven knows who to call. Every application carries a named security contact, and an integration that starts behaving oddly at two in the morning gets a phone call rather than a silent block.
The stages
An application moves through six states. Only two of them can authorize a host.
| State | What it means |
|---|---|
DRAFT | You are still filling in the application. Nothing works. |
PENDING_REVIEW | Submitted. Haven staff have it. Nothing works. |
SANDBOX | Approved for development. The full OAuth flow works against seeded test accounts. Real host data is unreachable. |
APPROVED | Live. Real hosts can authorize the application. |
SUSPENDED | Turned off by Haven, reversibly. Existing tokens stop working immediately. |
REVOKED | Terminal. |
Sandbox is not a waiting room. A client in SANDBOX completes the whole authorization flow, holds real access tokens, and calls every endpoint its scopes allow. What it cannot do is reach a real host's account. That is deliberate: Haven would rather review working software than a form, and you would rather find out how the API behaves before you are queued behind a human.
What the application asks for
Have these ready.
About the company. Legal name, the name hosts will see, your website, and two email addresses: one for support and one for security. The security address is where a disclosure or an incident notice goes, and it should reach someone who can act on it.
About the product. What it does, who uses it, and what it needs Haven for. Write this for a reader who knows the industry and has never heard of you. Specificity shortens review; a description that could describe any product in the category lengthens it.
The scopes you want, and why. Ask for what you need. An application requesting guests:read and reservations:refund for a channel-management product will be asked what for, and the answer determines whether it is granted. Narrow requests are approved faster, and you can always come back for more (see Incremental authorization).
Your redirect URIs. Every URI the authorization flow may return a host to. These are matched by exact string equality, so register the precise value your client will send. Details and the rules in The authorize endpoint.
Your expected volume. A rough monthly request estimate. This sets your initial rate-limit tier and is not a commitment.
What Haven looks for
Reviewers are asking four questions.
Is the scope request proportionate to what the product does? Does the redirect URI belong to infrastructure you control, and is it https? Is there a real security contact? And, for anything touching guest personal data or money, is there a reason this product needs it that a narrower scope would not satisfy?
Sensitive and restricted scopes need a named sign-off recorded against the application, not just an approval click. Expect a conversation about guests:read, guidebook:secrets:read, messaging:send, reservations:cancel and reservations:refund.
Certification, for production access
Moving from sandbox to live is a short technical review rather than a second wait. Haven checks that your integration does five things, all of which are documented and testable against sandbox:
Verifies webhook signatures rather than trusting the payload. Honors Retry-After on a 429 instead of retrying immediately. Sends a real User-Agent naming your product and a contact address. Sends an Idempotency-Key on every write. Re-fetches the resource after a webhook rather than treating the webhook body as the record.
Each of these is a support ticket Haven does not want to receive, and an integration that gets all five right is one that will not generate them.
After approval
Haven creates your OAuth client and shows the client secret exactly once. Store it before closing the page; it is stored hashed and cannot be recovered, only replaced. You can hold several live secrets at a time, which is what makes rotation an overlap rather than an outage.
From there, Quickstart.
Applying
Fill in the form at https://www.bookwithhaven.com/developers/apply. It asks for the material above and for the scopes you think you need — ask for what you will use, because a shorter list is approved faster and you can ask for more later without re-applying.
You will get an email when it arrives. Credentials come after review, not with the acknowledgement: submitting creates an application, and no developer, client or secret exists for it until a named member of Haven staff creates one.
If the form does not suit — you need to attach something, or your legal team wants a thread —
email info@bookwithhaven.com with the subject Public API access — <your company> instead.
Use of the API is governed by the Developer and API Terms. An administrator of your organization must accept the current version before production credentials are issued.