For the complete documentation index, see llms.txt. This page is also available as Markdown.

Update Subscription

SDK methods for subscription update (change plan) checkouts in the Limio SDK.

Subscription update checkouts let existing subscribers change their plan — upgrade, downgrade, or modify add-ons ( https://docs.limio.com/product/self-service/what-are-the-standard-functionality-of-limio-self-service-manage-my-account/how-to-configure-an-update-subscription-flow ) . They use a different flow from standard acquisition checkouts because the server drives the available next actions (effective dates, proration, removal side-effects).

Subscription update checkouts use order_type: "update_subscription". The SDK detects this automatically and routes mutations through the subscription update API.

How it works

  1. From a subscription management page, call initiateCheckout with order_type: "update_subscription" and a forSubscription reference.

  2. The server creates an update checkout session and returns a checkoutId.

  3. Redirect the subscriber to the update checkout page with the checkoutId.

  4. On the offer selection page, use selectOfferForSubscriptionUpdate to let the subscriber pick a new plan.

  5. The server resolves effective dates, proration, and next actions, then returns the updated basket.

Starting an update checkout

Use initiateCheckout with order_type: "update_subscription" and the subscription ID. This creates the server-side update session.

import React from "react"
import { useBasket } from "@limio/sdk"

const SubscriptionUpdateButton = ({ subscription, updatePageUrl = "/update" }) => {
  const { initiateCheckout, basketLoading } = useBasket()

  const handleUpdate = async () => {
    const basket = await initiateCheckout({
      order: {
        order_type: "update_subscription",
        forSubscription: {
          id: subscription.id
        }
      }
    })

    const checkoutId = basket.order.checkoutId
    window.location.href = `${updatePageUrl}?basket=${checkoutId}`
  }

  return (
    <button onClick={handleUpdate} disabled={basketLoading}>
      Change plan
    </button>
  )
}

The forSubscription.id tells the server which subscription is being modified. The response includes the checkoutId used to track this update session.


Selecting a new offer

Once the update checkout session exists, use selectOfferForSubscriptionUpdate on the offer selection page. Only one offer can be active at a time — selecting a new offer resets the checkout and re-resolves server-side state.

Parameters:

Field
Type
Description

offer

ElasticOffer

The offer the subscriber is switching to

quantity

number

Quantity (typically 1 for plan changes)


Clearing items before re-selection

When the subscriber changes their mind and picks a different offer, await clearOrderItems() before selectOfferForSubscriptionUpdate. This ensures the server re-resolves everything cleanly for the new selection.

clearOrderItems is asynchronous. It sends a remove action for every item in the basket to the server and updates the basket state with the response, so it must be awaited before you select the new offer.


Adding items to a subscription update checkout

Use addSubscriptionOrderItem to append an order item to the subscription update basket. Unlike selectOfferForSubscriptionUpdate (which replaces all items), this method is additive — it keeps existing items and appends the new one.

The caller constructs the full order item shape, giving visibility and control over what's being added.

Parameters:

Field
Type
Description

orderItemActionType

string

The action type (e.g. "update" for quantity changes)

offer

Offer

The offer being modified

quantity

number

The target quantity

The server resolves the effective date based on the direction of the quantity change. Increases take effect immediately; decreases take effect at end-of-term.

Example — seat quantity update flow:

A common pattern is to use addSubscriptionOrderItem when initially adding a quantity change to the basket, then updateItemQuantity for subsequent adjustments to items already in the basket.

When to use which method:

Scenario
Method

Item is not yet in the basket

addSubscriptionOrderItem

Item is already in the basket

updateItemQuantity

Selecting a completely new plan (replaces all)

selectOfferForSubscriptionUpdate

Removing an offer from the subscription

addSubscriptionOrderItem with orderItemActionType: "remove"

Your component has access to orderItems and nextActions.quantityUpdates to determine which method to use.


Quantity updates in subscription update checkouts

updateItemQuantity behaves differently in subscription update checkouts. Instead of calling the standard basket API, it routes through the subscription update API so the server can recalculate proration and effective dates.

You don't need to handle this routing yourself — the SDK detects order_type: "update_subscription" and uses the correct endpoint.


Removing an offer from a subscription

Use addSubscriptionOrderItem with orderItemActionType: "remove" to remove an offer from a multi-offer subscription without cancelling the subscription. The removed offer stays active and billed until the end of the current term — the same effective-date semantics as a downgrade.

Offer removal is available from Release 116.

Parameters:

Field
Type
Description

orderItemActionType

"remove"

Marks this item as an offer removal

type

"subscription_offer"

Identifies the item as an existing offer on the subscription

offer

Offer

The subscription offer being removed

Example — removal flow:

Rules the server enforces:

  • A subscription always keeps at least one active offer. An order that would remove every offer is rejected. An offer added in the same order offsets a removal, so swapping (remove one offer, add another) passes.

  • Removals take effect at the end of the current term. In a mixed order (for example a removal plus a quantity change), the removal drives the whole order's effective date to term-end, so the offer is never stripped immediately. The exception is a swap: when an offer is added in the same order, the effective date follows the added offer's upgrade or downgrade classification instead.

  • Batch all removals into a single order. Submitting an update order sets a pending change on the subscription that blocks further update checkouts until the effective date passes, so sequential removal orders are not possible.


Notes

  • Start every update flow with initiateCheckout using order_type: "update_subscription" and forSubscription: { id }.

  • Always await clearOrderItems() before selecting a different offer to avoid stale server state.

  • The ownerId query parameter identifies which subscription is being updated — pass it through when redirecting.

  • Server-driven state means the basket response may include fields not present in standard checkouts (effective dates, next actions, proration details).

  • See Basket (Cart) for all other basket methods (adding items, promo codes, checkout navigation, etc.).

Last updated

Was this helpful?