Configurar y utilizar la API REST
Consultar citas libres y reservar citas, directamente desde su propia aplicación.
La API trabaja con JSON y se llama a través de la dirección https://example.com/api.
El proceso de reserva consta de seis llamadas que se basan una en otra: calendario, motivo de cita, día, hora, campos de formulario y, por último, la reserva.
Todas las llamadas se realizan desde su servidor, no desde el navegador de sus clientes.
Paso 1: activar la API y generar el token
La API está desactivada en el estado de entrega. Usted la activa en el área de administración.
- Haga clic en la navegación en Configuración.
- Haga clic en la subnavegación en Configuración general.
- Haga clic en la lista en Interfaz.
- Active API activar. El cambio se guarda inmediatamente.
- Haga clic en Generar nuevo token para crear el token de acceso de la interfaz.
- Copie el token mostrado inmediatamente y guárdelo de forma segura, no se vuelve a mostrar.
Capturas de pantalla
Haga clic en la navegación en Configuración
1
Haga clic en la subnavegación en Configuración general
2
Haga clic en la lista en Interfaz
3
Active API activar. El cambio se guarda inmediatamente
4
Haga clic en Generar nuevo token para crear el token de acceso de la interfaz
5
Copie el token mostrado inmediatamente y guárdelo de forma segura, no se vuelve a mostrar
6
El token empieza por apm_, seguido de 64 caracteres, y se muestra una sola vez. En el sistema se guarda únicamente un hash, el token en sí ya no se puede consultar más adelante.
Hay exactamente un token por instalación: si genera un token nuevo, el anterior pierde su validez inmediatamente.
El token se envía en cada llamada en la cabecera de la petición:
Authorization: Bearer apm_su-token
Paso 2: comprobar la conexión y consultar los calendarios de citas
Con la primera llamada comprueba la conexión y obtiene los números de sus calendarios de citas.
curl -H "Authorization: Bearer apm_su-token" \
https://example.com/api/schedules
Respuesta:
{
"data": [
{ "id": 1, "name": "Sede principal" },
{ "id": 2, "name": "Sucursal" }
]
}
El id del calendario deseado se utiliza en todas las demás llamadas como parámetro schedule.
Paso 3: consultar los motivos de cita
curl -H "Authorization: Bearer apm_su-token" \
"https://example.com/api/reasons?schedule=1"
Respuesta:
{
"data": [
{
"id": 1,
"name": "Consulta de asesoramiento",
"description": "Asesoramiento estándar",
"duration": 1800
},
{
"id": 2,
"name": "Cita de seguimiento",
"description": "",
"duration": 900
}
]
}
duration es la duración en segundos (1800 segundos equivalen a 30 minutos).
El id se sigue utilizando como parámetro reason. Si un calendario no tiene motivos de cita configurados, data está vacío.
Paso 4: consultar los días con citas libres
curl -H "Authorization: Bearer apm_su-token" \
"https://example.com/api/days?schedule=1&reason=1"
Respuesta:
{
"data": ["2026-05-23", "2026-05-24", "2026-05-26"]
}
Solo se devuelven los días en los que hay al menos un horario de cita libre. Hasta dónde llega la lista en el futuro lo determinan los ajustes de su calendario de citas.
Paso 5: consultar las horas libres de un día
curl -H "Authorization: Bearer apm_su-token" \
"https://example.com/api/slots?schedule=1&reason=1&day=2026-05-23"
Respuesta:
{
"data": [
"2026-05-23 09:00:00",
"2026-05-23 09:30:00",
"2026-05-23 10:00:00"
]
}
Las horas son horas locales de su instalación, el formato es siempre AAAA-MM-DD HH:MM:SS.
Paso 6: consultar los campos de formulario de la reserva
Qué campos se necesitan para una reserva lo define usted mismo en el planificador de citas. Por eso consulte siempre los campos en lugar de fijarlos en su propio programa.
El espacio del parámetro slot se debe codificar como %20.
curl -H "Authorization: Bearer apm_su-token" \
"https://example.com/api/forms?schedule=1&reason=1&slot=2026-05-23%2009:00:00"
Respuesta:
{
"data": {
"first_name": {
"form_type": "textbox",
"input_type": "text",
"label": "Nombre",
"required": true,
"value": ""
},
"last_name": {
"form_type": "textbox",
"input_type": "text",
"label": "Apellidos",
"required": true,
"value": ""
},
"email": {
"form_type": "textbox",
"input_type": "email",
"label": "Dirección de email",
"required": false,
"value": ""
}
}
}
Todos los campos con "required": true se deben rellenar en la reserva. El campo password nunca lo devuelve la API.
Paso 7: reservar la cita
La reserva es la única llamada con el método POST. La cabecera debe contener Content-Type: application/json.
En submission introduce los valores de los nombres de campo del paso 6.
curl -X POST https://example.com/api/bookings \
-H "Authorization: Bearer apm_su-token" \
-H "Content-Type: application/json" \
-d '{
"schedule": 1,
"reason": 1,
"slot": "2026-05-23 09:00:00",
"submission": {
"first_name": "Hans",
"last_name": "Pitt",
"email": "hans.pitt@example.com"
}
}'
Respuesta en caso de éxito (estado 201):
{
"booking_id": 142,
"booking_details_id": "a3f8c2d1e5b6",
"user_id": 87,
"slot": "2026-05-23T09:00:00Z"
}
booking_id: el número de la cita para sus propios registrosbooking_details_id: el identificador con el que su cliente puede consultar los detalles de su citauser_id: el registro de cliente creado con la reservaslot: el inicio de la cita, aquí en UTC según ISO 8601
Con esto la cita queda registrada en el planificador de citas. Los emails de notificación se envían igual que en cualquier otra reserva.
Mensajes de error
Los errores también se devuelven como JSON, por ejemplo {"error":"Unauthorized"}.
- 400 Invalid request:
scheduleoreasonno es un número,slotno tiene el formatoAAAA-MM-DD HH:MM:SSo faltasubmission. - 400 Invalid JSON: el conjunto de datos enviado no es JSON válido.
- 400 Required field empty: falta un campo obligatorio del paso 6. El campo afectado aparece en
field. - 401 Unauthorized: el token falta, es incorrecto o ha sido sustituido por uno nuevo. Algunos servidores eliminan la cabecera
Authorization; en caso de duda pregunte a su proveedor. - 404 Schedule/Reason/Day/Slot not found: el número consultado, el día o la hora ya no está disponible.
- 404 Not found: la dirección es incorrecta o falta un parámetro o tiene un formato incorrecto. Los parámetros que faltan no generan, por tanto, un error 400, sino 404.
- 415 Unsupported Media Type: en la reserva falta
Content-Type: application/json. - 429 Too Many Requests: se ha alcanzado el límite de 300 peticiones por minuto. La cabecera
Retry-Afterindica el tiempo de espera en segundos. - 500 Failed to create user/appointment: la cita no se ha podido guardar.
- 503 API disabled: la API no está activada (véase el paso 1).
- 503 Not configured: la instalación todavía no está terminada.
Indicaciones
- El orden de las llamadas es obligatorio: cada llamada devuelve el dato que necesita la siguiente.
- Las horas se envían en hora local, la respuesta de la reserva contiene la cita en UTC.
- Entre la consulta de una hora libre y la reserva, la cita puede ser ocupada por otra persona. En ese caso (error 404 Slot not found) vuelva a consultar las horas libres.
- Los calendarios y los motivos de cita cambian pocas veces y se pueden almacenar en caché. Los días y las horas libres conviene consultarlos siempre de nuevo.
- La API está pensada para la comunicación entre servidores. No se envían cabeceras CORS, por lo que no es posible una llamada directa desde el navegador. El token no se debe integrar en un sitio web ni en una app.
- Cada reserva crea un registro de cliente. Las citas creadas a través de la API se reconocen en el planificador de citas por la fuente
api. - Por el momento no están incluidos: la cancelación y el cambio de fecha de citas, la lectura de citas existentes y una salida por páginas. Para los avisos automáticos a sistemas externos utilice el módulo Webhooks.
- La referencia técnica completa con todos los parámetros, códigos de estado y esquemas está disponible en Referencia de la API REST, y la descripción legible por máquina según OpenAPI 3.1 como openapi.json. Ambos archivos están también en su propia instalación, en
https://example.com/api/docs.htmlyhttps://example.com/api/openapi.json.
Volver al resumen: Módulo "API (interfaz)".