Reliability patterns
Design Hyponema integrations with normal production API reliability patterns. This page is conceptual and does not define exact response schemas or status-code matrices.
Errors
Section titled “Errors”Treat errors as structured signals your backend can log and recover from. Preserve request identifiers when available so support and observability review can connect your application logs with Hyponema traces.
Common operator-facing causes include missing provider keys, unavailable voice catalog data, empty knowledge, unavailable traces, billing interruptions, and wallet-era entitlement limits.
Rate limits
Section titled “Rate limits”Rate limits protect shared infrastructure and workspace usage. On throttling, slow down, retry later, and avoid tight retry loops. Review Billing and expected traffic before launching high-volume sessions.
Idempotency
Section titled “Idempotency”Use idempotency for backend operations where a retry might otherwise create duplicate work. This is especially important around session setup, outbound actions, and other mutation flows.
Pagination
Section titled “Pagination”List-style API surfaces should be consumed page by page. Do not assume the dashboard and the API return every record in one response. Store cursors or continuation state according to the current API contract.
Versioning
Section titled “Versioning”Build against the documented current API version for your workspace. Avoid relying on hidden dashboard endpoints, internal route names, or redirect-only URLs.