Skip to main content

Connections

Integration boundaries

How Fatou Health connects external systems without turning a connector into blanket authority.

Connection is not permission

An integration proves that Fatou Health can reach a system. It does not automatically authorize every action that system supports. Tenant binding, policy, workflow state, and explicit side-effect rules remain separate controls.

  • Credentials remain server-side.
  • Provider identifiers are bound to the intended practice.
  • Read-only preflight comes before write enablement.
  • Write paths use narrow tools rather than arbitrary provider access.
  • Important external changes should be verified with provider readback.

Scheduling

Acuity is the current provider used by operating-contract scheduling. Fatou Health also contains a legacy Cal.com booking path. New operating-contract work should not assume the legacy path has the same configuration model.

  1. Bind the integration to one tenant.
  2. Verify appointment type, calendar, and timezone mapping using read-only provider calls.
  3. Keep booking disabled until the mapping is confirmed.
  4. Run one controlled booking through Fatou Health.
  5. Read the booking back from the scheduling provider.
  6. Test replay behavior so retries do not create duplicate appointments.

Email, models, and platform data

  • Supabase — application data, authentication, and tenant-scoped persistence.
  • Resend — current public inquiry email delivery path.
  • Groq — current model client factory used by the agent runtime.
  • Website tracker — tenant-bound public site key plus optional origin allowlist for visitor events.