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

September at a glance

September was about giving your customers a seat at the table. You can now divide a customer into teams and hold each one to its own credit limit, and anyone can build a dashboard on their Paid data by describing it, then embed it for a customer to watch live. The app had a visual refresh, search is a keystroke away from anywhere, and the API gained read endpoints for credit movements and bank transfer details.

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

Split a customer into teams, and cap what each one spends

A customer is no longer a single bucket of credits. You can now describe the structure inside a customer — departments, squads, environments, whatever matches how they buy — and set a spend cap on any part of it, for a period you choose. Spend rolls up the tree, so a cap on a parent watches the whole branch. Paid evaluates caps on a schedule and tells you when one is reached; it keeps recording spend, so your product decides what to do about it.

Each unit is addressed by your own key, not a Paid id, so the structure you already have in your system is the structure you use here. Keys are kept unique within your organization, a unit’s whole history is recorded, and a cap’s schedule survives later edits rather than being silently reset. When a cap is reached, Paid sends a billing-credit-cap-reached webhook so your product can react before anyone’s work is refused.

Available through the API, the SDKs and the CLI. Customer units and credit caps

Built by: Min, Nabil, Nassim

Build a dashboard by describing it, and embed it for your customer

Custom views are available to everyone. Describe the dashboard you want to an AI assistant, point it at your Paid data, and save the result — it appears under Custom views in the Analyze section. Narrow a view to one customer and you can publish it and embed it in your own product, so that customer sees a live view of their own usage and value where they already work. Views can be shared by link, given preview-only timeframes, and unpublished again when you are done.

Create a custom view with Claude · Embed a custom view

Built by: Binh, Camille, Georgi, Ivan

Billing and credits: improvements and fixes

• When tax calculation is switched on, you can set a tax code per product line instead of one code for the whole organization.
• Backprocessing an order now always replays its credits, so a corrected order and its credit ledger cannot drift apart.
• Plan order lines accept price and discount overrides, and the order page shows the full line detail, including the credits an order grants.
• A customer’s bank transfer details can be read back rather than only created, and incoming transfers are reconciled against the customer automatically, with a daily sweep for any that were missed. Bank transfers
• Early access. Graduated credit bracket rates, so a credit price can step by volume, with unit conversion handled for you.

Built by: Binh, Camille, Gareth, Ivan, Nabil, Nassim, Raj, Xifong

Turn usage into signals you can bill

• Early access. Metering is switched on for selected organizations. A rule says which usage counts, a window groups it over a period of your choosing, and the signals that come out bill like any other. A ledger shows every window and what it produced, rules can be filtered by status with inactive ones out of the way, and a detail panel narrates what happened inside a window. Meters

Built by: Gareth, Lewis, Nabil, Nassim, Xifong

App experience: improvements and fixes

• Search is available to everyone: ⌘K (Ctrl+K on Windows) opens a palette that jumps straight to a page, customer, invoice or order, with your recent destinations listed first.
• The app had a visual refresh — spacing, typography, icons, overlays, switches and tables all moved onto one design system in a single pass. Nothing moved and nothing behaves differently.
• Every chart in the app — signals, costs, delivered value, billings — now shares one theme, with consistent formats, tooltips and colours.
• The customers table, credit ledger, billings grid and overview page were rebuilt on the new design, with numeric columns aligned, a legend you can click to filter, and empty states that explain themselves.

Built by: Binh, Camille, Georgi, Ivan, Léo, Marta, Ulysse, Will

For developers: new read APIs, exports and the provisioning endpoint

What changes. The v2 API gained read surfaces that previously existed only inside the app:

• GET /api/v2/credits/transactions and GET /api/v2/credits/transactions/summary — the credit ledger, and a bucketed burn summary grouped by event name and credit currency, with exact decimal amounts. Credits
• POST/GET /api/v2/customers/{id}/funding-instructions, and the same pair under /api/v2/customers/external/{externalId}/funding-instructions when you address customers by your own id — create and read a customer’s virtual bank account for bank-transfer payment. Bank transfers
• POST /api/v2/provision is now part of the public spec, with an API reference page, SDK methods, a CLI command and an MCP tool. It enforces idempotency keys and order locks, so a replayed call cannot provision twice. Provisioning from a CRM
• Customer units and credit caps have a full CRUD surface under /api/v2/customers/{id}/customer-units. Customer units and credit caps
• Signal usage summaries can be exported as a spreadsheet-ready CSV through an asynchronous export job, and grouped summaries are now served synchronously from the rollup, by display id or your own external customer id. Chart signal volume

Who is affected. Anyone building on the v2 API, the SDKs, the CLI or MCP. Everything in this section is additive.

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

Built by: Gareth, Georgi, Lewis, Min, Nassim, Xifong