Skip to main content
POST
JavaScript

Scheduled Plan Changes

Use the effective_at parameter to control when the plan change takes effect:
Scheduled plan changes are ideal for downgrades — customers keep their current plan benefits until the end of the billing period, then automatically switch to the new plan.
To cancel a scheduled plan change before it takes effect, use the Cancel Scheduled Plan Change endpoint.

Payment Failure Handling

Use the on_payment_failure parameter to control what happens when the plan change payment fails:
If on_payment_failure is not specified, the behavior defaults to your business-level setting configured in the dashboard.
Set collect_via_payment_link to true to send the customer to a hosted checkout page instead of charging their saved payment method. The response then includes payment_id, payment_link, client_secret, and expires_on — redirect the customer to payment_link to complete the payment. This requires: A request that doesn’t meet these returns 422. While the link is unpaid, the subscription stays on its current plan and a further change-plan request returns 409, unless you set cancel_older_payment_link.

Redirecting After Payment

Set return_url to send the customer back to your site after they pay the link. The redirect adds subscription_id, payment_id, and status as query parameters.
  • status is the status of the plan-change payment, not the status of the subscription.
  • When the payment fails, the subscription stays active on its current plan. To try again, call change-plan again to get a new link.
  • The new plan can apply shortly after the redirect, when the payment webhook arrives.
return_url needs collect_via_payment_link: true. Without it, the request returns 422. If the customer leaves the checkout without paying, set cancel_older_payment_link to true on the next change-plan request. Dodo Payments cancels the unpaid link, and the new plan change replaces the pending one. The cancelled link no longer accepts a payment. The request is validated before the link is cancelled, so an invalid request keeps the customer’s link. The link is cancelled only if the customer has not started to pay: Each change-plan request issues its own invoice. The replaced plan change and its invoice are cancelled.
See the Subscription Upgrade & Downgrade Guide for the full flow, including declined payments, replacing a pending link, and what happens if the link expires.

Discount Codes

You can apply one or more stacked discount codes when changing plans by passing the discount_codes array (max 20 entries, applied in array order). The singular discount_code field is deprecated but still works for existing integrations; it cannot be combined with discount_codes in the same request.
Use discount codes during plan changes to offer promotional pricing on upgrades, or pass codes when migrating customers to a new plan tier.
Use prevent_change for critical upgrades where you want to ensure payment before granting access to premium features.

Authorizations

Authorization
string
header
required

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Path Parameters

subscription_id
string
required

Subscription Id

Body

application/json
product_id
string
required

Unique identifier of the product to subscribe to

proration_billing_mode
enum<string>
required

Proration Billing Mode

Available options:
prorated_immediately,
full_immediately,
difference_immediately,
do_not_bill
quantity
integer<int32>
required

Number of units to subscribe for. Must be at least 1.

Required range: x >= 0
adaptive_currency_fees_inclusive
boolean | null

Whether adaptive currency fees should be included in the price (true) or added on top (false). If not specified, uses the subscription's stored setting.

addons
Attach Addon Request · object[] | null

Addons for the new plan. Note : Leaving this empty would remove any existing addons

Cancel the payment link of a pending plan change, so that this change can replace it.

The link is cancelled only if the customer has not started to pay. A paid or in-progress payment gives a 409. A failed cancel gives a 503, and a retry is safe.

The request is validated before the cancel. A later failure, for example an amount below the minimum, leaves the subscription on its current plan with no open link. A retry is safe.

The preview route shares this request body and ignores this field.

cancel_scheduled_change_plan
boolean

Replace a scheduled plan change with this one.

The scheduled change is cancelled by the transaction that applies this change. A change that never applies leaves the schedule in place.

effective_at: next_billing_date is allowed. The new schedule then replaces the old one in the request transaction.

A pending plan change still gets a 409. This field does not affect it.

The preview route shares this request body, so a preview that sets this field also passes the scheduled-change 409.

Collect the plan-change amount with a payment link. The customer then pays on a checkout page.

The business needs the allow_plan_change_via_payment_link capability. The request needs effective_at: immediately. The request also needs on_payment_failure: prevent_change.

The preview route shares this request body and ignores this field.

discount_code
string | null
deprecated

DEPRECATED: Use discount_codes instead. Cannot be used together with discount_codes.

discount_codes
string[] | null

Stacked discount codes to apply to the new plan. Max 20. Cannot be used together with discount_code. If provided, replaces any existing discount codes. Empty array removes all discounts. If not provided (None), existing discounts with preserve_on_plan_change=true are preserved.

effective_at
enum<string>

When to apply the plan change.

  • immediately (default): Apply the plan change right away
  • next_billing_date: Schedule the change for the next billing date
Available options:
immediately,
next_billing_date
metadata
null | Metadata · object

Metadata for the payment. If not passed, the metadata of the subscription will be taken

on_payment_failure
null | enum<string>

Controls behavior when the plan change payment fails.

  • prevent_change: Keep subscription on current plan until payment succeeds
  • apply_change (default): Apply plan change immediately regardless of payment outcome

If not specified, uses the business-level default setting.

Available options:
prevent_change,
apply_change
return_url
string | null

The URL that receives the customer after they pay the payment link. Needs collect_via_payment_link: true. Without it, the request gets a 422. A change that collects no money issues no link and does not use the URL. The preview route validates this field but does not use it.

The redirect adds subscription_id, payment_id and status. The status value is the status of the plan-change payment. It is not the status of the subscription. When that payment fails, the subscription stays active on its current plan. To try again, call this endpoint again to get a new link. The new plan can apply after the redirect, when the payment webhook arrives.

Response

Subscription plan changed. A link request can return checkout details. A pending plan change applies after payment succeeds.

Handles for a hosted checkout page that settles a plan change.

The four fields repeat UpdatePaymentMethodResponse and a subset of CreateSubscriptionResponse. A shared type would rename the generated SDK types for all three routes, so each route keeps its own.

client_secret
string | null

Client secret for an embedded checkout.

expires_on
string<date-time> | null

When the link stops working.

payment_id
string | null

Id of the payment that settles the plan change.

Checkout page URL. Give this to the customer.

Last modified on September 30, 2026