API and Integrations for EVV, Payroll, and Accounting

What connects

• EVV aggregators, including Colorado's Sandata aggregator as a Provider Choice system.
• Payroll providers, receiving approved hours from verified visits.
• Accounting and general ledger systems for billing and remittance data.
• Clearinghouses for 837 claim submission where you already have a relationship.
• Identity providers for single sign-on.
• Custom internal systems through the REST API and webhooks.

How integration works

The REST API exposes clients, authorizations, staff, schedules, visits, documentation, and billing records with scoped API keys and full request logging. Webhooks push events — visit verified, claim generated, credential expiring — to your systems as they happen rather than on a nightly poll.

For environments where outbound connections are restricted, including air-gapped deployments, integrations run through controlled file exchange instead of live network calls.

Migration in and out

Onboarding includes importing clients, authorizations, staff, and historical documentation from your current system. Your data is yours: full exports are available at any time in open formats, with no contractual lock on getting it back.

Adopting in stages instead of all at once

Replacing documentation, EVV, scheduling, payroll, and billing simultaneously is how implementations fail. The realistic path is sequential, and it requires the new system to coexist with the old one for a while.

A common sequence: documentation and EVV first, because they are the source records everything else depends on; scheduling next, once visit data is clean; then payroll export; then billing, once you trust that the services in the system match what was delivered. At each stage, OutcomeGrid exchanges data with the systems you have not yet replaced, so nothing has to be re-keyed during the transition. Agencies frequently spend a full quarter in a mixed state, and that is a normal, planned condition rather than a problem.

What integration actually requires from you

The honest answer is: a person who knows your current data, and a short list of decisions. Client and staff identifiers need to map between systems. Service codes and rates need to be confirmed against your current contracts rather than assumed. Historical documentation needs a retention decision — import everything, import a period, or leave it in the legacy system as a read-only archive.

OutcomeGrid handles the mechanics: the REST API and scheduled file exchange move the data, request logging shows what moved and when, and webhooks notify your systems as events occur rather than on a nightly batch. For air-gapped deployments, the same exchanges run through controlled file transfer with no outbound network calls.

Timelines are predictable because the work is bounded. A straightforward client, staff, and authorization import with confirmed service codes is usually measured in days rather than months. The long tail is historical documentation, and that can be imported after go-live without holding up the programs already running on the platform. Single sign-on and payroll export are typically configured in the same window, since both are contained pieces of work with clear owners on each side.