Skip to main content

Compatibility

Compatibility has three parts: the application runtime must load the package, React apps must provide a compatible React runtime, and the selected Ovok environment must publish the API operations your workflow needs. Check each part before upgrading or shipping.

Package and language support​

The published package exposes a CommonJS entry point and TypeScript declarations. Its build target is ECMAScript 2018. Use a bundler that can consume CommonJS and make sure your deployment target can run ES2018 output, or transpile dependencies for older browsers.

The package does not publish a minimum TypeScript version. TypeScript is not needed at runtime; JavaScript applications can use the package, while TypeScript applications should use a compiler that can read the package's declaration files.

The package metadata does not publish a supported-browser matrix or a React Native support statement. Check your bundler and target browser APIs in the app's supported environments before release.

React applications​

React is a peer dependency. The current package metadata does not set a minimum or maximum React version, and its development dependency targets React 18.3. Treat the peer range as dependency metadata, not a guarantee that every React release has been validated.

Use the same React installation as the host application. Avoid bundling a second React copy: OvokProvider and SDK hooks must resolve the same React runtime as the components that use them.

OvokClient can be used without React. OvokProvider and hooks belong in a client-side React tree. In server-rendered applications, keep authenticated clients request-scoped on the server and provide a separate client instance to browser components. See React integration and React applications.

SDK package peers​

The package declares peer dependencies in addition to React. Install versions that satisfy the ranges published for the exact @ovok/core release you use. Package managers report missing or incompatible peers during installation; resolve those against the installed release metadata rather than copying peer versions from a different SDK release.

The SDK package version and the versions of its peer packages should be upgraded as a compatible set. Check your lockfile after the upgrade so local development, CI, and production install the same versions.

Ovok API compatibility​

An SDK method can be present in the package before the API environment you target supports the corresponding operation. The SDK does not enable project features or grant access; the server checks the user's identity, project configuration, and permissions for every request.

Use capability discovery during development to inspect the selected environment:

const statement = await client.getCapabilityStatement('R4');
const publicEndpoints = await client.getPublicApiEndpoints('R4');

The capability statement describes available FHIR operations. The public endpoint list describes non-FHIR routes advertised by the server. Neither replaces project authorization checks. For operation details, consult FHIR basics, the FHIR R4 reference, and the platform guide for the feature you are using.

Environment compatibility​

Keep the SDK client pointed at the same environment where the project, user, and content are configured. For sandbox development, use the sandbox API origin and the FHIR path published for that environment:

import { OvokClient } from '@ovok/core';

export const client = new OvokClient({
baseUrl: 'https://api.sandbox.ovok.com',
fhirUrlPath: '/fhir/R4/',
});

Do not reuse a sandbox client configuration for production. Settings, users, CMS content, feature availability, and API releases can differ between environments. See configure the client and the platform's settings and features guide.

Upgrade checklist​

Before deploying a new SDK version:

  1. Read the release notes and check the package metadata for that exact version.
  2. Resolve every peer dependency to a version accepted by the package manager.
  3. Confirm that the application bundler handles the package entry point and that the runtime supports ES2018 output.
  4. Run the app against the intended Ovok environment and check its capability statement and published endpoints.
  5. Exercise the project settings, access policies, and feature gates used by the application.

If a request fails after an upgrade, start with errors and retries, then verify the backend feature prerequisites in the relevant Ovok guide.