API

The application exposes a tRPC API under:

/api/trpc

There is also a plain runtime health endpoint:

GET /api/health

and a signed Paddle webhook endpoint:

POST /api/webhooks/paddle

Public SMART key discovery is exposed at:

GET /.well-known/jwks.json

Authentication

Most product procedures use protected tRPC procedures and resolve organization/client authorization before domain work.

Session/authentication is integrated with Clerk in the configured production path.

Major API namespaces

The current appRouter includes namespaces for:

organizations, billing, hospitalOnboarding, securityContext, aiGovernance, aiPlatform, claims, cases, ingestion, evidence, appealAssembly, approvedActions, voiceAgent, hospitalVoice, integrationControl, connectorProfiles, connectorReadiness, fhirSmartContracts, reconciliation, outcomes, analytics, patterns, payerIntelligence, paymentIntegrity, revenueOperations, and other domain routers.

The router is the API contract. Do not infer unsupported REST endpoints from domain names.

Integration-control procedures

Current integration-control procedures include operations around:

• contracts;
• connection revisions;
• secret bindings;
• activation;
• connector validation;
• checkpoints;
• health;
• reconciliation.

Idempotency

The codebase uses idempotency keys and source identity/version/hash controls in specific domains. Idempotency is domain-specific; callers should use the documented field for the procedure being invoked.

Errors

Protected procedures return tRPC errors with scoped authorization failures, validation errors, not-found results, and precondition/activation failures as appropriate.

Raw internal exceptions should not be treated as stable public API contracts.