Happy Hear Audio

Connector

Changelog

Every change to the connector that a client developer could notice: a new or changed action, a limit, an authentication detail. Additive changes ship without notice; a client should ignore unknown fields. Anything that removes or renames a field or an action is announced here first. The operator-facing product changelog is at /changelog.

  1. HTTP API (v1, read-only) with operator API keys

    • GET /api/v1/… exposes the seven read actions over plain HTTPS with Authorization: Bearer hha_live_… keys created in Settings, Account, API keys. Monthly plan; up to 5 active keys; 60 requests a minute per key with X-RateLimit-* and Retry-After headers.
    • Each endpoint runs the same operation as the connector action of the same name, so the two doors return identical fields and the same no-PII rule applies.
    • /api/v1/openapi.json describes it in OpenAPI 3.1, generated from the same schemas; /developers/api and /developers/api/reference document it.

  2. Developer documentation and a machine-readable tool list

    • This section (/developers) went live: one page per action generated from the server's own tool registrations, plus limits, errors and this changelog.
    • /developers/connector/tools.json describes every action in JSON Schema, the same shapes tools/list returns, so a client or a code generator can read the connector without connecting.

  3. Five read actions added

    • get_event_audio_status: counts by state and a one-line-per-message list for one event.
    • list_events_needing_attention: account-wide check for failed messages or messages cleaning for more than 30 minutes.
    • get_gallery_link: the share link and whether a share code is required (never the code).
    • get_gallery_stats: visitors, plays, downloads, sent flag and first-opened date.
    • get_plan_and_usage: plan, subscription status, paid-through date, free event status and event count.
    • All five are read-only (readOnlyHint: true) and uncapped beyond the per-minute request limit.

  4. Daily caps on the three write actions

    • Per operator, rolling 24 hours, the same on every plan: start_cleaning 30, create_event 10, update_event 50.
    • Past the cap the tool changes nothing and returns a plain-text refusal with isError: true. The refusal is logged and does not count toward the cap.
    • A watcher reads the action log every 15 minutes and flags a looping client.

  5. Any MCP client can register itself

    • Dynamic Client Registration (RFC 7591) is on at the authorization server, so ChatGPT and any other compliant client connects with the server URL alone.
    • The consent screen accepts any https redirect URI that the client registered, and shows the operator the host it will return them to.
    • The pre-registered public client for Claude keeps working and stays documented.
    • Browser-originated requests are allowed from claude.ai, chatgpt.com and chat.openai.com in addition to our own hosts. Server-side clients send no Origin and were never affected.

  6. Connector launched

    • Remote MCP server at https://www.happyhearaudio.com/api/mcp over Streamable HTTP, OAuth 2.1 resource server with RFC 9728 protected-resource metadata.
    • Five actions: search_events, get_event, start_cleaning, create_event and update_event (name and date only).
    • Reads go through two allow-listed database views that carry no guest audio, transcript, phone number, speaker name, password, storage path or signed URL.
    • Writes run through the same functions the dashboard uses, scoped to the signed-in operator, and each one is logged.
    • Available on every plan, including the free first event.

Stability promise

  • Action names and parameter names do not change once published. A replacement ships alongside the old one before the old one goes.
  • New fields can appear in any result at any time. New actions can appear in tools/list at any time.
  • Removing an action or a field is announced here with at least 30 days of notice, best effort.