Skip to main content

Supported Integration Levels

This page defines the integration levels that partners use to connect with the Air Doctor platform. Each level increases capability and control. Level selection depends on the partner’s technical capacity and user-experience requirements. This page provides a structured overview and directs partners to detailed guides for each level.

Integration Levels at a Glance​

The six integration levels range from a simple forward or redirect level to a complete custom client that uses the Open API.

Recommendation Matrix​

RequirementSuggested levelsRationale
Fastest delivery1–2Minimal change inside the host app.
Strong branding and UI3–5Tight visual alignment inside the partner app.
Full ownership6Partner creates and owns the entire client.
Minimum maintenance1–3Air Doctor carries most update and release work.
Highest UX control4–6Partner controls layout, flows, and presentation.

Level 1 – Forward / Redirect​

Purpose - Offer the fastest path to integration.

What you provide​
  • Entry point in the host app (link or button).
  • Policy and person identifiers inside the deep link.
  • Basic explanation of the handoff to Air Doctor for end users.
What Air Doctor provides​
  • Authentication and user account management.
  • All flows, screens, and business logic.
  • Session handling and security controls.
  • Maintenance of UX, accessibility, and release cadence.
Common Scenarios​
  • Partner app links insured users to Air Doctor through a deep link.
  • Partner provides an entry point for medical search or appointment creation.
  • Travel assistance provider needs immediate activation without UI alignment.
  • Call center workflow requires quick escalation into the Air Doctor flow.
  • Partner system requires zero maintenance of medical logic or screen flows.
User management

From Level 2, user management can run in the Air Doctor app, in the partner app, or as a mix of both.
Level 1 always relies on Air Doctor for user management.

Level 2 – Embedded WebView​

Purpose - Keep users inside the host app with minimal effort.

The partner app embeds the Air Doctor web client inside a WebView.
Air Doctor UI and flows run inside this view. The partner can delegate user authentication and session control to its own system when required.

What you provide​
  • WebView container in the host app.
  • Optional single sign-on and session control.
  • Navigation entry points that open the embedded Air Doctor view.
What Air Doctor provides​
  • Web client for appointments and related flows.
  • Layout, visual design, and interaction logic inside the WebView.
  • Secure handling of session data inside Air Doctor services.
Common Scenarios​
  • Partner app keeps users inside the host app while Air Doctor controls the experience.
  • Insurance provider uses internal authentication and supplies sessions to the WebView.
  • Partner needs a simple embedded experience without design modification.
  • Healthcare provider wants a contained view of Air Doctor inside an existing workflow.
  • Concierge service requires access to doctor search and booking inside a controlled container.

Level 3 – Embedded WebView with CSS Overrides​

Purpose - Align the embedded experience with partner branding.

The partner supplies a CSS file that customizes the look and feel of the embedded Air Doctor app.
Only style elements change; features and layouts stay the same, and the partner can still delegate user management.

What you provide​
  • WebView container and navigation entry points.
  • Custom CSS that applies brand colors, typography, and components.
  • Ongoing updates to the CSS as themes evolve.
What Air Doctor provides​
  • Stable DOM structure and class hooks for CSS.
  • Web client behavior and layout that respect accessibility rules.
  • Authentication and user management, or support for delegated flows.
Common Scenarios​
  • Partner applies brand colors, typography, and layout refinements to align with its design system.
  • Marketing team requires consistent branding across all flows inside the partner app.
  • Partner app supports multiple themes and needs CSS variations across regions.
  • Insurance provider demands uniform UI identity while Air Doctor maintains logic.
  • Enterprise vendor aligns embedded components with strict accessibility rule

Level 4 – Combined Front‑end​

Purpose - Create a unified app that uses Air Doctor screens as modules.

The client front-end is open source and serves as a reference implementation. Partners import the required modules (pure JavaScript for web, Kotlin for Android, Swift for iOS) and integrate them into their app. The partner supplies the application shell such as navigation and menus, and Air Doctor supplies individual screens such as appointment booking and medical history. This approach keeps users inside the host app and allows screen reordering or combination of screens. User management either integrates with the partner system or uses Air Doctor services.

What you provide​
  • Application shell and navigation structure.
  • Integration of JavaScript, Kotlin, or Swift modules into the host code base.
  • Choice and order of Air Doctor screens inside user flows.
  • Connection to your authentication stack and user profiles.
What Air Doctor provides​
  • Open-source front-end modules for core screens.
  • Consistent behavior and interaction logic for those screens.
  • Updates to modules when server behavior changes.
  • Documentation for supported entry points and props.
Common Scenarios​
  • Partner integrates Air Doctor screens inside its own navigation structure.
  • Partner requires screen reordering or conditional access to screens.
  • Healthcare partner embeds booking screens inside a larger care-management flow.
  • Insurance provider wants direct control of routing and entry points.
  • Desktop and mobile teams adopt Air Doctor modules for consistent behavior across platforms.

Level 5 – Custom UI on Client SDK​

Purpose - Use Air Doctor logic while you control every pixel.

Partners design a custom user interface and rely on Air Doctor business logic through the client back-end SDK.
The SDK, written in Kotlin, compiles into JavaScript, JVM bytecode, and native iOS binaries.
Partners implement screens with frameworks such as plain JavaScript, Jetpack Compose, or SwiftUI based on instructions from the back end.
Air Doctor works with partners to ensure accessibility and alignment with Air Doctor values.

What you provide​
  • Complete UI design and layout.
  • Implementation of screens in your chosen frameworks.
  • Integration of the client back-end SDK into build and release pipelines.
  • Monitoring of API and SDK changes and prompt adaptation of your UI.
What Air Doctor provides​
  • Client back-end SDK with domain logic and state control.
  • Documentation of flows, data contracts, and best practices.
  • Support for accessibility and UX review.
  • Coordination on releases that affect SDK behavior.
Common Scenarios​
  • Partner needs full UI ownership with Air Doctor logic inside the state layer.
  • Engineering team uses native components such as Compose or SwiftUI for full brand control.
  • Partner runs a design system that requires strict alignment across screens.
  • Insurance provider integrates appointment logic inside an existing care journey.
  • Enterprise partner requires deep accessibility controls and screen-level adjustments.

Level 6 – Direct API Integration​

Purpose - Gain full control of UI and domain logic with maximum flexibility.

Partners bypass the Air Doctor client and create their own client that uses the Open API.
They design the interface and domain logic and send HTTP requests for registration, doctor lookup, appointment management, and related actions.
This level requires deep domain knowledge and careful attention to authentication and hypermedia responses.
Because the server follows the HATEOAS principle, clients parse hypermedia links to discover available actions.

What you provide​
  • Complete client architecture and UX design.
  • Implementation of all screens and flows.
  • HTTP client layer that consumes the Open API.
  • Management of authentication, authorization, and security policies.
  • Monitoring of API lifecycle, version changes, and deprecation notices.
What Air Doctor provides​
  • Open API specification with endpoints, schemas, and error models.
  • Hypermedia-driven responses that expose available actions.
  • Documentation that aligns endpoints with screen-level concepts.
  • Technical and product guidance during design and rollout.
Common Scenarios​
  • Partner builds a complete medical assistance client from the ground up.
  • Insurance provider requires total control of domain logic, navigation, and presentation.
  • Large platform aggregates multiple health services and integrates Air Doctor as one of many flows.
  • Partner integrates Open API actions inside an orchestration engine.
  • AI-driven system analyzes hypermedia responses and selects next steps without UI dependencies.

How to Choose the Right Level of Integration​

When you select an integration level, consider these factors.

  • Time to market - Levels 1-3 suit fast enablement. Higher levels require more effort but provide tighter integration and a smoother user journey.
  • User experience requirements - Higher levels provide increased control over look, feel, and navigation.
  • Maintenance and upgrade burden = Levels 1-3 place most maintenance on Air Doctor. Levels 4 and higher require continuous review of API changes and updates to SDKs.
  • Security and compliance - Higher levels place greater responsibility for processing of personal data handling on the partner. Lower levels delegate part of this responsibility to Air Doctor.