OpenAPI Discovery — Grok

Completed the independent API-discovery assessment. Existing application code was not modified.

Results:

• 6 capabilities discovered (5 Edge Function capabilities + staff portal PostgREST/RLS data access)
• 12 documented HTTP operations (5 function POST routes + booking action variants + OPTIONS where coded)
• Confidence: Edge Function behavior treated as CONFIRMED where directly coded; some Telnyx Insights payload shapes and the full RLS policy matrix remain UNKNOWN / partially INFERRED; no fabricated "expected healthcare" capabilities
• Authentication found: Bearer JWT (portal; gateway on for admin-manage), Bearer presence only (start-campaign; gateway JWT off), x-carecall-secret (assistant-tools), opaque booking token + anon key at gateway (booking-api), none on telnyx-call-events (always HTTP 200)
• OpenAPI validation: YAML structured as OpenAPI 3.1, hand-checked; no heavy external validator run in this environment — syntactic shape is not proof of semantic correctness

Major ambiguities:

• Whether start-campaign should restrict roles vs. accepting any Bearer
• Exact Telnyx Insights payload schema
• How deep the PostgREST/RLS surface should be treated as a second API surface

Major concerns:

• Unsigned Telnyx webhook endpoint
• Dialer (start-campaign) accepts any Bearer without a role check
• Shared tool secret is the sole AI-tool authentication mechanism
• CORS * on several functions

Needs human verification: production auth intent for the dialer, webhook signature hardening, whether PostgREST should be part of the published contract, and live response samples vs. schema looseness.

Success criterion (as defined for this workstream): a traceable hypothesis of CareCall's Edge Function API contract, grounded in implementation evidence, with uncertainty explicit — not a claim that the OpenAPI is complete or "correct" merely because it is valid YAML.