Changelog

October at a glance

October was about the everyday: getting around the app, reading what Paid sends your customers, and setting things up without help. The navigation was rebuilt, the whole app grew a dark theme, invoices and the emails that carry them were redesigned, and creating a product or an order is now a guided, step-by-step job. Underneath, customer teams and metering moved forward with selected organizations.

Items marked Early access are switched on for selected organizations rather than everyone. If you want one of them enabled, ask your Paid contact.

Get around the app in fewer clicks

The sidebar has been rebuilt around what you actually do: clear groups, your account and current organization pinned at the bottom with a switcher, and sub-items that appear in a hover flyout when the sidebar is collapsed, so everything stays one click away. Analytics lives on one tabbed page, with each dashboard as a tab, record pages share one header, and a keyboard-shortcuts dialog lists every shortcut in the app.

Built by: Camille, Georgi, Ivan, Léo, Lewis, Marta, Raj, Will

Dark mode, across the whole app

The whole app now has a proper dark theme. Pick light, dark or follow-your-system under Settings → Appearance, or from the menu behind your organization. Every surface moved with it: tables, charts, dialogs, detail pages, the data grid, logos and status colours. Charts share one palette in either theme, and every icon in the app is now drawn from one set.

Built by: Léo, Marta, Ulysse, Will

Invoices, redesigned

Invoices have a new document design and a new renderer behind it: cleaner layout and better multi-page handling. Every invoice issued from 2 October uses the new layout; invoices issued earlier keep the old one, so nothing you have already sent changes shape. Credit notes print from the same template, and the seller’s support URL appears under Bill from.

Built by: Georgi, Léo, Ulysse

Products and orders are now built in steps

Creating a product or an order is now a guided sequence of steps rather than a single form. Each step states what it needs, blockers are flagged where they happen with guidance on fixing them, every field explains itself and says whether a customer will see it, and drafts can be saved and reopened. The order wizard previews the first invoice — its lines and its PDF — before anything is activated, and an existing product can be edited through the same steps.

Built by: Léo, Marta, Nabil, Sam

Set up customer teams in the app

Early access. The Team tab on a customer shows the structure you set up through the API: every unit, the spend rolling up the tree, and how much of a cap has been used.

Units now accept aliases, so a key from your own system, a tenant id and a team name can all land on the same unit, and a unit’s spend can be read on its own endpoint.

Customer units and credit caps

Built by: Alessandro, Marta, Min, Nabil, Nassim

App experience: improvements and fixes

• The app was rebuilt on one design system: the same name for an action from menu to button, one way of writing dates and money, one toolbar across list views with status chips, filters and a compact footer, and consistent toasts, modals, badges, chips, buttons and avatars. Invoices are finalized rather than posted, payments are recorded, and bank details are payment instructions.
• The hosted sign-in and sign-up pages were redesigned.

Built by: Camille, Dan, Georgi, Ivan, Léo, Lewis, Marta, Nabil, Sam, Ulysse, Will

Billing: improvements and fixes

• Every email your customers receive — invitation, invoice, payment confirmation and payment failed — was redesigned and now shares one design.
• Usage billed in advance is refused for every usage pricing model, prepaid credits included. To sell credits up front, add a credit benefit to a recurring, seat or one-time charge.

Built by: Gareth, Léo, Nabil

More control over what a meter counts

• Early access. A metering rule can match or exclude specific values, so one meter can cover exactly the slice of usage you mean, and a window’s details sit beside the rule that produced it. Meters

Built by: Lewis

For developers: unit aliases and signal lookups

What changes.

• Customer unit aliases: GET/POST on /api/v2/customers/{id}/customer-units/{externalCustomerUnitId}/aliases and DELETE on /api/v2/customers/{id}/customer-units/{externalCustomerUnitId}/aliases/{alias}, so one unit can be addressed by several identifiers, plus GET /api/v2/customers/{id}/customer-units/{externalCustomerUnitId}/spend and a direct GET /api/v2/customer-units/external/{externalCustomerUnitId}. Customer units and credit caps
• Signals: POST /api/v2/signals/lookup, GET /api/v2/signals/summary/ and a batched POST /api/v2/signals/summary/batch/ with GET /api/v2/signals/summary/batch/{id}. Chart signal volume
• Credit grants take an optional idempotency key, so a call you retry after a timeout grants once rather than twice. Without a key, nothing changes.
• v2 order creation is validated before anything is written, so a bad order fails with a message instead of a half-written record.

Who is affected. Anyone building on the v2 API, the SDKs, the CLI or MCP. Everything in this section is additive; the changes under Breaking changes below are not.

What to do, and by when. Nothing is required. Regenerate or upgrade your SDK when you want the new methods.

Built by: Alessandro, Dan, Gareth, Lewis, Min, Nabil, Nassim, Sam, Ulysse, Xifong

Breaking changes

Six writes that Paid used to accept are now refused, each with a message naming the reason. Records already saved are untouched; what changes is what Paid accepts from here.

• A webhook receiver URL must use HTTPS and a public host. An endpoint you have already registered keeps receiving, and the webhook can still be switched off, but the URL has to move to HTTPS before that webhook can be saved or switched back on. Webhooks
• An order may only use a currency the product or plan on each line is priced in.
• A customer identifier or alias that another customer already holds is refused, ignoring case, so one identifier names one customer.
• A customer with billing history is kept rather than deleted, and the refusal names what is holding it — orders, invoices, credit notes, payments, contacts, entitlements, credit transactions and more.
• A contact is kept rather than deleted while an order or an unsettled invoice still bills to it. Once an invoice is paid, voided or canceled it no longer holds the contact.
• A credit grant to a unit balance needs a fee charged per unit.

Who is affected. Anyone whose integration writes one of those six shapes. Everyone else is unaffected, and nothing you have already saved changes.

What to do, and by when. Move webhook endpoints to HTTPS on a publicly resolvable host; price the product or plan on each line in every currency you order it in; keep each identifier and alias to one customer, ignoring case; reassign a contact’s live orders and unsettled invoices before deleting it, and keep customers that have been billed rather than planning to delete them; and put unit-balance credit grants on per-unit fees.

Built by: Alessandro, Nassim, Sam, Ulysse