Auto Scheduler
PreciosZona de pruebaFlujoBlogPreguntas FrecuentesDocumentación API
Iniciar sesión

En esta página

Descripción generalAlcanceSuscripción y facturaciónAutenticaciónEndpointUso (inicio rápido)API de lectura (GET)API de escritura (PATCH / POST / PUT / DELETE)CabecerasLímites y valores por defectoClaves raíz permitidasCuerpo de la solicitud (resumen)Tabla de referencia rápidaReferencia de campos (valores permitidos)apiVersiontimeZonescheduleStartDate / scheduleEndDatetimeRangeStart / timeRangeEndslotGranularityMinutesrequirementsByCellstaffavailableCellsLegislación laboral y flags de pago (valores del servidor)SanitizaciónRespuesta correctaCódigos de error (lista completa)Ejemplo JSONMás información
API de pago · Suscripción

Referencia de API para desarrolladores (pago)

Integre la API de producción para enviar cuadrantes con una clave API vinculada a su suscripción de pago. Los valores predeterminados del inquilino se guardan con PATCH /v1/schedule-defaults; los deseos semanales por empleado se leen o sustituyen con GET/PUT /v1/staff/{staffId}/weekly-shift-wish. La facturación sigue su plan y contrato (no por llamada API medida). Esta página documenta límites, validaciones y códigos de error — use la barra lateral para ir a cada campo.

Alcance de esta documentación

Esta página documenta solo la API REST de producto en API Gateway ({stage}/v1/*, autenticación con x-api-key).

Las rutas Next.js /api/* (webhooks de Stripe, imágenes OG, Web Vitals, etc.) son internas de la aplicación web y no forman parte de esta API para desarrolladores. No las use para integraciones externas.

GET /v1/processing-history no se ofrece (eliminado con la interfaz antigua) y no figura en la lista de endpoints de esta página.

Suscripción y acceso

Esta API HTTP forma parte del producto de pago: el acceso requiere un acuerdo comercial activo y las claves se emiten a su organización tras el onboarding.

La facturación se basa en la suscripción y el contrato. En planes de pago, los cargos suelen seguir la página de precios (p. ej. por miembro de plantilla y mes).

Los límites del playground o del nivel gratuito no aplican a las claves de API de pago. Los límites efectivos (días, personal, granularidad de 15 minutos) los fijan sus derechos de pago. Consulte Límites y valores por defecto en esta página.

Autenticación

Las solicitudes deben incluir una clave API válida emitida con su suscripción de pago. Cree, rote y revoque claves desde el área de cuenta tras iniciar sesión.

Envíe la clave en la cabecera x-api-key. Las claves están ligadas a su organización para la resolución del inquilino y los límites de acceso del plan contratado.

Gestionar claves: Gestión de API

Endpoint

Envíe una condición de cuadrante como JSON. Es la superficie de integración de pago; la URL base exacta se proporciona por entorno tras aprovisionar el acceso a la API.

POST {baseUrl}/v1/schedule

Use la URL base proporcionada cuando se aprovisionó el acceso a la API o por su contacto de operaciones.

Uso (inicio rápido)

Sustituya BASE_URL por la URL base de la API (prefijo de ruta) proporcionada cuando se aprovisionó su acceso.

Envíe su clave API en la cabecera **x-api-key**. Su organización (inquilino) se identifica a partir de la clave; no pasa un id de inquilino aparte en la cadena de consulta.

La lectura y actualización de datos de empresa (GET/PATCH /v1/company) requiere una suscripción de pago activa. Si la facturación no está configurada para su inquilino, puede recibir **503** (p. ej. código **STRIPE_NOT_CONFIGURED**).

Ejemplo con curl (bash / macOS / Linux / WSL)

Windows PowerShell: una barra invertida final `\` **no** continúa la línea. Escriba en una sola línea, o termine cada línea con acento grave (`) para continuar.

curl -sS -D - \
  -H "x-api-key: YOUR_API_KEY" \
  "BASE_URL/v1/schedule-results?limit=10"

curl -sS -D - \
  -H "x-api-key: YOUR_API_KEY" \
  "BASE_URL/v1/company"

API de lectura (GET)

Misma URL base y misma x-api-key que POST /v1/schedule. Consulta opcional: limit (1–100, predeterminado 50), cursor (token opaco: reenvíe el campo nextCursor de la respuesta anterior).

GET /v1/company y las actualizaciones de empresa requieren una suscripción de pago activa. Si la facturación no está configurada, puede recibir **503 / STRIPE_NOT_CONFIGURED**.

MétodoRutaDescripción
GET{baseUrl}/v1/schedule-resultsLista filas padre SCHEDULE_RESULT: conditionId, status, candidateCount, createdAt/updatedAt, etc. Paginación DynamoDB.
GET{baseUrl}/v1/schedule-results/historyBúsqueda de historial de resultados (como en el navegador). from / to (ISO 8601, predeterminado inicio de servicio a ahora), keyword, eventName (INSERT,MODIFY,REMOVE separados por comas), limit, cursor. Fusiona reciente y archivo automáticamente; solo items / nextCursor.
GET{baseUrl}/v1/schedule-results/{conditionId}Obtiene una fila padre SCHEDULE_RESULT por conditionId (atributos JSON; sin PK/SK).
GET{baseUrl}/v1/schedule-results/{conditionId}/resolutionSalida de optimización resuelta: status, candidates, confirmedAssignments si existen. Si status es completed y aún no confirmado, rank-1 puede auto-confirmarse en este GET (efecto secundario). Use POST …/confirm-assignments para confirmación manual.
GET{baseUrl}/v1/schedule-results/{conditionId}/reviewCarga de revisión para confirmación manual (candidatos, requiredByCellKey, allowedCellKeys del personal, etc.).
GET{baseUrl}/v1/schedule-results/{conditionId}/emergency-shift-contextContexto de turno de emergencia (fechas, personal, franjas). Requiere suscripción de pago; null si no hay condición.
GET{baseUrl}/v1/schedule-conditionsLista filas padre SCHEDULE_CONDITION (conditionId, fechas, publicApiCancelledAt opcional).
GET{baseUrl}/v1/schedule-conditions/{conditionId}Fila padre de condición más reqDays y staffSnapshots (sin PK/SK).
GET{baseUrl}/v1/audit-logsLista entradas de auditoría (más recientes primero; paginación con cursor).
GET{baseUrl}/v1/schedule-defaultsFila de valores predeterminados del inquilino (SCHEDULE_DEFAULTS) o null si no guardada.
GET{baseUrl}/v1/schedule-actual/{conditionId}Fila SCHEDULE_ACTUAL de turnos reales, o null si no existe.
GET{baseUrl}/v1/staff/{staffId}/weekly-shift-wishFila de deseos semanales del empleado, o null si no existe.
GET{baseUrl}/v1/companyDevuelve campos de Stripe Customer (nombre, correo, teléfono, dirección) para el customerId de su clave API.
GET{baseUrl}/v1/usersLista usuarios del inquilino (opcional: limit, cursor, userName, permissionProfileId, scope fullAccess|nonFullAccess).
GET{baseUrl}/v1/users/{userId}Obtiene un usuario por el userId de la ruta.
GET{baseUrl}/v1/staffLista personal activo del inquilino (ordenado por nombre mostrado).
GET{baseUrl}/v1/staff/{staffId}Obtiene una persona por staffId con detalles laborales (laborLawCompliance, laborFlsaExempt, topes personales, laborConstraintMask). Borrado lógico → 404.

API de escritura (PATCH / POST / PUT / DELETE)

Use la misma clave API con cuerpos JSON. PATCH /v1/company rechaza cadenas vacías en campos como el nombre de la empresa (alineado con la aplicación web). PATCH /v1/schedule-defaults guarda valores predeterminados del inquilino (requirementsByCellKey, horizonte de planificación, etc.); los campos de pago siguen su suscripción. PUT /v1/staff/{staffId}/weekly-shift-wish sustituye por completo la cuadrícula semanal de deseos (véase la nota de validación). DELETE /v1/users/{userId} devuelve 409 si no quedarían usuarios activos o al quitar al último administrador. POST /v1/staff devuelve 409 STAFF_LIMIT si la plantilla superaría el tope del inquilino.

POST /v1/users exige userName, email, permissionProfileId; opcional: locale, password. PATCH usuario: solo campos a cambiar. POST /v1/staff: JSON { "displayName": "..." } únicamente. PATCH /v1/staff/{staffId}: displayName, laborLawCompliance, laborFlsaExempt, personalMaxWeeklyMinutes / personalMaxMonthlyMinutes / personalMaxThreeMonthMinutes (entero o null), laborConstraintMask (objeto o null si laborLawCompliance true) — campos laborales de pago. POST /v1/schedule-results/{conditionId}/emergency-shift: absentStaffIds, absentDatesYmd y/o absentSlots (pago, plan fuente completado). POST …/confirm-assignments: array assignments y relaxAvailability opcional. PATCH /v1/schedule-defaults: PUBLIC_API_SCHEDULE_REQUEST_BODY.md §12. PUT /v1/staff/{staffId}/weekly-shift-wish: scheduleStartDate, scheduleEndDate, timeRangeStart, timeRangeEnd, wishByCellKey.

MétodoRutaDescripción
PATCH{baseUrl}/v1/companyActualiza los campos del perfil de la empresa (cliente de facturación).
PATCH{baseUrl}/v1/schedule-defaultsGuarda valores predeterminados de planificación del inquilino (cuerpo JSON alineado con saveSchema en schedule-defaults-actions). Los campos de pago siguen su suscripción.
POST{baseUrl}/v1/usersCrea un usuario. Devuelve 201 con JSON de usuario.
PATCH{baseUrl}/v1/users/{userId}Actualiza campos del usuario (userName, email, permissionProfileId, locale).
DELETE{baseUrl}/v1/users/{userId}Elimina un usuario. 409 si no quedarían usuarios o por la regla del último administrador.
POST{baseUrl}/v1/staffCrea una persona (displayName). Devuelve 201 con JSON staff.
POST{baseUrl}/v1/schedule-results/{conditionId}/emergency-shiftClona un plan fuente completado con ausencias aplicadas; devuelve 201 con conditionId. Requiere suscripción de pago.
POST{baseUrl}/v1/schedule-results/{conditionId}/confirm-assignmentsValida y guarda asignaciones editadas manualmente (200 con { ok: true }).
PATCH{baseUrl}/v1/staff/{staffId}Actualiza displayName y detalles laborales (laborLawCompliance, laborFlsaExempt, topes personales, laborConstraintMask).
DELETE{baseUrl}/v1/staff/{staffId}Borrado lógico de una persona (establece deletedAt).
DELETE{baseUrl}/v1/schedule-conditions/{conditionId}Marca la condición como cancelada (publicApiCancelledAt); no elimina filas hijas.
PUT{baseUrl}/v1/schedule-actual/{conditionId}Guarda asignaciones reales JSON { "assignments": [ ... ] } (validadas contra la cuadrícula de la condición).
PUT{baseUrl}/v1/staff/{staffId}/weekly-shift-wishSustituye los deseos semanales: cuadrícula completa (1–7 días), wishByCellKey por celda (NONE|LOW|HIGH); granularidad según valores predeterminados del inquilino.
POST{baseUrl}/v1/users/{userId}/restoreRestaura un usuario borrado lógicamente.

Cabeceras

CabeceraDescripción
x-api-keyClave API vinculada a su suscripción de pago (identifica el inquilino y los límites del plan).
Content-Typeapplication/json

Cabeceras de respuesta

Algunas cabeceras de respuesta (como ids de solicitud) son metadatos de trazabilidad, no su clave API. Trate los **cuerpos** JSON como confidenciales cuando contengan datos de empresa o de usuario.

Límites del plan de pago (derechos)

Límites de validación habituales para su contrato (granularidad de 15 minutos, duración del cuadrante, número de personal registrado y límites relacionados).

AjusteAPI de pago (típico)
Modelo de facturaciónSuscripción Stripe; los cargos del producto suelen escalar con los asientos de personal registrados según la página de precios (no por llamada API).
maxScheduleDaysHasta 14 días naturales por envío en la planificación detallada estándar de dos semanas (plazas mayores solo si el contrato lo permite).
maxStaffPerScheduleHasta 500 filas staff por POST /v1/schedule (PUBLIC_SCHEDULE_MAX_STAFF; staffId en línea en el cuerpo).
maxRosterStaffHasta 30 empleados activos vía POST /v1/staff con el tope predeterminado actual (STAFF_ROSTER_MAX_PAID); 409 STAFF_LIMIT si se supera.
allowedGranularities[60, 15] — los slots de 15 minutos son de pago; 60 minutos también está soportado.
maxPayloadBytes524288 (512 KiB) UTF-8 salvo que se conceda un tope mayor.
strictUnknownRootKeystrue — se rechazan claves desconocidas en la raíz o en staff

La necesidad de personal por celda sigue siendo un entero de 0 a 15. Al superar los límites de tasa puede devolverse una respuesta de error.

Claves raíz permitidas (modo estricto)

Con el modo estricto solo se aceptan las siguientes claves de nivel superior. Cualquier otra devuelve UNKNOWN_FIELD.

  • apiVersion
  • timeZone
  • scheduleStartDate
  • scheduleEndDate
  • timeRangeStart
  • timeRangeEnd
  • slotGranularityMinutes
  • requirementsByCell
  • staff

Cuerpo de la solicitud (resumen)

El payload sigue el modelo público de pago: fechas de calendario, zona horaria, rejilla de slots (60 o 15 minutos en la API de pago), necesidades por celda y disponibilidad del personal. La jurisdicción laboral, los flags de optimización de pago y los campos laborales por empleado no forman parte del JSON: el servidor escribe valores por defecto en la fila padre SCHEDULE_CONDITION al persistir (véase «Legislación laboral y flags de pago»). No incluya claves DynamoDB ni tipos de entidad internos en el cuerpo.

  • apiVersion — Opcional. Si está presente, solo la cadena de versión de esquema admitida.
  • Formato de cellKey — Las claves en requirementsByCell y availableCells deben coincidir con `${date}__${slotId}`, donde date es YYYY-MM-DD en el rango y slotId proviene de los slots enumerados para su rango horario y granularidad (igual que `cellKey` en los helpers del playground).

Tabla de referencia rápida

CampoTipoObligatorioNotas
timeZonestringSíZona horaria IANA para interpretar fechas y slots.
scheduleStartDate / scheduleEndDatestring (YYYY-MM-DD)SíRango de calendario inclusivo; inicio ≤ fin.
timeRangeStart / timeRangeEndstring (HH:mm)SíRango horario que define la columna de slots; debe generar al menos un slot.
slotGranularityMinutes60 | 15SíAPI de pago: 60 (hora) o 15 (cuartos). Debe estar en allowedGranularities.
requirementsByCellobjectSíClaves = cellKey en la rejilla calculada; valores = entero 0–15.
staffarraySíNo vacío; tamaño máximo según límites; cada ítem: staffId, displayName, availableCells opcional.

Referencia de campos (valores permitidos)

Las siguientes secciones reflejan el validador en `app/lib/public-schedule-api/validate.ts` y los sanitizadores en `sanitize.ts`, con los valores por defecto de pago de `PUBLIC_SCHEDULE_SUBMIT_DEFAULTS` salvo que se pasen opciones. Envíe números JSON como números reales (no como strings). Tras la validación, `build-schedule-transact-items.ts` añade campos de la fila padre (copia de optimización de pago, jurisdicción laboral, versión del modelo) que no son claves de la solicitud — véase «Legislación laboral y flags de pago».

apiVersion

string | omitido · Obligatorio: No — opcional

Valores permitidos

  • Omitido: aceptado (comportamiento actual).
  • Si está presente, debe ser exactamente "2026-04-01" (PUBLIC_SCHEDULE_API_VERSION).
  • Cualquier otra cadena se rechaza (TYPE_ERROR).

Comportamiento

  • Comparación tras el manejo equivalente a trim en sanitizeApiVersion.

Errores típicos

  • TYPE_ERRORValor de apiVersion no admitido.

timeZone

string · Obligatorio: Sí

Valores permitidos

  • Formato: una sola cadena. La API no publica un enum cerrado de todas las zonas: el servidor valida dinámicamente.
  • La validación coincide con `isValidIanaTimeZone`: Luxon `DateTime.now().setZone(zone).isValid` debe ser true.
  • Use identificadores canónicos de la base IANA, p. ej. `Asia/Tokyo`, `America/New_York`, `Europe/Berlin`, `UTC`.
  • No confíe solo en abreviaturas (`EST`, `JST`, `GMT`) — no son IDs IANA estables y pueden rechazarse.
  • Listas de referencia: distribución IANA (https://www.iana.org/time-zones) o la API de zona horaria de su plataforma.

Comportamiento

  • Se usa con fechas y horas de slot en la normalización posterior.
  • Si necesita una lista fija en el cliente, derívela con las mismas reglas (IDs IANA), no espere un enum del servidor en el esquema JSON.

Errores típicos

  • INVALID_TIME_ZONEFalta, vacío o zona IANA no válida.

scheduleStartDate, scheduleEndDate

string, string · Obligatorio: Sí — ambos

Valores permitidos

  • Debe coincidir con /^\d{4}-\d{2}-\d{2}$/ (tras trim).
  • Fechas de calendario reales; el rango inclusivo debe producir al menos un día vía enumerateDates.
  • El número de días no debe superar maxScheduleDays (API de pago típicamente hasta 14 días; el tope exacto = derechos del inquilino).

Comportamiento

  • scheduleStartDate debe ser anterior o igual a scheduleEndDate.

Errores típicos

  • INVALID_DATE_RANGEFormato incorrecto, fechas inválidas o rango vacío.
  • SCHEDULE_SPAN_TOO_LONGMás de maxScheduleDays días.

timeRangeStart, timeRangeEnd

string, string · Obligatorio: Sí — ambos

Valores permitidos

  • Cadenas no vacías (trim) interpretadas con la misma enumeración de slots que la UI (`enumerateSlotsByGranularity`).
  • El par debe generar al menos un slot; si no, falla la validación.

Comportamiento

  • Junto con slotGranularityMinutes define los slotId usados en cellKey.

Errores típicos

  • INVALID_TIME_RANGEValores faltantes o cero slots para el rango.

slotGranularityMinutes

number (número JSON) · Obligatorio: Sí

Valores permitidos

  • Debe ser exactamente 60 o 15 (no una cadena).
  • También debe figurar en allowedGranularities. En la API de pago suelen estar ambos; si 15 está desactivado para su inquilino, INVALID_GRANULARITY.

Comportamiento

  • Define el número de slots junto con el rango horario.

Errores típicos

  • INVALID_GRANULARITYNo es 60/15 o no permitido en el plan.

requirementsByCell

Record<string, number> · Obligatorio: Sí

Valores permitidos

  • Debe ser un objeto JSON plano (no un array).
  • Cada clave debe ser un cellKey en la rejilla esperada (fechas × slotIds). Claves desconocidas → UNKNOWN_CELL_KEY.
  • Cada valor: número JSON entero entre 0 y 15 inclusive.
  • Las celdas omitidas se tratan como necesidad 0 (solo las celdas con necesidad ≥ 1 entran en SHORTFALL).

Comportamiento

  • Las claves se comparan tras trim vía sanitizeCellKey.

Errores típicos

  • INVALID_REQUIREMENTSNo es un objeto o el valor numérico no es válido.
  • UNKNOWN_CELL_KEYClave fuera de la rejilla fecha × slot calculada.

staff

array · Obligatorio: Sí — array no vacío

Valores permitidos

  • Longitud entre 1 y maxStaffPerSchedule (predeterminado 500 en POST /v1/schedule; distinto del tope de plantilla en POST /v1/staff).
  • Cada elemento debe ser un objeto plano solo con claves permitidas: staffId, displayName, availableCells (modo estricto).
  • staffId y displayName deben pasar la sanitización (véase «Sanitización»).
  • staffId debe ser único en el array (DUPLICATE_STAFF_ID).

Comportamiento

  • Se conserva el orden para el recuento de disponibilidad.

Errores típicos

  • INVALID_STAFFArray vacío, demasiadas filas, objeto inválido o sanitización fallida.
  • UNKNOWN_FIELDClave extra en un objeto staff en modo estricto.
  • DUPLICATE_STAFF_IDEl mismo staffId dos veces.

staff[].availableCells

string[] | omitido · Obligatorio: No — opcional

Valores permitidos

  • Si se omite: el empleado se considera disponible en todas las celdas (internamente null = «todas las celdas»).
  • Si está presente: array JSON de strings; cada string no vacío debe ser un cellKey en la rejilla esperada.
  • Las cadenas vacías en el array son inválidas (INVALID_AVAILABLE_CELL).

Comprobación SHORTFALL

  • Para cada celda con necesidad ≥ 1, el número de empleados disponibles debe ser ≥ necesidad, si no SHORTFALL_CELLS.

Errores típicos

  • INVALID_AVAILABLE_CELLClave de celda desconocida o entrada vacía.
  • SHORTFALL_CELLSPersonal insuficiente frente al cupo requerido en una celda.

Legislación laboral y optimización de pago (no van en el JSON)

n/c — persistido en el servidor · En la solicitud: No — nunca envíe estas claves

Qué guarda la API en la fila padre

  • La API pública solo acepta ROOT_KEYS en la raíz y STAFF_KEYS en cada empleado. No envíe laborLawJurisdiction, usLaborStateCode, laborModelVersion ni paidOptimization.
  • Al enviar, el servidor rellena SCHEDULE_CONDITION padre con valores compartidos: paidOptimization = DEFAULT_PAID_OPTIMIZATION — laborLawCompliance false; balanceStaffLoad, honorShiftWishes y preferConsecutiveShifts true (véase schedule-defaults-shared.ts y build-schedule-transact-items.ts). laborLawJurisdiction JP, usLaborStateCode GENERIC, laborModelVersion v1.
  • Las restricciones laborales tipo ley en el optimizador requieren flags de cumplimiento activos en padre y por empleado; esta ruta los deja desactivados: no espere topes legales solo con este JSON.
  • El modelo laboral es una aproximación para la planificación, no asesoramiento legal. Catálogo: optimizer/config/labor_models.json.

Documentación

  • Detalle: docs/data-and-api/PUBLIC_API_SCHEDULE_REQUEST_BODY.md §2.1.1 y §3.1.

Si envía claves no permitidas

  • UNKNOWN_FIELDEl modo estricto rechaza propiedades desconocidas en la raíz o en staff.

Reglas de sanitización

Aplicadas antes o durante la validación según `sanitize.ts`. Explican rechazos como INVALID_STAFF.

staffId

  • Trim; longitud 1–128.
  • Caracteres: /^[a-zA-Z0-9._-]+$/ (sin barras ni contrabarras).

displayName

  • Eliminar caracteres de control y de ancho cero; colapsar espacios; trim.
  • No se permiten los signos < y >.
  • Máx. 128 caracteres tras sanitizar; no puede quedar vacío.

Claves de celda (requirements / availableCells)

  • Las claves se recortan; deben coincidir exactamente con los cellKey de la rejilla calculada.

Respuesta correcta

202 Accepted

El cuerpo pasó la validación y se escribió la condición; la optimización puede continuar de forma asíncrona. El manejador puede devolver JSON con conditionId y campos relacionados.

Códigos de error (lista completa)

Los errores de validación devuelven información estructurada con un `code` estable. El análisis ocurre antes de la validación (INVALID_JSON, PAYLOAD_TOO_LARGE). Los fallos de persistencia pueden aparecer como DYNAMODB_ERROR. PATCH /v1/schedule-defaults puede devolver SCHEDULE_DEFAULTS_SAVE_FAILED (HTTP 400) con detalles.

CódigoSignificado
INVALID_JSONEl cuerpo no es JSON válido.
PAYLOAD_TOO_LARGELa longitud en bytes UTF-8 supera maxPayloadBytes (por defecto 512 KiB).
TYPE_ERRORTipo JSON incorrecto o cadena apiVersion no admitida.
UNKNOWN_FIELDModo estricto: propiedad no permitida en la raíz o en staff.
INVALID_TIME_ZONEtimeZone ausente o no es un nombre IANA válido.
INVALID_DATE_RANGEFechas no YYYY-MM-DD, rango inválido o enumeración vacía.
SCHEDULE_SPAN_TOO_LONGDemasiados días entre inicio y fin (véase maxScheduleDays).
INVALID_TIME_RANGERango horario ausente o genera cero slots.
INVALID_GRANULARITYslotGranularityMinutes no es 60/15 o no permitido en el plan.
INVALID_REQUIREMENTSrequirementsByCell no es objeto o el recuento no es entero 0–15.
UNKNOWN_CELL_KEYClave no está en la rejilla de planificación calculada.
INVALID_STAFFstaff vacío, demasiado grande, fila inválida o sanitización fallida.
DUPLICATE_STAFF_IDValores staffId duplicados.
INVALID_AVAILABLE_CELLEntrada vacía o desconocida en availableCells.
SHORTFALL_CELLSDisponibilidad insuficiente frente a las necesidades.
DYNAMODB_ERRORError transitorio o de persistencia tras la validación (depende del manejador).
SCHEDULE_DEFAULTS_SAVE_FAILEDPATCH /v1/schedule-defaults: validación o reglas de negocio fallidas (véase error.details).
LABOR_COMPLIANCE_REQUIREDPATCH /v1/staff/{staffId}: laborConstraintMask enviado con laborLawCompliance en false.

Ejemplo JSON mínimo

{
  "apiVersion": "2026-04-01",
  "timeZone": "Asia/Tokyo",
  "scheduleStartDate": "2026-04-07",
  "scheduleEndDate": "2026-04-13",
  "timeRangeStart": "08:00",
  "timeRangeEnd": "20:00",
  "slotGranularityMinutes": 60,
  "requirementsByCell": {
    "2026-04-07__slot-0": 2
  },
  "staff": [
    {
      "staffId": "550e8400-e29b-41d4-a716-446655440000",
      "displayName": "Example",
      "availableCells": ["2026-04-07__slot-0"]
    }
  ]
}

Más información. Planes y funciones de pago: docs/architecture/NURSE_SCHEDULING_SERVICE_SPECIFICATION.md. Cuerpo POST /v1/schedule: docs/data-and-api/PUBLIC_API_SCHEDULE_REQUEST_BODY.md §1–§11. PATCH de valores predeterminados del inquilino: mismo archivo §12. Código: app/lib/public-schedule-api/, app/features/schedule-settings/schedule-defaults-actions.ts, app/lib/public-api-write/weekly-shift-wish-tenant.ts. Despliegue: docs/aws/CDK_DEPLOY.md.

Auto Scheduler

Servicio en la nube para optimizar turnos y planificar cuadrantes con reglas y restricciones operativas.

Términos de servicio|Política de privacidad|Divulgaciones legales

Solver (operador)