Haven vs Town

Haven

Haven answers by phone call, text, email and app, is free in beta with no card, and publishes a status page with dated incidents. No public page read says which actions need approval, which accounts it connects or how their tokens are kept, and it names no model provider or sub-processor.

Town

Town is a hosted assistant that works across the owner's mail, calendar and work apps, and other systems can start its routines through per-routine webhooks with rotatable secrets, idempotency keys and documented errors. A caller can't read a run's result. The privacy policy and trust page disagree on whether training is on by default.

Haven

1. Haven has no documented API or MCP server. An outside agent can reach it only through the owner's channels (call, SMS, email, app).
2. Do not assume an approval step before Haven sends mail, texts or calls. None is documented on the public pages.
3. Email Haven sends to other people names Hello Haven as sender and says it was sent on the user's behalf, per the terms.
4. Chat messages, history, profile context and uploaded files go to third-party AI model providers that the vendor does not name.
5. Check status.hellohaven.ai before relying on phone or voice. All four published incidents affected those channels.

Town

1. Start a Town routine with POST to its webhook URL, Authorization Bearer whsec_ secret, and application/json or text/plain. Expect 202 only.
2. Send X-Town-Idempotency-Key with a stable event id on every retry so Town doesn't start a second run.
3. Treat 404 as wrong secret, disabled endpoint or missing endpoint alike, and ask the owner to check Routine Settings rather than retrying.
4. Send account_email only if the owner allowed the override. It must match a connected account in full and can't widen the routine's scope.
5. Ask the owner to keep routines that act on webhook input in approval-required mode, as Town's own docs advise.