You signed a customer who runs on Allscripts. You open the developer portal, expecting one API and a sandbox key, and instead you find a legacy SOAP service called Unity, a separate set of FHIR endpoints, a rebrand to Veradigm, and a note that one of the products you need now belongs to a company called Altera. Before you write a line of code, you have to figure out which Allscripts you are actually integrating with.
This guide untangles that. It covers what "Allscripts" means after the 2022 rebrand and split, when to use the legacy Unity API versus the modern FHIR R4 APIs, how developer access actually works, and why the real timeline driver is approval, not engineering. If you are integrating more than one EHR, it pairs with our multi-EHR integration layer guide.
"Allscripts" is now several products under two owners
In 2022, Allscripts Healthcare Solutions rebranded its remaining business as Veradigm and, in the same year, sold its hospital and large-physician-practice segment to Harris Computer (a Constellation Software subsidiary). That divested unit became Altera Digital Health. So when someone says "Allscripts," they could mean any of four products, and they are no longer all owned by the same company.
The three classic product lines are worth naming precisely, because each has a different deployment profile and a different integration footprint:
- Sunrise - the acute-care, hospital-grade EHR. Enterprise inpatient deployments. Now part of Altera Digital Health.
- TouchWorks EHR - the large ambulatory platform, used by sizeable multi-specialty groups and health systems. Also moved to Altera.
- Professional EHR - the product for smaller practices, now marketed as Veradigm EHR. This one stayed with Veradigm, alongside the cloud-based Practice Fusion.
This matters on day one. The two surfaces you will integrate against - Unity and FHIR - exist under both owners, but the developer programs, tenants, and approval paths are not identical. The first question on any Allscripts project is not "SOAP or FHIR?" It is "which product, on which owner's platform, for which customer organization?"
The legacy path: the Unity API
Unity is the long-standing Allscripts integration API. It predates FHIR by years and still carries a large share of production traffic, especially for anything FHIR does not cover well. If you are touching Sunrise, TouchWorks, or Veradigm EHR for write-backs, scheduling, or vendor-specific data, you will probably meet Unity.
How Unity works: GetToken, then Magic
Unity is a token-based service available over both SOAP and a JSON/REST surface. The flow is consistent regardless of transport:
- Call
GetTokenwith your app credentials to obtain a security token. On the JSON surface this lives at a path like/Unity/UnityService.svc/json/GetToken. - Call
GetServerInfoto confirm connectivity and read server details - the canonical "is this thing on?" check. - Make every subsequent data call through a single Magic action (often
MagicJsonon the REST surface). You pass the token plus anActionname - for exampleGetPatient,GetSchedule,SaveNote, orGetClinicalSummary- and a set of parameters.
That single-endpoint, action-by-name design is the defining quirk of Unity. Instead of dozens of REST routes, you have one Magic method and a long catalog of action names, each with its own parameter shape and its own response structure. It is powerful and broad, but it is not self-describing the way a FHIR endpoint is, and the action catalog rewards careful reading of the vendor docs.
The modern path: ONC-certified FHIR R4
Alongside Unity, Veradigm and Altera both expose FHIR R4 APIs. These are the endpoints driven by federal regulation: the ONC certification program requires certified EHRs to publish a standardized FHIR API, including the (g)(10) standardized API criterion, supporting single-patient and population-level access to the data classes defined by USCDI.
In practice this means the common clinical resources are available through a predictable, standards-based interface:
- Patient, Practitioner, Organization for demographics and directory data.
- Condition, AllergyIntolerance, MedicationRequest, Immunization for the problem and medication picture.
- Observation, DiagnosticReport, DocumentReference for labs, vitals, results, and notes.
- Encounter, CarePlan, Procedure for the clinical context around a visit.
The shape of these resources follows the published HL7 FHIR R4 specification, and access is gated by OAuth2 / SMART on FHIR scopes rather than a Unity-style token. If you have built against Epic or Cerner FHIR, the patient-access and provider-access patterns will feel familiar.
FHIR is the default - but it isn't complete
Reach for FHIR first for any standard read. It is cleaner, self-describing, and portable across vendors. The catch is that "FHIR R4" does not guarantee every resource, every search parameter, or every write operation you need is actually implemented on a given product or a given customer's tenant. Scheduling, certain write-backs, and product-specific data are common gaps. We wrote about this exact trap - passing certification without being practically interoperable - in FHIR-compliant is not the same as interoperable.
Developer access: where the real timeline lives
Here is the part teams underestimate. The Unity and FHIR APIs are both well-documented, and a competent engineer can get a sandbox call returning data in a day or two. The schedule risk is almost never the code. It is access.
The path runs through the Veradigm developer program and looks like this:
- Register your app. Create an application on the developer portal, declare whether you need FHIR, Unity, or both, and describe the use case. Membership tiers differ for FHIR-only versus full Unity access.
- Build against the sandbox. The sandbox runs on synthetic patients - no PHI - and lets you get OAuth/SMART scopes and Unity
GetTokenworking without touching a real system. Finish as much as you can here. - Request production access. This is the gate. Production is approved per organization: the specific practice or health system that owns the tenant has to enable your app against their environment. That is a business and compliance process, not an API call.
- Go live. You receive a production base URL and client credentials scoped to that tenant.
The implication for planning: you can finish your sandbox integration in a week and still wait weeks or months for a customer's organization to approve production access. Sequence the approval request as early as you can, in parallel with the build - not after it. This dynamic is true across vendors, which is why we treat access timelines as a first-class part of any EHR integration plan, not an afterthought.
When FHIR coverage is thin: HL7 v2 and Unity as fallbacks
No single surface covers everything, so plan the fallbacks deliberately:
- Start with FHIR R4 for standard clinical reads - patients, conditions, medications, observations, results. If the resource and search parameters you need exist on the tenant, this is the cleanest path.
- Drop to Unity Magic actions when FHIR coverage is thin - typically for scheduling, task management, document write-backs, and product-specific data that the certified FHIR surface does not expose.
- Fall back to HL7 v2 when neither API gives you what you need in real time. The classic message feeds - ADT for admit/discharge/transfer, ORM for orders, ORU for results - remain the workhorse for event-driven data and are often the only practical way to get a real-time stream of certain events. An interface engine sits between the EHR and your system to route and transform these messages.
The decision is not vendor-wide. It is resource-by-resource and, critically, tenant-by-tenant. The same Patient resource that returns a full record on one Allscripts site can come back half-empty on the next, because the customer configured their system differently or licensed different modules. Verify coverage against the actual organization you are integrating, not against the vendor's capability statement.
Build vs. partner: the long tail of quirks
A single read against a single tenant is a weekend project. A production Allscripts integration that survives contact with multiple customers is a different animal, and the cost lives in the long tail:
- Two API surfaces - Unity and FHIR - with different auth models, error semantics, and pagination behavior.
- Two owners - Veradigm and Altera - with separate developer programs and approval paths for what users still call "Allscripts."
- Per-tenant variation in which FHIR resources and search parameters are actually populated.
- OAuth2 / SMART scope handling, token refresh, and the security posture every payload demands. We cover that surface in our healthcare API security guide.
That is the calculus behind build-vs-partner. If Allscripts is the only system you will ever touch, building in-house is reasonable. If it is one of several EHRs you need to support, a unified integration layer that normalizes Allscripts, Epic, Cerner, and athenahealth behind one API usually pays for itself fast - the approach we describe in our multi-EHR FHIR facade guide.
Healthcare is the only industry we work in. We built Yown Health's multi-EHR platform - integrating Epic, Cerner, Allscripts, and athenahealth behind a single interface - and we are FHIR R4 native, so we treat Unity, FHIR, and HL7 v2 as one connected layer rather than three separate projects. If your Allscripts integration is stalled on access approval or buried in per-tenant quirks, that is a solvable problem.
Key takeaways
- "Allscripts" became Veradigm in 2022, and Sunrise plus TouchWorks moved to Altera Digital Health - name the exact product and owner before you start.
- Unity is the legacy token-based API: call
GetToken, then route everything through a single Magic action by name. - FHIR R4 is the ONC-certified default for standard clinical reads, gated by OAuth2 / SMART scopes and shaped by USCDI.
- Access approval, not engineering, is the real timeline driver - production is granted per organization, so start that request early.
- When FHIR coverage is thin, fall back to Unity Magic actions, then to HL7 v2 feeds - and verify coverage per tenant, not per vendor.
If you want a second set of eyes on an Allscripts or Veradigm integration, book a 15-minute call and we will walk through the specific product, surface, and access path you are dealing with.
