Blue Banana EHR

1. Sign up at /signup with email + password. A personal tenant dev-<id> is created automatically and seeded with three near-future demo Appointments.
2. Mint an API key on /account (name it e.g. scratch). Copy the full bb_… value — you only see it once.
3. Read John Smith with an Authorization: Bearer bb_… header. Your tenant is derived from the key — no second header to remember.

   curl -H "Authorization: Bearer bb_…" \
        "https://bluebananaehr.com/api/fhir/r4/Patient/eb1f768e-226a-c047-0f2f-8331341167c2"

   You'll get a FHIR Patient resource with name: John Smith. Swap /Patient/{id} for /Patient/{id}/$everything to pull his complete chart. Successful responses echo the resolved tenant in X-EHR-Tenant-Resolved.

Prefer not to copy-paste curl? Open the playground — the same six requests are click-to-run cards with a key auto-minted for you.

Each API key is bound to one tenant — your private dev-<id>, auto-minted at signup. You do not pick a tenant per request; the key picks it for you.

• Reads return the union of your overlay and the shared canonical seed pool. On day zero you already see ~1,000 patients including John Smith.
• Writes (POST / PUT) land in your overlay only — invisible to other tenants. Edits to seed patients never leak.
• Deleteson a seed resource tombstone it in your overlay (gone for you, intact for everyone else). On a tenant-only resource, it's a hard delete.

Every error is a FHIR OperationOutcome. Common cases:

• 401 — missing/invalid Authorization header or revoked key.
• 403— your key resolves but you're asking for a tenant you don't own.
• 404 — resource not in your overlay or the canonical pool.
• 422 — malformed FHIR body (validation failure).
• 429 — rate or write-quota exceeded. The response carries a Retry-After header.

Two layers cap traffic. Every successful response carries X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset (Unix epoch seconds for the per-key window).

• Per API key — 30 req/min for user-named (production) keys, 10 req/min for the playground key auto-managed by /docs/api. Limits the blast radius of a leaked key.
• Per tenant — 50 req/min across all keys, 200 lifetime writes, 20 LLM calls/hour.
• Synthetic data only — never use this for clinical decisions or anything claiming HIPAA compliance.

The full schema for every endpoint lives in the API reference (Scalar, with a Try It panel). The working surface today is FHIR R4 CRUD on 31 resource types at /api/fhir/r4/* (Patient and Appointment have their own groups with prefilled examples), plus webhook subscriptions at /api/subscriptions and intake forms at /api/intake/*. All three accept bearer-API-key auth.

The agent runtime stays documented for forward compatibility but is not currently working for external developers — see the “Other” section below.

The following surface is documented for forward compatibility but is not currently workingfor external developers using a bearer API key. Don't build against it yet — it will be promoted back into the main reference once the underlying issues are fixed.

For agents and tooling, Blue Banana exposes machine-readable artifacts:

• /openapi.json — OpenAPI 3.1 spec for every documented endpoint and webhook.
• /llms.txt and /llms-full.txt — the llms.txt convention.
• /api/fhir/r4/metadata — live FHIR CapabilityStatement.