We are excited to announce a significant update to how subscription addresses are handled within our platform. These changes are designed to provide a cleaner, faster user interface and ensure more reliable address changes for your subscribers.

Currently, syncing addresses directly with Shopify can occasionally lead to unintended behavior — such as an update to a default address accidentally impacting unrelated subscriptions. To solve this, we are moving to a model where each subscription maintains its own independent shipping and billing address.

Key Benefits​

• More Reliable Address Updates: By decoupling subscription addresses from the general Shopify customer address book, updates are now isolated. Changing an address for one subscription will no longer unintentionally affect others.
• A Better Interface: We are streamlining the Customer Portal and App Admin by removing the legacy Address dropdown menu. This results in a simplified, less cluttered experience for both merchants and customers.
• Data Integrity: Moving forward, all addresses stored in our database will be native to our platform (Source: bold), eliminating synchronization conflicts with Shopify platform data (Source: platform).

Technical Implementation Guide​

For developers integrating with our API, this change involves a shift in how you retrieve and update addresses.

How to Retrieve a Shipping Address​

You should no longer rely on the Customers endpoints for address data. Instead, access the address directly through the Subscription object. Use the GET Subscription endpoint to retrieve the shipping_address object directly.

How to Update a Shipping Address​

To update an address, you must identify the specific address attached to the subscription.

1. Call the GET Subscription endpoint.
2. Extract the shipping_address_id.
3. Use that ID as the address_id in a PUT Update Customer Address request.
4. Update the Subscription so the address change is updated on the Shopify contract with PATCH Partial Update Subscription updating the shipping_address_id to the address_id that was just updated.

Retrieving a List of Customer Addresses​

As we are disabling the sync of generic Shopify platform addresses, our API will no longer return the full list of a customer’s Shopify addresses.

Action Required: If your application requires a full list of a customer’s saved addresses from Shopify, please query the Shopify API directly.

API Deprecations and Breaking Changes​

To support this architecture, specific fields in the Customer APIs will be deprecated. The following endpoints will now return empty arrays for address-related fields. Please ensure your applications handle these responses correctly.

• Subscriptions API:
  • GET Customer:
    • addresses will return []
    • default_address will return null
  • GET List Customers:
    • addresses will return []
    • default_address will return null
  • GET List Customer Addresses:
    • customer_addresses will return []
• Customers API:
  • GET List Customers:
    • addresses will return []
    • default_address will return null
  • GET Customer by ID:
    • addresses will return []
    • default_address will return null
  • GET Customer by Platform ID:
    • addresses will return []
    • default_address will return null
  • GET List Customer Addresses:
    • This endpoint is deprecated
    • It will return {"addresses": []}

Note on Default Addresses​

Default address attributes will remain on endpoints that currently support them. However, the value will always be returned as null.

The List Customers endpoint of the Subscriptions API will update four fields in the addresses and default_address objects.

Currently, these fields are returned as a number, but according to the API specification, they should be string. Starting December 3, 2025, these fields will always be returned as string values.

Fields Affected​

Why is this changing?​

• This update makes the returned data consistent with the public API docs.
• Corrects a data type discrepancy that may cause type errors in strict-typed languages or API clients.

Action Required​

Review your integration: If your code expects these fields to be a number, update it to accept a string value.

New endpoints for modifying discount codes on subscriptions:

• Update Discount Code
• Remove Discount Code

Upcoming deprecation:

Using the PUT and DELETE /subscriptions/[subscription_id]/discount_code endpoints is now the recommended approach to modify subscription discount codes. Further annoucements are coming soon regarding the deprecation of using PUT AND PATCH /subscriptions/[subscription_id] endpoints to modify discount codes.

A new optional field dynamic_discounts was added to Subscription Groups payloads.

New endpoints for creating, updating, and deleting Convertible Adjustments:

• Create Convertible Adjustment Group
• Create Convertible Adjustment Group Items
• Delete Convertible Adjustment Group
• Delete Convertible Adjustment Group Item
• Delete Convertible Adjustment Group Items
• Update Convertible Adjustment Group
• Update Convertible Adjustment Group Item

This change impacts the following endpoints:

• Create Subscription Adjustments
• Get Subscription Adjustments
• Get Subscription Adjustment by ID

No action is necessary. This is a non-breaking change, and this entry is intended for informational purposes only.

This endpoint is useful for offline or off-session order processing, when you don't want to call the Process Order endpoint from the frontend.

This endpoint enables you to control whether Bold triggers customer creation on the platform during the order creation process. This setting defaults to true.

This endpoint enables you to control whether the Process Order endpoint performs an inventory check. If the inventory check is required, the Process Order endpoint returns a 422 error if there is not enough inventory to complete the order.

The inventory check is required by default.

This update includes the following new endpoints:

• Get Shop Payment Styling
• Create Shop Payment Styling
• Delete Shop Payment Styling

These endpoints enable you to style Payment Booster. For most other types of checkout, Bold recommends styling the checkout using the Bold Checkout admin. Refer to Style the Checkout with CSS for more information.

This change impacts the following endpoints:

• Get Customer by ID
• Get Customer by Platform ID
• List Customers
• List Customer Addresses

Additional Documentation​

Refer to Add Customized Elements to Checkout for more information about this anchor location.

Bold previously sent only the order_id, or the public order identifier for the platform, in Auth requests. The bold_order_id represents the order identifier internal to Bold.

Refer to the External Payment Gateway Connector API specification for more information: Implement an External Payment Gateway.

This setting is also available in the General Settings section of the Bold Checkout Admin.

When ?include_all_apps=true is present, the response includes rulesets created by other apps. When ?include_all_apps=false is present or the flag is omitted, the response includes only rulesets created using the Price Rules API.

Handling the customer_data object in the Auth endpoint is not required.

Refer to the External Payment Gateway Connector API page for more information: External Payment Gateway Connector API: Auth

This change also adds support for the estimate_shipping and estimate_tax RSA events.

These endpoints include:

• Create Wallet Pay Order
• Update Shipping Address for Wallet Pay
• Capture Payment for Wallet Pay

These endpoints currently support PayPal only.

Add the discounts field to the following endpoints:

Platform Connector​

• Response body of the List Orders endpoint.
• Response body of the Get Order endpoint.
• Request body of the Create Orders endpoint.

Platform Event Notifications​

• Request body of the Order Saved endpoint.