Developers

Four endpoints are the product

Twenty-one exist; the rest are operations. The OpenAPI document is generated from the running app and checked in CI, so it cannot drift.

Base URL      https://your-host/v1
Tenant auth   Authorization: Bearer hebb_<key-id>_<secret>
Operator auth X-Admin-Key: <admin key>
Errors        application/problem+json, RFC 9457, with a request_id

Teach one rule

curl -X POST https://host/v1/rules \
  -H "Authorization: Bearer $KEY" \
  -H 'content-type: application/json' \
  -H 'Idempotency-Key: change-4711' \
  -d '{"slot": "refund window", "value": "60 days"}'

There is no tenant parameter

The key identifies the tenant. This is the central design decision, not an omission: an endpoint accepting {"tenant": "..."} would be one forged field away from serving another customer's data, and no amount of checking in the handler fixes it, because the caller controls the value being checked.

A test walks the route table and fails if any tenant-scoped route ever grows a tenant field.

Access

There is no self-serve sign-up yet, so there is nothing to sign in to. Access today means a key issued by hand, against a self-hosted deployment. Ask for one and say what you are building — that is the whole process.

Compatibility

An OpenAI-compatible shim ships with the server, so trying Hebb against an existing integration is a base_url change rather than a rewrite.