---
title: "Create bulk single schedules"
method: POST
path: "/v1/schedules/bulk"
tags: ["Schedules"]
---

# Create bulk single schedules

`POST /v1/schedules/bulk`

Create multiple single schedules in a single request. This request triggers an asynchronous process to create the schedules. Once processing is complete, the [Bulk single schedules created](https://developers.pismo.io/events/docs/scheduler-payments-bulk-scheduled-payments-1) event is sent with the result of the operation.

This endpoint accepts a `defaults` object that can be used to set common values for all schedules in the request. Individual schedules can override any default value by specifying the field in their own definition.

In some cases, due to errors and retries, execution of the scheduled transaction might occur on the following day instead of the originally scheduled date. To address this, the `allow_execution_after_day_change` flag in `schedule_details` enables you to pre-authorize execution of the scheduled transaction on the next day. This flag must be set to `true` for schedules that are set to be executed at the end of the day (after 11:30pm UTC). If the schedule is not executed on the expected day for any reason, and this field isn't set to `true`, the schedule is not executed and is marked as `EXECUTED_WITH_ERROR_NEXT_DAY_NOT_ALLOWED`.

This endpoint generates the [Scheduled payment created or modified](https://developers.pismo.io/events/docs/scheduler-payments-scheduled-payments-1) event with the `status` field set to `CREATED`.

Each execution of the schedule also generates the [Scheduled payment executed](https://developers.pismo.io/events/docs/scheduler-payments-scheduled-payments-execution-1) event.

Refer to the [Payment scheduler](https://developers.pismo.io/pismo-docs/docs/payment-scheduler) guide for more information.

## Request body

- BulkSingleScheduleRequest — Request to create multiple single schedules in bulk
  - `defaults` BulkSingleScheduleDefaults — Default values applied to all schedules in the request. Individual schedules can override these values.
    - `account_id` integer — Account ID
    - `processing_code` string — Processing code for the debit transaction. If `split_transaction` is `false` (the default), each installment payment is recorded as one debit transaction equal to the installment amount minus the discount, and `processing_code` is the processing code for that transaction. If `split_transaction` is `true`, each installment payment is recorded as two transactions: a debit transaction for the installment amount and a credit transaction for the discount. In this case, `processing_code` is the processsing code for the debit transaction, and `second_processing_code` is the processing code for the credit transaction.
    - `currency_code` string — ISO 4217 3-letter currency code, For example, `986` = Brazilian real and `840` = US dollar.
    - `description` string — Challenge result
    - `amount` number, double — Fee amount.
    - `schedule_details` BulkSingleScheduleDetailsDefault — Default schedule details that can be applied to all schedules
      - `type` 'authentication' | 'challenge-request' — Evaluation intention
      - `interval` 'DAY' | 'WEEK' | 'MONTH' — Scheduler interval
      - `day_type` 'BUSINESS_DAY' | 'CALENDAR_DAY' — `BUSINESS_DAY` type ignores weekends and holidays, `CALENDAR_DAY` includes all calendar days.
      - `start_date` string, date-time — Start date of executions in the UTC-0 RFC3339 format. Format: YYYY-MM-DDTHH:mm:ss.sssZ.
      - `end_date` string, date-time — End date for link (GMT-3). When the final charge for a link is made, `end_date` gets populated.
      - `retries` Retries — Configuration to define retry policy for failed executions.
        - `interval_recurrence` integer — Interval for retries, in minutes
        - `number_of_attempts` integer — Maximum number of execution retries
      - `allow_execution_after_day_change` boolean — Can the schedule be executed after the day changes? For single and transfer schedules that are scheduled for after 11:30pm UTC, this field is required to be `true`.
    - `restrictions` Restrictions — Restrictions applied to the schedule
      - `minimum_daily_available` number, float — Establishes a minimum limit value to always be maintained in the customer's balance. If the value of the customer's balance is lower than the minimum limit value, the schedule is executed, otherwise its execution is stopped and saved as "Executed with restrictions".
      - `minimum_monthly_average_available` number, float — Follows the same logic as `minimum_daily_available`, except it considers an average limit value from the first day of the month until the day before the scheduled execution to compare with the customer’s balance value.
      - `minimum_days_account_inactivity` integer — If the days of account inactivity are greater than this field value, the schedule execution is stopped and saved as "Executed with restrictions".
    - `metadata` string — Any data object with key/value pairs. No limit on length. **Note**: This field must not be used to send Personally Identifiable Information (PII), Payment Card Industry (PCI) data, or any sensitive/regulated information. Metadata fields are intended for operational, non-sensitive data only. For sensitive data, use the specific parameters designed for that purpose. For more information, refer to [Get started with Pismo APIs](https://developers.pismo.io/pismo-docs/reference/get-started-with-pismo-apis#metadata).
  - `schedules` BulkSingleScheduleItem[], required — List of schedules to create. Each schedule can override any default value.
    - `schedule_id` string, required — Schedule ID (idempotency field for this operation)
    - `account_id` integer — Account ID
    - `processing_code` string — Processing code for the debit transaction. If `split_transaction` is `false` (the default), each installment payment is recorded as one debit transaction equal to the installment amount minus the discount, and `processing_code` is the processing code for that transaction. If `split_transaction` is `true`, each installment payment is recorded as two transactions: a debit transaction for the installment amount and a credit transaction for the discount. In this case, `processing_code` is the processsing code for the debit transaction, and `second_processing_code` is the processing code for the credit transaction.
    - `currency_code` string — ISO 4217 3-letter currency code, For example, `986` = Brazilian real and `840` = US dollar.
    - `description` string — Challenge result
    - `amount` number, double — Fee amount.
    - `schedule_details` BulkSingleScheduleDetailsOverride — Schedule details that override the defaults for this specific schedule
      - `type` 'authentication' | 'challenge-request' — Evaluation intention
      - `interval` 'DAY' | 'WEEK' | 'MONTH' — Scheduler interval
      - `day_type` 'BUSINESS_DAY' | 'CALENDAR_DAY' — `BUSINESS_DAY` type ignores weekends and holidays, `CALENDAR_DAY` includes all calendar days.
      - `start_date` string, date-time — Start date of executions in the UTC-0 RFC3339 format. Format: YYYY-MM-DDTHH:mm:ss.sssZ.
      - `end_date` string, date-time — End date for link (GMT-3). When the final charge for a link is made, `end_date` gets populated.
      - `retries` Retries — Configuration to define retry policy for failed executions.
        - `interval_recurrence` integer — Interval for retries, in minutes
        - `number_of_attempts` integer — Maximum number of execution retries
      - `allow_execution_after_day_change` boolean — Can the schedule be executed after the day changes? For single and transfer schedules that are scheduled for after 11:30pm UTC, this field is required to be `true`.
    - `restrictions` Restrictions — Restrictions applied to the schedule
      - `minimum_daily_available` number, float — Establishes a minimum limit value to always be maintained in the customer's balance. If the value of the customer's balance is lower than the minimum limit value, the schedule is executed, otherwise its execution is stopped and saved as "Executed with restrictions".
      - `minimum_monthly_average_available` number, float — Follows the same logic as `minimum_daily_available`, except it considers an average limit value from the first day of the month until the day before the scheduled execution to compare with the customer’s balance value.
      - `minimum_days_account_inactivity` integer — If the days of account inactivity are greater than this field value, the schedule execution is stopped and saved as "Executed with restrictions".
    - `metadata` string — Any data object with key/value pairs. No limit on length. **Note**: This field must not be used to send Personally Identifiable Information (PII), Payment Card Industry (PCI) data, or any sensitive/regulated information. Metadata fields are intended for operational, non-sensitive data only. For sensitive data, use the specific parameters designed for that purpose. For more information, refer to [Get started with Pismo APIs](https://developers.pismo.io/pismo-docs/reference/get-started-with-pismo-apis#metadata).

## Response `202`

Request was accepted and schedules will be processed asynchronously.

## Other responses

- `400` — Bad request
- `403` — The request has been lost
- `500` — Internal server error

---

[API](https://skmtc.net/pismo/apis/platform-authentication.md) · [All operations](https://skmtc.net/pismo/apis/platform-authentication/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/pismo/platform-authentication/versions/935b62e16de4/schema)