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

# Create single schedule

`POST /v1/schedules`

## Request

- Base URL: `https://sandbox.pismolabs.io/scheduler-payments`
- URL: `https://sandbox.pismolabs.io/scheduler-payments/v1/schedules`
- Auth: HTTP bearer

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](doc: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` 'ONCE' | 'RECURRING': Should a schedule be executed once or in a recurring fashion? - `ONCE`: Executed only once on the date specified in `start_date`. - `RECURRING`: Executed repeatedly according to the interval defined in `interval`, within the period between `start_date` and `end_date`. A recurring schedule can run daily, weekly, monthly, or yearly, which is set in the `interval` field.
    - `interval` 'DAILY' | 'WEEKLY' | 'MONTHLY' | 'YEARLY': Schedule execution frequency
    - `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 of schedule executions in the UTC-0 RFC3339 format. Format: YYYY-MM-DDTHH:mm:ss.sssZ.
    - `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, float, required: Credit or debit amount
  - `currency_code` string, required: Three-letter currency code of the operation in ISO 4217.
  - `processing_code` string, required: Processing code that identifies the credit or debit operation
  - `description` string: Optional text that describes the operation
  - `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` Metadata: This optional user-defined key-value object field can be used with external operations to provide additional context or supplementary custom information for the operation. The Pismo platform does not perform any validation or processing on this field. **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](ref: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`: Operation forbidden
- `500`: Internal server error

---

[API](https://skmtc.dev/pismo/apis/core-platform-payment-scheduler.md) - [All operations](https://skmtc.dev/pismo/apis/core-platform-payment-scheduler/llms.txt) - [OpenAPI document](https://skmtc.dev/pismo/apis/core-platform-payment-scheduler/revisions/85d7c15a4b75?raw)