Use this file to discover all available pages before exploring further.
Technical Execution
Technical Execution
Suki SDKs & APIs · Engineering checklist
How integration works, what partners need, critical technical requirements, and integration timeline
Technical execution at a glance
Learn how to integrate Suki SDKs and APIs into your product. Go through this technical execution guide for technical requirements and the integration process for our developer tools.
How integration works
These four phases apply across the Web SDK, Mobile SDK, Headless Web SDK, and SDP REST APIs. Your surface changes how you implement each step; use the Critical technical requirements section below for checklists by product.
1
Setup and configuration
Partner ID, security (JWKS), and environment setup. Install the Web or Headless package, embed the Mobile SDK, or configure SDP REST API clients.
>
2
Authentication
Connect your IdP, issue partner tokens, and validate access for embedded SDKs or server-side SDP API calls.
>
3
Ambient session and AI
Run sessions with Web or Headless UI, native mobile capture, or API-driven flows. Stream audio, receive transcript and structured clinical note.
>
4
Note delivery
Receive structured payloads (JSON), map to your formats, and route to chart, record, or downstream systems.
What partners need
To use our developer tools, you need to have the following:
✓ Identity & Security System
An existing authentication system (OAuth 2.0 or similar) is the foundation. The SDK connects to what’s already in place. Most organizations already meet these requirements.
✓ Development environment
Teams shipping a browser client with React (@suki-sdk/react) or JavaScript (@suki-sdk/js) are ready. Server-rendered-only stacks still need a supported client bundle. Standard tools and package managers are all that’s needed.
✓ Clinical knowledge
Clinical teams already understand their specialties and documentation requirements. That expertise configures the SDK for optimal note generation.
✓ Structured data path
Ability to receive structured payloads and route them into charts, care plans, billing, or other downstream systems. The SDK delivers LOINC-oriented note data your services can map and persist.
✓ Audio capabilities
Standard web browser microphone permissions and HTTPS connections. Capabilities every modern web application already supports.
✓ User information
Stable identifiers and context for the person using the SDK (for example, physician, nurse, case manager, or virtual care role), plus organization or tenant IDs you already store.
Integration Methods
Web SDK
Use our pre-built browser UI with the Web SDK for React or JavaScript to get started quickly.
Why it matters: Match the package to the stack. React apps get React-optimized components. The JS package targets browser JavaScript outside React. This avoids unnecessary complexity.
List of medical specialties the application supports
Understanding of LOINC codes for clinical note sections
Mapping between encounter types and appropriate LOINC codes
Why it matters: Context is everything. A cardiology note looks different from a behavioral health note. Proper configuration ensures notes are clinically appropriate and perfectly formatted for partner workflows.
Infrastructure to receive note submission events or callbacks
Logic to parse LOINC-encoded JSON structure
Workflow to map Suki’s output format to your systems of record or handoff targets
Why it matters: Completed notes arrive as LOINC-encoded JSON. Partner systems receive structured, ready-to-use data for charts, exports, or internal services. No manual translation needed.
Microphone access permission flow in the application
HTTPS connection for production (required for microphone access)
Iframe configuration if embedding: add allow=“microphone; clipboard-write; clipboard-read” attributes
Why it matters: Audio capture is essential. Without proper microphone permissions, the system can’t function. Ensure permissions are requested and iframe configurations are correct.
These areas need attention for native iOS deployments. The Mobile SDK is a headless framework: you own the UI while the SDK handles audio, sessions, and platform services.
Authentication and tokens
Requirements
Implement tokenProvider protocol so the mobile SDK can request authentication tokens when needed
Pass PartnerID, ProviderInfo, and related fields to initialize as described in configuration guide
Use .stage for development and .prod for production
Why it matters: The SDK exchanges tokens with Suki services on a predictable contract. A correct token provider and initialization payload avoid auth failures during sessions.
SukiAmbientCore.framework added, embedded, and set to Embed & Sign
NSMicrophoneUsageDescription in Info.plist with a clear, user-facing explanation
Why it matters: Apple enforces microphone disclosure and embedding rules. A correct deployment target and framework embedding prevent runtime crashes and App Store rejection.
Use these when your backend or a custom client orchestrates login, sessions, and content without the pre-built Web SDK UI. Follow REST and streaming patterns in the API reference.
Authentication and tokens
Requirements
HTTPS-only clients; obtain a Suki token via login using partner_id, partner_token, and provider_id as documented
Partner JWTs issued consistently with your JWKS and Suki validation rules
Secure storage and rotation of credentials in your services
Why it matters: API access is token-driven. Misconfigured login or partner tokens surface as 401s across session and content calls.
Critical technical requirements (Headless Web SDK)
Partner authentication and tokens are the same as the Web SDK. Headless differs because you build your own UI and integrate useAuth, ambient hooks, and related APIs instead of pre-built components.
Authentication
Requirements
Same partner authentication checklist as the Web SDK tab.
OAuth 2.0 compliant identity provider or custom JWT generation system
Publicly accessible JWKS endpoint (HTTPS) for token verification
JWT tokens signed with RS256 algorithm
Required claims: exp, iss, aud, and user identifier
Why it matters: It is the same trust model as the Web SDK. In Headless you connect tokens through useAuth and related hooks; auth gaps block ambient APIs until identity is wired correctly.
