Tres endpoints y nada más
La superficie pública es chica a propósito: dos consultas abiertas de datos de referencia y una escritura autenticada. Alcanza para que el sitio de una organización reciba solicitudes de pacientes sin sacar a nadie de su propia web.
01 Base y formato
Todo cuelga del prefijo /api y responde application/json.
Es una API sin estado: no hay cookies ni sesión, y el cuerpo de las respuestas
siempre trae un status.
https://cannis.org/api
Los dos endpoints abiertos están limitados a 60 pedidos por minuto por IP. Si vas a poblar un selector, cacheá la respuesta del lado de tu sitio: las provincias no cambian.
02 Autenticación
Provincias y localidades son abiertas. La escritura no: va con un token
que se emite por organización y viaja en el encabezado
Authorization. El token identifica a la organización, así que no hace
falta —ni se puede— mandar cuál es: la solicitud queda asociada a la que emitió el
token.
Authorization: Bearer <tu-token> Accept: application/json
- Un token puede tener fecha de vencimiento o no tenerla.
- Un token revocado deja de funcionar al instante.
- Cada uso queda registrado: se puede auditar qué integración escribió qué.
03 Provincias
Devuelve las provincias argentinas con el identificador que después espera el alta de solicitud. Sin parámetros.
[
{ "id_provincia": 1, "nombre": "Buenos Aires" },
{ "id_provincia": 2, "nombre": "Catamarca" }
]
curl https://cannis.org/api/provincias
04 Localidades
Las localidades de una provincia. El clásico segundo selector.
id_provincia que devolvió el endpoint anterior.
Tiene que existir.
[
{ "id": 1042, "nombre": "Rosario" },
{ "id": 1043, "nombre": "Venado Tuerto" }
]
curl "https://cannis.org/api/localidades?id_provincia=21"
Guardate el id: es lo que después va en el campo
localidad del alta de solicitud, igual que el
id_provincia va en provincia.
05 Solicitud de paciente
El único endpoint que escribe. Está pensado para el formulario de ingreso que una organización publica en su propio sitio: la persona completa sus datos ahí y la solicitud entra al panel de esa organización, que recibe además un aviso por correo.
Se envía como multipart/form-data, porque admite archivos.
Está protegido con reCAPTCHA: el formulario tiene que resolverlo del lado
del navegador y mandar el resultado.
Los nombres de campo de esta página describen qué datos pide el endpoint, no cómo se llaman exactamente en el cuerpo del pedido. Los nombres definitivos te los pasamos junto con el token, cuando coordinamos la integración.
AAAA-MM-DD.
id_provincia del endpoint de provincias.
id del endpoint de localidades.
curl -X POST https://cannis.org/api/post/solicitud_paciente \ -H "Authorization: Bearer <tu-token>" \ -H "Accept: application/json" \ -F "nombre=Lucía" \ -F "apellido=Fernández" \ -F "documento=30111222" \ -F "fecha_nacimiento=1983-04-12" \ -F "[email protected]" \ -F "celular=3415551234" \ -F "provincia=21" \ -F "localidad=1042" \ -F "calle=San Martín" \ -F "numero=1234" \ -F "reprocann=1" \ -F "consentimiento=1" \ -F "captcha=<token-del-captcha>" \ -F "[email protected]"
{
"status": "success",
"message": "Tu solicitud ha sido enviada exitosamente."
}
06 Errores
Los errores de validación vienen en messages, ya redactados en
español y con el nombre legible del campo: se pueden mostrar tal cual al lado del
formulario.
{
"status": "error",
"messages": [
"Email: Ya existe un registro con ese Email en esta ONG.",
"Documento: El Documento debe contener entre 8 y 9 números."
]
}
Authorization o no arranca con Bearer.
¿Vas a integrarte? Escribinos: el token se emite por organización y te acompañamos en la primera prueba.