Skip to main content
These functions let you query and manage recurring subscriptions from backend templates and backend scripts. All operations are scoped to the current customer’s email — a customer can only access their own subscriptions.
The internal /api/subscription-* routes are used by the call center and subscription portal. You do not call those routes directly from your pages. Instead, use the functions below in backend scripts to build your own subscription management pages.

Functions reference

Built-in validation

Write functions enforce these rules automatically — even if your script does not check:
  • Customer session must have an email
  • Subscription must exist and belong to the session customer (email match)
  • Status must be valid for the action (e.g. only active subscriptions can be paused or skipped, only paused can be resumed, already-canceled cannot be canceled again)
  • changeSubscriptionFrequency requires a valid interval unit and a positive integer count
Invalid operations return { ok: false, error: '...' } without modifying the subscription.

Subscription object shape

Sensitive fields (vault_id, billing_id, merchant_id, customer_address, tax_report, metadata) are never exposed.

Gating content

Use hasSubscription to show or hide content based on subscription state. All read helpers share a per-request cache — the database is only queried once no matter how many times you call them.

Active subscription gate

Gate by product code

Point-in-time gate (date-based)

Check whether the customer was subscribed on a specific date — useful for gating content that was published while a subscription was active, even if the subscription has since been canceled.
Date logic: a subscription is considered active on the given date if started_at ≤ date and canceled_at is either null or after the date. The current status field is not used — only the raw timestamps.

Status-specific checks

Subscription count

Win-back flow (recently canceled)


Displaying subscriptions in templates

Use getSubscriptions() in a backend script and render with @foreach:

Building page-based APIs

The recommended pattern for subscription management: create EF pages with slugs like api/subscription-list, api/subscription-cancel, etc. Each page uses a backend script to validate, call the adapter, and return JSON.
These pages accept POST requests with JSON bodies (via request.body) and return JSON via response.json(). No HTML is rendered — the backend script handles the entire response.

List subscriptions

Create a page with slug api/subscription-list:

Cancel subscription

Create a page with slug api/subscription-cancel:

Pause subscription

Create a page with slug api/subscription-pause:

Resume subscription

Create a page with slug api/subscription-resume:

Skip next charge

Create a page with slug api/subscription-skip:

Change frequency

Create a page with slug api/subscription-change-frequency:

Calling from frontend JavaScript

Once you have the page-based APIs set up, call them from your frontend code:

See also