Support and status
Getting help
Include the correlation id of a request that demonstrates the problem. It arrives on every response as X-Haven-Request-Id, and on failures as error.requestId. It identifies your exact request in Haven's logs, and its presence usually turns a day of back-and-forth into a single reply.
Also include your client_id, the operation or endpoint, and roughly when it happened. Do not include an access token, a refresh token or a client secret. Support never needs one, and sending one means rotating it.
Log this
Log X-Haven-Request-Id on every non-2xx response, next to the account and the operation. Integrations that do this get answers quickly. Integrations that do not end up describing symptoms.
Also worth keeping: the scope value from your most recent token response, and the scopes array from your last /me. When something starts returning 403, the first question is what your token actually holds, and the second is when it changed.
Reaching you
Your application carries two addresses and they are used differently.
The support address is where routine correspondence goes and may be a shared inbox.
The security address is for disclosures and incidents, and should reach someone who can act within hours. If Haven has to suspend your application at two in the morning because of a credential leak, this is the address that gets the call. A monitored alias beats a person who might be on holiday.
When Haven contacts you
Deprecation. Breaking changes are announced with a Deprecation header on affected responses and a Sunset date, plus an entry in the Changelog and an email. The header arrives long before the date.
Abnormal traffic. A sudden change in volume or error rate gets an email before anything blunter happens. This is the reason User-Agent is enforced.
Suspension. Rare and reversible, used for incident response. Your calls return 403 with partner_suspended and the token endpoint returns invalid_client.
Status and incidents
Haven does not yet publish a status page for the public API. Until it does, info@bookwithhaven.com is the channel for both directions, and an incident affecting partner traffic is emailed to security contacts.
What to monitor on your side
Four signals catch most problems early.
Your 429 rate, which tells you whether you are near a ceiling before you hit it. Your invalid_grant rate on refresh, which is hosts disconnecting and is normal at a low level and a problem in a spike. Webhook signature failures, which should be zero and mean either a rotation you did not handle or something sending you forged deliveries. And the age of your oldest unprocessed webhook, which is the earliest indication that your handler is falling behind.