--- title: "Obtener las fechas de calendario de una charge schedule strategy" method: POST path: "/{country_code}/public/charge-schedules/assignments/calendar-dates" tags: ["Sin catalogar"] --- # Obtener las fechas de calendario de una charge schedule strategy `POST /{country_code}/public/charge-schedules/assignments/calendar-dates` ## Request - Base URL: `https://api.trytoku.com` - URL: `https://api.trytoku.com/{country_code}/public/charge-schedules/assignments/calendar-dates` - Auth: API key in header `x-api-key` Calcula las fechas de calendario (de cobro) que producirían las reglas de recurrencia de una estrategia. El país (tomado del path) define la zona horaria y el calendario de días hábiles/feriados. La recurrencia se toma de la estrategia guardada (``id_charge_schedule_strategy``) cuando existe; si no, del payload enviado en línea. Retorna un mapa "YYYY-MM-DD" -> {type, times}, donde type es SCHEDULED para los días que provienen de charge_schedules y FILL_UP para los días agregados por el comportamiento fill-up. ## Path parameters - `country_code` 'cl' | 'mx' | 'br', required: Códigos de país admitidos en el prefijo de ruta `/{country_code}`. ## Headers - `x-account-key` string ## Request body - CalendarDatesPayload: Calcula las fechas de calendario (de cobro) que producirían las reglas de recurrencia de una estrategia, sin persistir nada. Hay dos formas de entregar la fuente de la recurrencia: - ``id_charge_schedule_strategy``: cuando viene definido y la estrategia existe, las fechas se calculan a partir de la estrategia **guardada** (sus ``recurrence_rules`` / ``charge_schedules`` / ``default_charge_behaviour`` / ``default_charge_time``) — vista previa de una estrategia guardada; - en caso contrario se usan los ``recurrence_rules`` + ``charge_schedules`` enviados en línea (+ los opcionales ``default_charge_behaviour`` / ``default_charge_time``) — vista previa de una estrategia que aún no se guarda. Se debe entregar al menos una de las dos. ``default_charge_behaviour`` por defecto es ``SKIP_UNSCHEDULED_DAY`` (sin relleno); un valor ``FILL_UP_*`` además incluye los días rellenados, usando ``default_charge_time`` como su hora del día. Con ``a_b_testing_branch`` en ``TESTING`` las fechas son las de la rama de testing del A/B testing de ``id_charge_schedule_strategy_assignment``: se mantienen las reglas de recurrencia y el relleno, pero los ``charge_schedules`` se reemplazan por el ``charge_schedule_override`` del experimento. ``CONTROL`` cobra con la programación de la estrategia, igual que sin rama. - `a_b_testing_branch` 'CONTROL' | 'TESTING': An enumeration. - `charge_schedules` ChargeSchedule[] - `charge_max_start_time` string - `charge_start_time` string - `date` string, date-time - `day_offset` integer - `id_charge_schedule` string - `independent_attempt` boolean - `retry_schedules_configuration` RetrySchedulesConfiguration - `recurring_retry_configuration` RecurringRetryConfiguration - `max_retries` integer, required - `retry_calendar_type` 'BUSINESS' | 'CALENDAR', required: Unidad en que se interpreta un conteo de días: `CALENDAR` cuenta todos los días y `BUSINESS` cuenta solo días hábiles, salteando fines de semana y los feriados del país. Aparece por separado en cada configuración que cuenta días, así que una misma estrategia puede usar días hábiles para calcular la fecha de cobro y días corridos para espaciar los reintentos. - `retry_interval_days` integer, required - `retry_times` string[] - `schedule_date_type` 'CHARGE_DATE' | 'SUBMIT_DATE', required: Qué representa la fecha configurada: `CHARGE_DATE` es el día en que se cobra al pagador, y `SUBMIT_DATE` el día en que Toku envía la instrucción al banco. En los productos que cobran por archivo o mandato bancario ambas fechas difieren en los días hábiles de anticipación que exige la institución, así que con `CHARGE_DATE` el envío se adelanta para llegar a cobrar el día pedido. En los productos que cobran en línea, sin anticipación, las dos opciones son equivalentes. - `schedule_type` 'DATE' | 'OFFSET', required: Si una entrada del calendario de cobro es una fecha fija o una regla recurrente. Con `DATE` la entrada cobra una sola vez, en la fecha indicada. Con `OFFSET` la entrada define un desplazamiento que la periodicidad expande en varias fechas, y es la única forma que expande además los reintentos. - `default_charge_behaviour` 'FILL_UP_TO_BUSINESS_DAY' | 'FILL_UP_TO_CALENDAR_DAY' | 'SKIP_UNSCHEDULED_DAY': Si además de las fechas que la estrategia calendariza se cobra también en los días que no calendarizó. `SKIP_UNSCHEDULED_DAY` no agrega ninguno: se cobra solo en las fechas calendarizadas. `FILL_UP_TO_BUSINESS_DAY` completa todos los días hábiles del horizonte y `FILL_UP_TO_CALENDAR_DAY` todos los días corridos, descontando en este último caso los que el comportamiento de día no hábil descarte. - `default_charge_time` string - `id_charge_schedule_strategy` string - `id_charge_schedule_strategy_assignment` string - `product_type` 'CARDS' | 'RENDITION_FILES' | 'PIX' | 'BOLETO': Canal de recaudación de una asignación: la familia de rieles por la que sale el cobro. `CARDS` cobra a tarjetas inscritas, `RENDITION_FILES` cobra por archivo de rendición —descuento automático, PAC y los archivos batch de tarjetas—, y `PIX` y `BOLETO` cobran por esos medios brasileños. Es la llave con que se enruta cada cobro, y cada canal exige su propia configuración: qué datos hay que completar antes de poder activar una asignación depende de este valor. El `toku_product` elige después el flujo exacto dentro del canal. - `recurrence_rules` RecurrenceRules - `calendar_type` 'BUSINESS' | 'CALENDAR', required: Unidad en que se interpreta un conteo de días: `CALENDAR` cuenta todos los días y `BUSINESS` cuenta solo días hábiles, salteando fines de semana y los feriados del país. Aparece por separado en cada configuración que cuenta días, así que una misma estrategia puede usar días hábiles para calcular la fecha de cobro y días corridos para espaciar los reintentos. - `non_business_day_behaviour` 'CONTINUE' | 'NEXT_BUSINESS_DAY' | 'PREVIOUS_BUSINESS_DAY' | 'SKIP', required: Qué hacer cuando una fecha de cobro calculada cae en fin de semana o feriado. `NEXT_BUSINESS_DAY` la mueve al siguiente día hábil, `SKIP` descarta el cobro de ese período y `CONTINUE` deja la fecha tal cual, cobrando en día no hábil. - `periodicity` 'MONTH' | 'SEMI_MONTH' | 'WEEK' | 'EVENT_TRIGGERED', required: Patrón con que se repite un cobro y con el que se expande el offset configurado en fechas concretas. `MONTH` genera una fecha por mes, `WEEK` una por semana —donde el offset es el día de la semana, de `1` (lunes) a `7` (domingo)— y `SEMI_MONTH` dos por mes, una contada desde el inicio del mes y otra desde su mitad. `EVENT_TRIGGERED` no se calendariza: sus fechas de cobro no se generan por adelantado sino cuando ocurre el evento que las dispara, y por eso exige definir la ventana horaria en que el cobro puede ejecutarse y no admite configuración de reintentos. ## Response `200` Successful Response - object ## Other responses - `401`: Faltan las credenciales o son inválidas. - `403`: No tienes acceso a este recurso. - `404`: El recurso solicitado no existe. - `422`: El cuerpo de la petición no pasó la validación. - `429`: Se superó el límite de peticiones permitidas. ## Changes - **2026-11-03** `a6ef070075b1`: 1 info - endpoint added [Operation history](https://skmtc.dev/trytoku/apis/toku-api/changes/:country_code/public/charge-schedules/assignments/calendar-dates/post.md) --- [API](https://skmtc.dev/trytoku/apis/toku-api.md) - [All operations](https://skmtc.dev/trytoku/apis/toku-api/llms.txt) - [OpenAPI document](https://skmtc.dev/trytoku/apis/toku-api/revisions/a6ef070075b1?raw)