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 Unity API versus the FHIR R4 APIs, how developer access 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 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 product lines worth naming precisely, because each has a different deployment profile and integration footprint:

• Sunrise — the acute-care, hospital-grade EHR used in enterprise inpatient deployments. Now part of Altera Digital Health. For Altera developer access, contact ADP@alterahealth.com directly.
• TouchWorks EHR — the large ambulatory platform used by sizeable multi-specialty groups and health systems. Also moved to Altera.
• Veradigm EHR (formerly Professional EHR) — the product for smaller ambulatory practices. Stayed with Veradigm, alongside the cloud-based Practice Fusion.

This matters on day one. 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 significant share of production traffic — especially for anything FHIR does not cover: scheduling, write-backs, practice management data, and vendor-specific fields. If you are touching Sunrise, TouchWorks, or Veradigm EHR for anything beyond standard clinical reads, you will almost certainly meet Unity.

One important distinction: the Veradigm FHIR API is read-only. For write operations — updating records, scheduling appointments, saving notes — Unity is the only path. This is true for Veradigm EHR, and it is also true for Practice Management: any demographic, appointment, or financial data that needs to be written requires 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 GetToken with your app credentials to obtain a security token. On the JSON surface this lives at a path like /Unity/UnityService.svc/json/GetToken.
• Call GetServerInfo to confirm connectivity and read server details — the canonical "is this thing on?" check before proceeding.
• Route every subsequent data call through a single Magic action (typically MagicJson on the REST surface). You pass the token plus an Action name — GetPatient, GetSchedule, SaveNote, GetClinicalSummary — and a set of parameters specific to that action.

That single-endpoint, action-by-name design is Unity's defining quirk. Instead of dozens of REST routes, you have one Magic method and a catalog of action names, each with its own parameter shape and response structure. It is broad and powerful, but it is not self-describing the way a FHIR endpoint is. Reading the vendor docs carefully pays off here more than in most integrations.

The modern path: ONC-certified FHIR R4

Alongside Unity, Veradigm and Altera both expose FHIR R4 APIs driven by federal regulation. The ONC certification program requires certified EHRs to publish a standardized FHIR API — the (g)(10) standardized API criterion — supporting single-patient and population-level access to the data classes defined by USCDI.

The Veradigm FHIR API supports both JSON and XML formats (JSON by default), and authentication follows the HL7 SMART App Launch Framework 2.0 specification — a profile of OAuth 2.0. If you need FHIR R4 responses specifically from a version-less environment, add fhirVersion=4.0 to the Accept header.

Common clinical resources available through the FHIR surface:

• Patient, Practitioner, Organization — demographics and directory data
• Condition, AllergyIntolerance, MedicationRequest, Immunization — the problem and medication picture
• Observation, DiagnosticReport, DocumentReference — labs, vitals, results, and notes
• Encounter, CarePlan, Procedure — clinical context around a visit

Access is gated by OAuth2 / SMART on FHIR scopes. The Veradigm FHIR server returns a Capability Statement at [FHIR path]/metadata — always pull this first. It documents exactly which resources and search parameters are supported for that tenant, so you are not building against assumptions. If you have built against Epic or Oracle Health FHIR, the patient-access and provider-access patterns will feel familiar.

FHIR is the default — but it is not complete

Reach for FHIR first for any standard read. It is cleaner, self-describing, and portable across vendors. The catch: "FHIR R4" on the vendor's website does not guarantee every resource, search parameter, or write operation you need is actually implemented on a given product or a given customer's tenant. Scheduling, write-backs, and product-specific data are common gaps. We wrote about this exact trap in FHIR-compliant is not the same as interoperable.

FHIR vs Unity: which to use for which data

The short version: FHIR for standard clinical reads, Unity for writes and scheduling, HL7 v2 when you need a real-time event stream. But the real decision is per-resource and per-tenant — not per-vendor. The same Patient resource that returns a full record on one Allscripts site can come back half-empty on the next because that customer configured their system differently or licensed different modules. Always pull the Capability Statement from the actual organization you are integrating, not from the vendor's documentation.

Developer access: where the real timeline lives

Here is the part teams consistently underestimate. The APIs are well-documented, and a competent engineer can get a sandbox call returning synthetic data in a day or two. The schedule risk is almost never the code. It is access.

The path runs through developer.veradigm.com:

• Register your app. Create an application on the developer portal, declare whether you need FHIR, Unity, or both, and describe the use case. Select your App Type (Patient, Provider, or System) accurately — it affects how your application appears in the client's License Management Portal.
• Build against the sandbox. Veradigm provides a free trial for Open-tier users with a click-through agreement — no upfront fees. The sandbox runs on synthetic patients (no PHI) and lets you get OAuth/SMART scopes and Unity GetToken working without touching a real system.
• Request production access. This is the gate. Production is approved per organization: the specific practice or health system that owns the tenant must enable your app on 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 organization to approve production access. Sequence that request as early as possible — in parallel with the build, not after it. This holds true across every major EHR vendor, which is why we treat access timelines as a first-class part of any EHR integration plan.

Veradigm Connect membership tiers

Which tier you need depends on what APIs you are using:

• Open (free). Full access to FHIR-enabled APIs. Good for patient-facing apps and regulatory reads. No Unity access, no SDK, no certification path. A free sandbox with a click-through agreement gets you going with no upfront cost.
• Integrator (paid). This is what most healthtech teams building bidirectional integrations need. You get FHIR plus the full Unity API, the SDK, and a certification path so your solution can be deployed to clients. Tiers (Bronze, Silver, Gold) differ on support level — pay monthly or get 10% off annually.
• Altera products (separate path). Sunrise, TouchWorks, and Paragon now use Altera's Developer Program. The FHIR portal still covers them, but for Unity access or deeper integration questions, contact ADP@alterahealth.com. Veradigm Connect and Altera have separate approval workflows.

If your app targets Veradigm EHR or Practice Fusion and needs write capability, you need the Integrator tier. If you are only reading standard clinical data via FHIR, Open gets you there for free.

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. Check the Capability Statement first.
• Drop to Unity Magic actions when FHIR coverage is thin — typically for scheduling, task management, document write-backs, and product-specific data that the FHIR surface does not expose. Unity is also the only write path for most resources.
• 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. Verify coverage against the actual organization you are integrating — not against the vendor's capability statement.

SMART on FHIR scopes: what to set when you register

When you register a FHIR application on the Veradigm portal, you select scopes that control what data the application can request from the EHR. A few things to know before you fill out the form:

• Scopes must match your App Type. Scopes that start with patient/ are for patient-facing applications; user/ scopes are for provider-facing ones.
• SMART version 1 scopes end in .read. SMART version 2 scopes end in .rs. The Veradigm FHIR API supports SMART App Launch Framework 2.0, so use v2 scopes unless you have a specific reason not to.
• If your application needs a refresh token (most do), check offline_access during registration.
• Request only the scopes your app actually needs. Over-requesting raises flags during the client licensing approval process and can slow down production activation.
• For backend system-to-system integrations, set up a JWKS endpoint for your public key so you can rotate keys without contacting every FHIR vendor you work with.

Veradigm EHR version 24.5 and later also supports Single Sign-On (SSO), which matters if you are building a SMART-launched app that needs to embed inside the EHR workflow rather than run as a standalone portal.

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 domain 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 Unity, FHIR, and HL7 v2 are treated 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. It is also the only write path for most operations.
• FHIR R4 is the ONC-certified default for standard clinical reads — gated by OAuth2 / SMART scopes, shaped by USCDI. The Veradigm FHIR API is read-only.
• Open tier (free) covers FHIR reads. Integrator tier covers Unity plus bidirectional workflows. Altera products use a separate program at ADP@alterahealth.com.
• 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.