No fee & no special effort. Registering an application, obtaining client credentials, and accessing the sandbox and this documentation are provided at no charge. Registration is not conditioned on a competitive relationship, a fee, or any of the prohibited terms at §170.404(a)(4)(ii)(B). See API Terms & Conditions.
1. Client Types
| Type | Example | Authentication |
|---|---|---|
| Public | Native mobile app, single-page app | No secret; Authorization Code + PKCE (S256) |
| Confidential — symmetric | Server-side web app | client_secret_basic + PKCE |
| Confidential — asymmetric | Backend service (SMART Backend Services) | private_key_jwt with a registered public key |
2. Required Technical Attributes
The following attributes are collected at registration (per §170.315(g)(10)(viii)). Required attributes depend on client type.
| Attribute | Required for | Notes |
|---|---|---|
client_name | All | Human-readable application name shown on the consent screen. |
redirect_uris | Authorization Code clients | One or more exact-match callback URIs. HTTPS, or an app-claimed private-use URI scheme for native apps. |
grant_types | All | authorization_code, refresh_token, and/or client_credentials. |
response_types | Authorization Code clients | code. |
token_endpoint_auth_method | All | none (public), client_secret_basic, or private_key_jwt. |
scope | All | Space-delimited list of requested scopes — see Supported Scopes. |
jwks / jwks_uri | Confidential asymmetric | Public key(s) used to verify the private_key_jwt client assertion. |
contacts | Recommended | Developer email(s) for security and operational notices. |
logo_uri, policy_uri, tos_uri | Optional | Displayed on the patient consent screen. |
launch_uri | EHR-launch apps | Endpoint Retinex invokes for an EHR launch. |
software_id, software_version | Optional | Stable identifier for the software across instances. |
3. Dynamic Client Registration (RFC 7591)
Applications may self-register programmatically at the registration endpoint:
POST https://retinexv2-apim.azure-api.net/auth/register
Content-Type: application/json
{
"client_name": "Acme Patient App",
"redirect_uris": ["https://app.acme.example/callback", "com.acme.app:/oauth2redirect"],
"grant_types": ["authorization_code", "refresh_token"],
"response_types": ["code"],
"token_endpoint_auth_method": "none",
"scope": "openid fhirUser offline_access launch/patient patient/Patient.rs patient/Observation.rs",
"contacts": ["dev@acme.example"]
}
Successful registration returns the assigned credentials:
{
"client_id": "c_9f3a2b7c1d8e",
"client_id_issued_at": 1780000000,
"token_endpoint_auth_method": "none",
"redirect_uris": ["https://app.acme.example/callback", "com.acme.app:/oauth2redirect"],
"grant_types": ["authorization_code", "refresh_token"],
"scope": "openid fhirUser offline_access launch/patient patient/Patient.rs patient/Observation.rs"
}
Confidential clients additionally receive a client_secret (symmetric) or register a jwks_uri (asymmetric).
4. Native (Mobile) Application Registration
Native apps register as public clients (token_endpoint_auth_method: none). Because a secret cannot be protected inside a distributed binary, security rests on PKCE and app-claimed redirect URIs:
- Register a private-use URI scheme redirect (e.g.
com.acme.app:/oauth2redirect) and/or an HTTPS claimed redirect (Android App Links / iOS Universal Links). - Use Authorization Code + PKCE S256 and request
offline_accessfor a refresh token. - Store issued tokens in iOS Keychain / Android Keystore.
The full method for secure refresh-token issuance to native apps is documented under SMART Authorization → Native Applications.
5. Sandbox & Manual Registration
A free sandbox with synthetic patient data is available for development and testing. To request sandbox access or to register a production application manually, contact support@retinex.ai. There is no fee for access to the sandbox, test data, or registration.
6. Verification of API Users
Production registration verifies the developer's identity and contact information and the ownership of claimed redirect URIs/domains. Verification criteria are objective and uniformly applied to all similarly situated API users, consistent with §170.404(a)(3) and the non-discrimination condition at §170.404(a)(4)(i).
7. Change Log
| Date | Version | Change |
|---|---|---|
| 2026-06-03 | 1.0 | Initial public application-registration documentation for §170.315(g)(10). |