# Create a one-off cycle on a subscription

Triggers an extra capture against an active subscription's saved payment method — useful for billing ad-hoc items like setup fees, add-ons, or upgrades without touching the recurring schedule. The regular cycles keep running unchanged.
Send `capture_at` to schedule the capture for later, or omit it to capture right away. The subscription must be active; a one-off cycle on an inactive subscription is rejected with a `409 Conflict`.
**Required scope:** <code style="background:#e8f0fe;color:#1a73e8;padding:2px 8px;border-radius:12px;font-size:0.85em">subscription:create</code>

Endpoint: POST /subscription/{id}/cycle
Version: 2.0
Security: accountId, apiKey

## Path parameters:

  - `id` (string, required)
    UUID of the subscription to add the cycle to.

## Request fields (application/json):

  - `value` (number, required)
    Must have at most two decimal places.
    Example: 10.5

  - `capture_at` (string)
    When to schedule the charge, in UTC. Must not be in the past. Omit to capture immediately.
    Example: 2037-12-12 09:00

  - `description` (string)
    Free-form text shown on the bank statement or in the MB WAY app.
    Example: extra subscription charge

  - `key` (string)
    Your internal identifier for this charge. Useful for reconciliation on your side.
    Example: one-time-charge-key

## Response 201 fields (application/json):

  - `status` (string, required)
    Example: ok

  - `message` (array, required)
    Example: ["Your request was successfully created"]

  - `id` (string, required)
    The UUID of the newly created cycle.
    Example: 550e8400-e29b-41d4-a716-446655440000

## Response 400 fields (application/json):

  - `status` (string, required)

  - `message` (array, required)
    An array of human-readable messages included in the response. These messages provide detailed information about the success of the operation or explain the reasons for any failure. This field is always present in the response to ensure clarity and transparency regarding the outcome of the API request.

## Response 401 fields (application/json):

  - `status` (string, required)

  - `message` (array, required)
    An array of human-readable messages included in the response. These messages provide detailed information about the success of the operation or explain the reasons for any failure. This field is always present in the response to ensure clarity and transparency regarding the outcome of the API request.

## Response 403 fields (application/json):

  - `status` (string, required)

  - `message` (array, required)
    An array of human-readable messages included in the response. These messages provide detailed information about the success of the operation or explain the reasons for any failure. This field is always present in the response to ensure clarity and transparency regarding the outcome of the API request.

## Response 404 fields (application/json):

  - `status` (string, required)

  - `message` (array, required)
    An array of human-readable messages included in the response. These messages provide detailed information about the success of the operation or explain the reasons for any failure. This field is always present in the response to ensure clarity and transparency regarding the outcome of the API request.

## Response 409 fields (application/json):

  - `status` (string, required)

  - `message` (array, required)
    An array of human-readable messages included in the response. These messages provide detailed information about the success of the operation or explain the reasons for any failure. This field is always present in the response to ensure clarity and transparency regarding the outcome of the API request.

## Response 412 fields (application/json):

  - `status` (string, required)

  - `message` (array, required)
    An array of human-readable messages included in the response. These messages provide detailed information about the success of the operation or explain the reasons for any failure. This field is always present in the response to ensure clarity and transparency regarding the outcome of the API request.

## Response 429 fields (application/json):

  - `status` (string, required)

  - `message` (array, required)
    An array of human-readable messages included in the response. These messages provide detailed information about the success of the operation or explain the reasons for any failure. This field is always present in the response to ensure clarity and transparency regarding the outcome of the API request.

## Response 500 fields (application/json):

  - `status` (string, required)

  - `message` (array, required)
    An array of human-readable messages included in the response. These messages provide detailed information about the success of the operation or explain the reasons for any failure. This field is always present in the response to ensure clarity and transparency regarding the outcome of the API request.