Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

Autenticación y OAuth

Claves API, OAuth 2.1 con PKCE (lanzamiento independiente SMART on FHIR), id_token de OpenID Connect, ámbitos de paciente SMART v2, tiempos de vida de tokens y el ciclo de vida del consentimiento.

La Plataforma Anpheros acepta tres tipos de credenciales. Cada solicitud lleva exactamente una.

Credencial	Aspecto	Quién	Ve
Clave API	`sk_test_…` (sandbox) / `sk_live_…` (producción)	el servidor de un proyecto	los pacientes que el proyecto creó (en sandbox, incluyendo su propia copia de 30 pacientes sintéticos)
Token de acceso OAuth	`at_…`	una aplicación actuando en nombre de un paciente bajo un consentimiento	solo ese paciente, dentro de los ámbitos SMART concedidos
Token de ID de Firebase	JWT	un desarrollador en el panel, o un paciente en "Conexiones"	sus propias organizaciones / sus propios registros

Envíalo como Authorization: Bearer <credential> (las claves API también funcionan como X-Api-Key).

Claves de API

Creadas en el panel o a través de POST /admin/projects/{id}/keys; se muestran una vez; se almacenan como hash SHA-256.
Ámbitos (Scopes): read, write. Una clave nunca cruza el entorno de su proyecto (sk_test_ no puede acceder a datos de producción y viceversa).
El límite de tasa por clave (por defecto 600/min) se aplica en toda la plataforma (almacén compartido), con Retry-After en 429. También hay un límite por IP de 600/min.
Cabeceras opcionales en escrituras: X-Anpheros-Author-Type, X-Anpheros-Author-Ref, X-Anpheros-Source-System, X-Anpheros-Origin-Id, X-Anpheros-Acting-As (un Practitioner/PractitionerRole de su propio directorio), X-Anpheros-On-Behalf-Of (una Organization de su propio directorio). Estas rellenan Provenance.

OAuth 2.1 (SMART on FHIR, lanzamiento independiente)

Descubrimiento: GET /.well-known/smart-configuration.

GET /oauth/authorize?response_type=code&client_id=…&redirect_uri=…&scope=…&state=…&code_challenge=…&code_challenge_method=S256[&purpose=treatment][&patient=<pairwise id>][&lang=ro] Muestra la página de consentimiento alojada. PKCE S256 es obligatorio; el redirect_uri debe registrarse exactamente.
El paciente inicia sesión (Google o correo electrónico a través de Firebase), elige el registro (propio o de un dependiente), la duración (30/90/180/365 días) y autoriza. La plataforma emite un código de un solo uso (10 minutos).
POST /oauth/token con grant_type=authorization_code&code=…&code_verifier=…&redirect_uri=…&client_id=… (los clientes confidenciales añaden client_secret). Respuesta: access_token (30 min), refresh_token (30 días, rotatorio), patient (su ID de par para el registro), grant_id, scope.
Actualización: grant_type=refresh_token. Cada token de actualización es de un solo uso. Presentar un token de actualización usado revoca toda la cadena (detección de robo). Se rechaza una solicitud duplicada en paralelo de una solicitud de actualización y también puede revocar la cadena, así que nunca rote concurrentemente.
Revocar: POST /oauth/revoke (token + client_id). Revocar un token de actualización también revoca sus tokens de acceso.

Las respuestas de token llevan Cache-Control: no-store y Pragma: no-cache, como requiere SMART.

OpenID Connect (`openid fhirUser`)

Solicite openid fhirUser junto con los ámbitos del paciente y la respuesta del token también contiene un id_token: un JWT firmado con RS256, con iss (la URL base de la plataforma), sub (su ID de par para la persona), aud (su client_id), exp, iat y fhirUser — la URL absoluta del recurso Patient de la persona, legible con el token de acceso que acaba de recibir. El descubrimiento se encuentra en GET /.well-known/openid-configuration; las claves públicas en GET /oauth/jwks (kid en la cabecera del token). El parámetro nonce aún no es compatible (es opcional en el flujo de código de autorización). Se aceptan launch/patient y offline_access; el campo patient de la respuesta del token es el contexto de lanzamiento.

Otros tipos de concesión: client_credentials (clientes confidenciales; se comporta como una clave API), y la concesión de identidad de primera parte (solo clientes de confianza).

Su marca en la página de consentimiento

Una aplicación puede mostrar su logotipo y color de acento en la página de consentimiento alojada. Configúrelos en la consola (Aplicaciones → Marca) o con la API de administración:

PUT /admin/applications/{application_id}/branding
{"logo": "data:image/png;base64,…", "brand_color": "#1D4ED8"}

Logo: una imagen PNG, JPEG o WebP como URI de datos, hasta 64 KB. Se comprueba el contenido, no el tipo declarado; SVG no se acepta. La imagen se almacena con la aplicación y se incrusta en la página, por lo que la página de consentimiento no realiza ninguna solicitud a sus servidores.
Color de acento: #RRGGBB, utilizado para el botón principal. El texto blanco sobre él debe mantener un contraste de al menos 4.5:1 (WCAG AA); se rechazan los colores más claros.
Un campo que omita permanece como está; null o una cadena vacía lo eliminan.

El resto de la página no cambia: la línea "Protegido por Anpheros Platform", la lista en lenguaje sencillo de lo que solicita la aplicación y el banner de PRUEBA en los proyectos sandbox permanecen, para que las personas siempre puedan saber que el consentimiento lo mantiene Anpheros. Los conectores de IA (MCP) siempre muestran la página de Anpheros sin marca de aplicación.

Ámbitos

Ámbitos de paciente SMART v2: patient/<Type>.<cruds> con un filtro opcional ?category=<code> (el único filtro que el servidor aplica; cualquier otro filtro se rechaza en el momento de la autorización). patient/*.rs lee todo; offline_access añade un token de actualización. La información demográfica del paciente y el directorio siempre son legibles bajo una concesión. Un tipo de recurso fuera de la concesión devuelve 403; un paciente fuera de la concesión devuelve 404.

Ciclo de vida del consentimiento

Los consentimientos caducan automáticamente, pueden ser revocados por el paciente en cualquier momento (pantalla Conexiones / /me), y cada lectura bajo un consentimiento se registra con el ID de la aplicación. Los webhooks consent.granted / consent.revoked notifican al proyecto.

Errores

401 credencial desconocida/expirada · 403 la credencial existe pero puede que no tenga permiso para esta acción · 404 el recurso no existe para ti · 429 límite de peticiones alcanzado (Retry-After). Ver errors.md.