Summary
This release makes group contracts and self-service plan changes first class. A parent can sign one quote that covers several forward-billed subsidiaries. A customer can move between the plans of a pricing plan group without a support ticket, from your integration or from the customer portal. A checkout for physical goods collects the delivery address in the same flow and attaches it to the subscription. Desk gains a ⌘K search over every page, record and action.
Quotes
A quote version can hold several subscriptions
A quote version is no longer limited to one subscription. POST /v1/quotes/init takes a pricing_plan_subscriptions list. Each entry has its own pricing plan schedule. The quote version reports all of them in pricing_plan_subscription_ids and pricing_plan_subscription_infos. One customer signs, and the others are forward billed against it. This is how a group contract is usually sold: the parent signs for the subsidiaries, and each subsidiary is invoiced separately. The deal metrics already report per subscription, so the totals on a multi-subscription quote need no extra call. The single-valued pricing_plan_subscription_id and pricing_plan_subscription_info still work and are deprecated. See Quotes.
Subscriptions
Move a subscription to another plan in its group
POST /v1/pricing-plan-subscriptions/{id}/change-plan moves a running subscription to a sibling plan in the same pricing plan group and returns the schedule it created. The body takes the target pricing_plan_id and an optional start_at. Add billing_period when the new plan is billed on a different cycle. If you leave billing_period out, the current period is kept.
The group decides when the change takes effect, so the same call is correct for an upgrade and for a downgrade. upgrade_type, downgrade_type and cancellation_type each take IMMEDIATE, IMMEDIATE_PRO_RATA, NEXT_BILLING_PERIOD or NOT_ALLOWED. start_at is accepted only for the two immediate policies. The change needs PRICING_PLAN_SUBSCRIPTION.UPDATE and PRICING_PLAN_SCHEDULE.CREATE. See Plan changes.
A subscription carries the address its goods go to
default_shipping_address_id on a subscription names an ACTIVE shipping address of the same customer. Set it to null to clear it. A customer that takes the same product at more than one location can keep a subscription per address, and each renewal ships to the right place. You cannot delete an address while a subscription points at it.
Customers
A shipping address can be created ready to use
POST /v1/shipping-addresses now takes status: DRAFT, as before, or ACTIVE to skip the activate call. A system that already knows its addresses are good no longer makes two calls per address. DEPRECATED is refused on creation. status stays read-only on PATCH: use activate and deprecate. See Shipping addresses.
Collect a shipping address during checkout
A hosted checkout page can ask the buyer for a delivery address. Turn it on per checkout page in Desk, next to the success URL and the terms. The portal’s authorize call then accepts shipping_address_details in the init_pricing_plan_subscription context: a reference, a recipient and an address. Solvimon upserts the address on the customer the checkout resolves to and attaches it to the subscription it creates. A merchant selling physical goods gets the address and the subscription in one flow. A checkout that sells software is unaffected. The portal also has its own read and deprecate endpoints for the addresses of the customer the link belongs to.
Customer portal
A customer can change their own plan
The portal exposes the same plan change as the API, limited to the subscription the link belongs to. A buyer can move between the plans of a pricing plan group under the group’s own timing policy. A transition the group marks NOT_ALLOWED is refused, not hidden. See Self-serve plan changes.
Invoices
Fixes
- Adding a one-off line without a
pricing_bandanswers400and names the field. AFIXEDorFLATline without one returned500. - “Request usage report” is hidden on
VOIDandARCHIVEDinvoices. No usage is billed on a voided invoice, so the report held only its header row.
Payments
Your own text on the customer’s bank statement
A payment acceptor configured for Adyen takes two optional settings. shopper_statement is the text the customer sees on their bank statement. metadata is a list of key and value pairs sent with the payment. Both are templates, so {{invoice.invoice_number}} puts the invoice number on the statement and into the Adyen settlement report, which carries no merchant reference of its own. Reconciling a settlement file against invoices no longer needs a separate lookup. Neither setting has a default, so platforms that do not configure them are unaffected. Both are editable in Desk on the payment acceptor.
An abandoned payment closes itself
Solvimon now acts on Adyen’s offer-closed notification. When a buyer leaves an iDEAL or other redirect payment and Adyen reports the offer expired, the payment moves from PENDING to CANCELLED and keeps the gateway’s reference. Only a PENDING payment whose reference matches is touched, so a late authorization is left alone. The payment list settles on its own, and a retry starts from a clean state.
Fixes
- An Adyen request that is rejected for a validation error now records which fields were rejected. A failed integration or payout setup says what to correct instead of only “invalid information provided”.
Event ingestion
Fixes
- GET /v1/events answers
400and names the parameter whenprocessed_details_typeis a value the platform does not know, or when the customer id is not a valid resource id. Both returned500.
Roles and permissions
Fixes
- A user whose only customer role is Customer Draft Contributor can no longer activate a customer. The role covers customers in
DRAFT. Activating one is an administrator’s action.
Workflows
Send an email later
The “send email to customer” workflow action takes a delivery delay. Set it in minutes on the action in Desk, up to three days. The API carries it as delivery_delay_seconds on the action. A dunning reminder can be scheduled for the next working morning instead of going out the moment the invoice falls due. See Workflow actions.
ERP actions show which integration they run against A workflow action that posts to an ERP now shows that system’s name and logo in the action list. A workflow with several integrations is readable at a glance.
AI and MCP
The cards link to each other The customer, quote, subscription and invoice cards an AI client renders are now linked. A breadcrumb moves between them, a customer card has tabs, and a card opens full screen. A quote’s first invoice preview has a card of its own, so building a quote in chat no longer falls back to a markdown table. The cards are built from Solvimon’s own component library, so they look like Desk.
Cards keep rendering in a long conversation A card no longer stops appearing after several turns in the same chat. A list card is built from the list it was given instead of re-fetching each item. A card that cannot render is logged, not silently replaced with text. A read-only card no longer carries contact details or payment methods.
Desk
Find any page, record or action with ⌘K ⌘K, or Ctrl+K, opens a search over the whole of Desk from anywhere. It finds pages by title, path or synonym, so “discounts” reaches Coupons and “group” reaches Plan groups. It opens a record from a pasted id. Before you type, it offers the common actions: create a customer, a one-off invoice, a subscription or a quote, and ingest an event. The sidebar’s search field opens the same panel.
Meter property variables have a screen
The meter property variable API gained a Variables section in the sidebar. Create a variable, give an ENUM, NUMBER or STRING meter property its list of values, import the values from a CSV, and reprocess the events the change affects. Pricing conditions that refer to a variable can now be maintained without calling the API. See Meter property variables.
Filter invoices on amount The invoice list filters on the invoice amount, using the amount search the API gained last release. A platform that bills usage produces final invoices worth nothing at all. This filter separates them from the invoices worth collecting.
Fixes
- Rows on the subscription and invoice lists open in a new tab with a right click anywhere in the row, not only on the first column.
- Creating a rate card works after opening and closing the customer picker without choosing anyone. The empty picker sent an invalid id, and the error named nothing.
- Editing a pricing from flat to tiered sends the type you chose. On a plan with several currencies or periods the
PATCHstill saidFLAT. - Saving a usage-based pricing with nested conditions no longer fails on an unknown
use_billing_cyclesfield.
For developers
Realistic examples in the API reference Solvimon rewrote every example in the API reference with values from a plausible billing setup instead of placeholders. This covers request bodies, responses, error responses, parameters and headers, for example on POST /v1/customers. Copying an example and changing the ids now gives a request that makes sense. This matters most to an AI agent that reads the specification as its only documentation.
SDK elements render before the translations arrive
An SDK element in en-US renders immediately instead of waiting for two translation catalogs the bundle already contains. The element paints and starts its requests one network round trip sooner.
Deprecated API fields
The following fields are now deprecated. They continue to work for backwards compatibility. Migrate to the replacements.
pricing_plan_subscription_id(quote version info): usepricing_plan_subscription_ids. The single-valued field is only set when the quote version has exactly one subscription.pricing_plan_subscription_info(quote version): usepricing_plan_subscription_infos, which carries one entry per subscription on the quote version.pricing_plan_subscription_id(quote version create-subscription action): usepricing_plan_subscription_ids, which lists every subscription the action created.