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

# Create single schedule

`POST /v1/schedules`

Create a single schedule, which executes a simple payment operation on a single account. Configure the schedule's execution frequency and other details in the `schedule_details` field.

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

- SingleScheduleRequest — Request to create a new single schedule
  - `schedule_id` string, required — Schedule ID (idempotency field for this operation)
  - `schedule_details` SingleScheduleDetails, required — Single schedule details
    - `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`.
  - `account_id` integer, required — Account ID
  - `amount` number, double, required — Fee amount.
  - `currency_code` string, required — ISO 4217 3-letter currency code, For example, `986` = Brazilian real and `840` = US dollar.
  - `processing_code` string, required — 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.
  - `description` string — Challenge result
  - `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 `200`

Request was processed successfully, existing schedule with the corresponding `schedule_id` returned.

- SingleScheduleResponse — Response from the creation of a new single schedule
  - `schedule_id` string — Schedule ID (idempotency field for this operation)

## Other responses

- `201` — Request was processed successfully, new schedule created.
- `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)