Integrations & API

Part of the Anaya Care Handbook — the source of truth for how the product must behave. When the product needs to change, change this document first, then make the system match it.

Implementation status — this module is mostly specified but not yet built. The Google Drive integration (INT-16–INT-19) is live and audited against the code; every other rule below is 🚧 Spec only until that feature ships and this page is audited against the code. Legend: ✅ In code · ⚠️ Partial · 🚧 Spec only (not yet built).

What this covers

This page is the register of third-party integrations Anaya Care relies on or plans to add, and the outward API through which other systems will talk to the platform. It records which integrations are live, planned, or future, and the interoperability commitments — a REST API, webhooks, and standard data exports — that arrive in a later build phase. It is the home for telehealth and real-time translation/captioning as integrations; the features that consume the other integrations have their own pages, cross-referenced below.

Key terms

• Integration — a connection to an outside service the platform calls (for example a push or SMS provider) or receives data from.
• Integration status — where each integration sits: Current (live), Planned (next build phase), or Future (later).
• Outward API — the REST interface Anaya Care exposes so third-party systems can read and write platform data, subject to RBAC.
• Webhook — an outbound notification Anaya Care sends to a subscriber's endpoint when an event occurs, for real-time integration.
• Data export — generating downloadable platform data in a standard format: CSV, PDF, or HL7 FHIR where applicable.
• HL7 FHIR — the healthcare interoperability standard used when exporting health data to other systems.

How it works

Anaya Care is API-first: the backend is designed so that future third-party integrations attach through a single REST API rather than ad-hoc connections. Three integrations are live today — the push notification service and the SMS service, both used to deliver alerts (see Communication and Emergency Alerts (SOS)), and Google Drive, described below. Everything else is on the roadmap.

The Google Drive integration lets a staff member open a care document in Google Docs instead of downloading a Word copy. It is offered wherever a Word download already is — the care plan, the care proposal, the care summary and the shift report — and it is deliberately available to exactly the people who may download that document, no wider. Choosing it uploads the same Word document the platform would have downloaded into that person's own Google account, converted to a Google Doc, and opens it.

Connecting happens the first time it is used: someone who has never linked Google is asked for permission at the moment they ask for the document, rather than being sent to a settings page first. The platform asks for the narrowest permission Google offers — it may only touch files it created itself, and can never read anything else in that person's Drive. A person can disconnect at any time, which revokes the platform's access and forgets the stored permission.

Opening the same document twice reopens the same Google Doc rather than making a second copy, so a staff member's own edits survive. A document that changes — a care plan republished at a new version, a shift report amended — produces a new Google Doc, so republishing can never overwrite what somebody wrote in the old one. A Doc that has been deleted or put in the bin is simply made again.

The important consequence is that this moves client information out of the platform. Once a document has been converted into someone's Google account it is theirs: the agency cannot recall it, cannot see who it is shared with, and the platform's activity log stops at the moment of export. This is why the connection is per-person and per-document rather than an agency-wide sync, and why it is worth an agency deciding deliberately whether to use it (see Decisions needed).

Integrations are grouped by status. Planned integrations are scheduled for the next build phase: real-time translation, telehealth video consultation (see Telehealth Services), and background-check screening for care providers. Future integrations come later: the fintech partner behind Anaya Wallet, EHR systems (Epic, Cerner), wearable devices, and direct 911 / emergency services integration. The data the platform already captures for EVV Compliance Reporting will flow out through this layer when the export and aggregator pipelines are built.

The background check service integration partners with a screening provider (for example Checkr or Sterling). A Company Admin (Owner or Admin) initiates a check through the platform, and the result is stored securely in the care provider's profile. The integration only moves the data — the agency remains fully responsible for conducting and interpreting the check and for the hiring decision; the platform never makes that decision. This screening also underpins the vetting promised by the ARMI Marketplace.

The outward-facing interoperability capabilities are the REST API itself, webhook support for real-time event notifications, API documentation for integrators, API access tiers scoped to each subscriber's plan, and data export in CSV, PDF, and HL7 FHIR where applicable. These are all on the roadmap and are listed here so the integration surface is specified in one place before any of it is built. Features that depend on these connections — Telehealth Services, Care Coordination & Provider Integration, Anaya Wallet, Anaya Healing Ally, and Emergency Alerts (SOS) — carry their own detail on their own pages.

Rules

1. INT-1 — The platform must integrate with a push notification service for all push delivery and an SMS service for urgent alerts. Both are live integrations and the platform must not deliver pushes or urgent texts by any other route. (🚧 Spec only)
2. INT-2 — Each integration must carry an explicit status — Current, Planned, or Future — and the platform must not depend on a Planned or Future integration as though it were live. (🚧 Spec only)
3. INT-3 — Real-time language translation must be provided through a translation service integration; it is Planned and not available until that integration ships. Captioning and translation are integrations governed here, not standalone features. (🚧 Spec only)
4. INT-4 — Video consultation must be provided through a telehealth provider integration; it is Planned and is the home for telehealth on the platform. (🚧 Spec only)
5. INT-5 — Care provider screening must run through a background check service integration; it is Planned. (🚧 Spec only)
6. INT-6 — Anaya Wallet fund management must run through a fintech partner integration; it is a Future integration and no wallet funds move until it is in place. (🚧 Spec only)
7. INT-7 — Health record integration with EHR systems (Epic, Cerner) is a Future integration; the platform must not claim EHR interoperability before it ships. (🚧 Spec only)
8. INT-8 — Automated health data capture from wearable devices (for example Apple Watch) is a Future integration. (🚧 Spec only)
9. INT-9 — Direct 911 / emergency services integration is a Future integration. Until it exists, the emergency flow dials 911 from the device rather than through a platform integration (see Emergency Alerts (SOS)). (🚧 Spec only)
10. INT-10 — The platform must expose a REST API for third-party system integration. This is a Future capability. (🚧 Spec only)
11. INT-11 — The platform must support webhooks so subscribers receive real-time event notifications. This is a Future capability. (🚧 Spec only)
12. INT-12 — The platform must support data export in CSV, PDF, and HL7 FHIR where applicable. This is a Future capability, and health-data exports must use HL7 FHIR. (🚧 Spec only)
13. INT-13 — Through the background check integration, a Company Admin (Owner or Admin) must be able to initiate a screening from the platform; the result must be stored securely in the care provider's profile; and the agency remains fully responsible for conducting and interpreting the check and for the hiring decision — the platform must never make that decision (see ARMI Marketplace). (🚧 Spec only)
14. INT-14 — The platform must publish API documentation for integrators alongside the REST API and webhooks. (🚧 Spec only)
15. INT-15 — API access must be offered in tiers scoped to each subscriber's subscription plan and use case, so that a subscriber's API reach matches the tier it pays for. (🚧 Spec only)
16. INT-16 — Wherever the platform offers a care document as a Word download, it must also offer to open that document in Google Docs, and the two must be available to exactly the same people. A person who may download a document may open it; a person who may not, may not. The signed care proposal is the one exception: it stays PDF-only, as it already is for Word (see Care Proposals). (✅ In code)
17. INT-17 — Opening a document in Google Docs must place it in the individual's own Google account, never an agency-wide or platform-owned one, and must request only the permission to manage files the platform itself created — never read access to the rest of that person's Drive. The permission must be requested at the moment it is first needed, and the person must be able to revoke it. (✅ In code)
18. INT-18 — Opening the same version of the same document more than once must reopen the Google Doc already created for it, so the person's own edits are preserved. A new version of a document must produce a new Google Doc, so that republishing never overwrites edits made to an earlier one. A Doc the person has deleted must be recreated rather than treated as an error. (✅ In code)
19. INT-19 — Exporting a care document to Google Docs moves client information outside the platform, where the agency can no longer control access and the activity log cannot follow it. The platform must not present this as equivalent to an in-platform download, and must never export a document to Google on a person's behalf without them asking for it. (✅ In code)

Integration register

Who can do what

Most rules on this page apply at the platform and operations level: configuring integrations and the outward API is an Anaya SuperAdmin concern, not a per-subscriber role. Two actions are subscriber-facing: initiating a background check, which sits with the Company Admin (Owner or Admin); and opening a care document in Google Docs, which deliberately has no permission of its own.

Opening a document in Google Docs carries no separate permission on purpose. Granting it one would create a second, drifting answer to a question the platform has already settled per document — the care plan, the care proposal, the care summary and the shift report each already decide who may read them, and INT-16 binds the Google Docs option to that same answer rather than restating it.

Decisions needed

• How does a third party authenticate to the REST API? The PRD commits to a REST API but says nothing about auth. Options: API keys per subscriber; OAuth 2.0 client credentials; signed JWTs issued by the platform.
• How is the API versioned? Options: path-based versioning (/v1/...); header-based versioning; a single unversioned API with a deprecation policy.
• What are the rate limits and quotas? The PRD sets no API throughput limits. Options: per-key request quotas; per-subscriber tier limits aligned to subscription plan; no limits initially.
• How are webhook deliveries secured and retried? Options: signed payloads with a shared secret and retry-with-backoff; at-least-once delivery with idempotency keys; subscriber-pull instead of push for missed events.
• Which records are exportable, and to whom? Data export is committed in CSV/PDF/FHIR but the scope is undefined. Options: export gated by the existing Export permission per feature; FHIR limited to health records only; full-account export for data-portability requests.
• How do the API access tiers map to subscription plans? INT-15 commits to tiers scoped by subscriber plan and use case, but the mapping is undefined. Options: tie API reach directly to the existing subscription tiers; sell API access as a separate add-on; gate by use case (read-only vs read-write) independent of plan.
• Should an agency be able to restrict which Google accounts a care document may be exported to? INT-16 currently lets anyone who may download a document open it in their own Google account, including a personal one. A personal Google account carries no business agreement with Google covering client information, whereas an agency's own Google Workspace can. Options: leave it open and treat it as the agency's policy to enforce; let an agency list the Google domains it will accept, so exports can only land in accounts it controls; make the whole integration an agency-level switch that is off until turned on. This needs settling before the integration is offered to agencies operating under stricter obligations — see Security & Compliance and Data Ownership & Retention.
• Is the REST API / webhook layer "Planned" or "Future"? Developer Reference v4.2 §8.50 lists the API, webhooks, documentation, and access tiers as Planned, while §2.9 (Interoperability) lists the same surface as Future. The page currently treats INT-10, INT-11, and INT-12 as Future; the canonical status needs to be settled before build.