Authentication

Integrations authenticate with a long-lived API key, sent as a bearer token on every request. Keys are created in the OpenHouse app and can be revoked at any time.

API keys

An administrator creates keys under Settings → API keys in the OpenHouse app. The full secret — it starts with oh_ — is shown exactly once, at creation: store it in your secret manager, because it cannot be retrieved again. Send it on every request:

curl -s https://openhouse-api.6drei2.com/ingest/contacts \
  -H "Authorization: Bearer oh_..." -H 'Content-Type: application/json' \
  -d '{"records": [...]}'
  • Keys don't expire — they work until an administrator revokes them, and revocation takes effect on the very next request.
  • A key is scoped to one organization and acts with the role it was given at creation — operator by default, which covers everything in this documentation. An administrator can change a key's role later under Settings → API keys; the change applies from the key's next request.
  • Every action a key performs appears in the organization's audit log under the key's own name — give each integration its own key, so the trail stays readable and one credential can be rotated without touching the others.
  • A missing, malformed or revoked key is a 401; an action above the key's role is a 403.

Alternative: signing in as a user

For one-off scripts you can authenticate as a real user instead. Note the token is short-lived — 15 minutes — which is fine for a script that signs in and runs, and wrong for anything long-running: use an API key for those.

POST/auth/login
email
string
The user's email address.
password
string
The user's password.
curl -s https://openhouse-api.6drei2.com/auth/login \
  -H 'Content-Type: application/json' \
  -d '{"email": "you@your-org.com", "password": "..."}'

# 200 →
{ "token": "eyJhbGciOi...", "user": { "email": "...", "role": "operator", ... } }

Send the token as Authorization: Bearer <token>. Sign-in is rate-limited (5 attempts per minute), and invalid credentials are a 401.

A dynamic CRM. Your audiences, campaigns and reports keep up.

Customer data, analysis and campaigns usually live with three vendors, and an agent cannot run an account whose pieces do. In OpenHouse they are one product, so a question becomes a segment becomes a campaign, in one conversation.

Customer data platform

Events from the shop, the app and payments land in one profile per customer. Attributes and segments are derived from them.

CRM with a design studio

Campaigns and automations run on those segments. Emails are designed in the same place, on the brand.

Self-service BI

Anyone on the team asks a question of the customer base and gets the chart. Dashboards are described, not built.

Let’s talk.

Access is by invitation. If your team already runs a workspace, an administrator there can invite you. Otherwise, request a demo and we will set one up with you.