Changelog

What changed in sumwerk, newest first, released every Friday. Fixes that changed a number are listed too, with what was wrong.

9 October 2026

Check one number you know

A new MRR figure is only worth something once it matches a number you already trust. sumwerk shows your MRR next to its check against Stripe’s invoices: type a number you know, and see where the difference comes from, with your own amounts: yearly plans, other currencies, trials, taxes, discounts.

• Getting started. A new account chooses where to start (Revenue, CRM or Billing) and gets one list for all of sumwerk: connect Stripe, watch your history being read, check one number you know, customers, pipeline stages, a calendar, at-risk rules, billing, your app, your team, a sandbox. Every step ticks itself when it is done; “Not for us” sets one aside. Your history is read as soon as Stripe is connected, and we email you when it is in if you left the page.
• Import customers from a CSV. From your current CRM or a spreadsheet: say what each column is, look at the first rows, import, see what every row did, and undo it if it was the wrong file. Guide: Import customers.
• Connect your app, step by step. Name the app, make a token, copy the calls (Ruby, TypeScript or curl), and see the first customer arrive. Not your job? Invite a developer; they land on that page and make their own token. The clients send customers too: upsert_customer (Ruby), upsertCustomer (TypeScript).
• sumwerk is operated by Kitchn Venture GmbH (Berlin). The imprint, privacy policy, terms of service (2026-10-09) and data processing agreement (2026-10-09.2) name Kitchn Venture GmbH instead of Maier Enterprises UG; disputes with merchants go to Berlin. Every account is asked to accept the terms and the agreement once.
• New version of the data processing agreement and the privacy policy (2026-10-09). They describe connecting Stripe through the sumwerk app instead of a key: nothing of your Stripe account is stored, sumwerk only reads until you switch on billing management, and disconnecting or uninstalling ends the access at once. Every account is asked to accept the new agreement once.

2 October 2026

• Fix: the Stripe connect screen names every permission the key needs. Since 23 September sumwerk also reads your Stripe account’s own id, so a key can never be switched to another Stripe account, but the screen did not list that permission and a key made exactly as described was refused. It now says to also set All Connect resources to Read.

29 September 2026

• Fix: the guide “Connect your product to sumwerk” is listed on the docs page again. Its card there was empty since 24 September, and the guide itself had no page title.

25 September 2026

• sumwerk now learns which parts of it are used. Our server records which app pages signed-in people open and the changes they make (a task created, a customer edited, a CSV downloaded), never what they contained, and sends them to datalove, our own product analytics in Germany. Public pages are counted too: the page, the linking site’s domain and campaign tags, and unique visitors per day the way Plausible counts them (a daily code from address and browser, never stored, gone the next day), with country, browser and device type, with no cookie. No cookie or script in your browser; nothing in sandboxes or through the API. The privacy page says what, why and for how long, and how to object.
• A calmer usage card. A group of metrics is always shown as its group, even with one part, and its heading carries the group’s total of the last 30 days and its change. A metric that only feeds a ratio or a rule can be kept off the card: untick “on customer page” on the Attributes page or send hidden: true on PUT /api/v1/usage-metrics/:key. Rules and automations still read it.
• Fix: a new Plain conversation no longer fails when Plain sends two events for it at once. Plain sends several events for a new thread within the same second; when two arrived together, one could fail and wait for Plain’s retry. Now both are written to the same conversation.

24 September 2026

• A usage ratio can add metrics up. Numerator and denominator each take one metric or several joined by +, for example a share of all ads where one side comes from another source.
• A tidier customer page. Usage, the timeline and the ledger on the left; tasks, details, people and one card for Stripe customers and ids on the right. Long lists fold: people to one line, the timeline to its latest four entries, emails to their subject, attributes and the ledger after six. Hovering a usage chart shows each week’s values, and a usage metric can have its own color.
• Old invoices left open are told apart from customers who stopped paying. When a subscription has an invoice still open but later invoices were paid, the at-risk list shows “Old invoice still open” with the invoice number, date, amount, how many invoices were paid since and a link to it in Stripe. It is low risk by default (adjustable on the account page) and adds nothing to the MRR at risk. Before, such a customer showed as “Unpaid for too long”, high risk, with its whole MRR.
• Fix: removing one of your own at-risk rules removes its exceptions too. Before, a customer kept “not flagged, on purpose” for a rule that no longer existed.
• Usage metrics can be grouped. Metrics with the same group, such as ads launched per platform, are one stacked chart on the customer page, with each part’s last 30 days and change. Set the group on the Attributes page or with group on PUT /api/v1/usage-metrics/:key.
• Scheduled downgrades are at risk from the day they are scheduled. When a subscription schedule in Stripe lowers the price at its next phase, the at-risk list shows it as “Downgrade scheduled” with the MRR it takes away and the day the lower price starts, until Stripe switches the price; then it is a contraction as before. Its level is set on the account page (medium by default), and downgrade.scheduled / downgrade.withdrawn can start automations.
• Usage over time. Your application sends what each customer did per day (ads launched, active users, connected accounts, spend) with PUT /api/v1/sources/:source/usage/:date, for all its ids at once. sumwerk keeps every day, adds up the ids of one company, and your at-risk rules and automations can compare windows: usage.ads_launched.change_28d_pct at most -70 flags a customer that was active and has mostly stopped, not only one at zero. Metrics are sums, levels or ratios of two sums, described on the Attributes page. The customer page shows half a year of them in weeks. See Usage over time.
• A customer can hold several ids of one source. A company with two workspaces in your application is one customer; before, the second id was refused. Add an id on the customer page, or let your application say who pays: stripe_customer_ids on the source address joins a new id to the customer that holds its Stripe customer. A Stripe customer that belongs to another customer is never moved; the answer says so in warnings.
• Tokens are simpler. A token reads, or reads and writes, the whole account; which ids a call uses is in its address. The per-token source setting is gone, and tokens that had one work for the whole account. People of a customer can now be sent under your id: POST /api/v1/sources/:source/customers/:id/contacts.
• Imports leave your application’s data alone. An attribute belongs to the application that sends it; a ChartMogul import no longer overwrites it, nor the name, company and trial dates of the customers your application sends. Other attributes can be left out when the import starts.
• Breaking API change: customers and contacts have one ID, a UUID. A customer’s id in every response, nested customer.id and customer_id, customer URLs and a contact’s id are UUIDs; public_id is gone. Integer ids are no longer accepted by the API or MCP. Old browser links to a customer page redirect to the UUID, and unsubscribe links in emails sent before the change keep working. Customer lists break ties by creation time.

• Breaking API change: each customer has one ID per connected application. Customer writes require a source URL; the old customer PUT returns 410. IDs are labelled by their source, with no primary selection, retired aliases or combined attribute values. Explicit linking refuses conflicting IDs. Use the customer’s id for contacts and activity; see the integration guide before resuming your sync.

• ChartMogul imports keep only ChartMogul and verified Stripe IDs. App IDs and email-source aliases are ignored. Imported customers have a dedicated ChartMogul source; link your application’s ID explicitly after locating the customer by ChartMogul or Stripe ID. Existing mappings remain unchanged. Conflicting established customers are reported for manual review.

• Save token access together. One save button now saves every token selection, preventing another row’s unsaved selection from disappearing. Settings explain account access versus customer-only synchronization; application setup, token creation and API examples are separated.

23 September 2026

The compatibility and alias behavior described below was superseded by the September 24 breaking change.

• Separate customer IDs for each connected application. Configure sources on Account → API and use /api/v1/sources/:source/customers/:external_id. Two apps can use 123 independently. Customer pages support explicit linking and verified legacy assignment. Primary selection rechecks retirement under the account lock. Responses add public_id without changing v1 numeric IDs. Existing unbound customer PUTs remain backwards compatible; moving an existing producer to a named source is a separate, coordinated step.

• A sandbox may send, for an end-to-end test. Under Account → Email in a sandbox, an owner or developer chooses: keep every email (the default), send only to addresses of people on the team, or send to anybody. Everything not allowed out is kept as before.
• Sent from here on the Email tab: the latest emails written by a person, a sequence or an automation, with who sent them, how they went and the full text. In a sandbox the same list is what would have gone out, since a sandbox sends nothing.
• Team page: who sends from where. Each member’s line says whether their emails go out from their own connected mailbox or as “Name via sumwerk”, with a link to connect yours. In a sandbox the Email tab now says that nothing is sent and that the mailbox connection is the one from live mode; the company’s Google app is set up once, in live mode.
• Try customer research before you rely on it (Account → Customer research → Try it): run it on a customer you name, read the result on the tab, tune the prompt, run again. A test writes nothing to the customer.
• Retry-After on every 429. A rate-limited answer from the API or MCP now says how many seconds to wait, plus X-RateLimit-Limit, so a client retries at the right moment instead of guessing. The 600 per minute now count across the whole API per token, as the reference always said, instead of per endpoint. Asked for on the feature board.
• Bookings: team calls. A collective Calendly event or a cal.com team event names several hosts. Every host with a login gets the task, the first of them owns the lead, the note names them all, and a cancellation closes every host’s task. Asked for on the feature board.
• Customer list pages in the API. GET /api/v1/customers answers at most 100 customers per call, with pagination.next_page to follow; clients that read the whole list adopt it. Customer CSV downloads stream in batches.
• CSV cells are safe in spreadsheets. Text that starts like a formula is neutralised in every export.
• A replacement Stripe key must belong to the same Stripe account and mode. Live and test history can no longer be mixed by a key rotation.
• Closed months follow an empty ledger. A recalculation that leaves no revenue history restates the closed months to zero instead of keeping stale figures.
• Queued emails respect a late unsubscribe. A mail waiting to be sent is dropped when the recipient unsubscribed, was removed, or the sequence was stopped in the meantime; a send with an uncertain result is flagged for review instead of sent again.
• Merging customers keeps more. Unsubscribe preferences, email and sequence history, research runs and the links in mails already sent move with the merge.
• Recalculations and syncs recover. A failed recalculation keeps its request so the retry does the work; interrupted automations and sequences do not repeat local actions; a minute-by-minute sweep picks up what a restart left behind.
• Google mailbox connections reject expired or mismatched authorization attempts.
• Customer research refuses internal network addresses and limits how much of a website it downloads.
• Bookings from Calendly or cal.com become leads (Account → Integrations → Bookings): every booked call creates the lead, or finds it by the person’s email or the company’s domain, adds the person, makes the host the owner, writes a note with the answers and puts a task on the host’s list for that day. A cancellation closes the task, a reschedule moves it. Calendly’s webhook is created for you from a token you paste once. Guide: /docs/bookings.
• A second organisation joins the company instead of splitting it. A PUT under a new id that names a Stripe customer another customer already holds now joins that customer and becomes its main id; before, it took the Stripe customer with it, which moved revenue history and restated closed months. A customer known by its own id can no longer take a Stripe customer away from another one: the call is refused with the record named.
• ChartMogul import: only new customers. A third mode for the import: leads that are not in sumwerk yet come in with their people, notes and tasks; everything that exists, under any id or Stripe customer, is left exactly as it is.
• Bars above the Log and above the API Requests: entries or calls per five minutes, hour or day over the window you chose, red where something failed, with the totals, and for the API the average, the 95th percentile and the slowest call. The Requests list on the API tab narrows and pages like the Log now: a window (the last 24 hours by default), a customer, a text, a token, refused or writing calls. The Account pages use the whole width of the screen.
• Account → Log narrows and pages: a from/to window in your time zone (the last 30 days by default), a customer’s name, a text such as an event type or a rule’s name, and pages of 50 with “Older”. The API has the same: from, to, customer, q, and next_before as the cursor.

22 September 2026

• Paying since is the start of the current paying stretch. A customer who churned and came back shows the return date as “paying since” in the list, on the page, in the API (paying_since), the CSV and MCP; “first paid” stays the first payment ever. Your own at-risk rules leave a customer alone for 7 days after they start or come back (Account → At-risk rules, 0 switches it off), and can use “Paying since (this stretch)” as a field.
• An ignored write is no longer silent. When your system writes a customer under an id that is not the main one, its name, dates, owner and tags are ignored as before, but the customer page now says so (“Data came through another id and was ignored”, with Make it the main id next to it), the ids panel marks the id, GET /api/v1/customers/:id carries ignored_writes[], and the Requests log says “ignored: name (not the main id)”.
• Delete an empty record: a customer that has nothing but its ids, for example one split off by mistake, can be deleted at the bottom of its page and with DELETE /api/v1/customers/:id. Anything with a Stripe customer, revenue, people, notes or tasks stays and is merged instead. The button next to an id now says “Split off into its own customer”, so it is not mistaken for removing the id.
• Forget an id on the customer page (Known under n ids → Forget) and DELETE /api/v1/customers/:id/ids/:value: for an id that no longer exists anywhere, such as a ChartMogul uuid that was merged away. What it sent goes with it; the customer stays. The main id cannot be forgotten.
• The ChartMogul import follows merges made in ChartMogul. Two records that ChartMogul merged since the last import are merged here too: the one with revenue wins, else the one with your own id, and everything else moves into it. Before, such a customer was left out with a validation message; the message now says what to do when a merge cannot be done.
• Customer research, with your own keys (providers under Account → Integrations, what it does under Account → Research): read a company’s website and, with Apify, its LinkedIn page and people, ask your LLM for a summary with your prompt, and get one note plus the attributes website, linkedin_url, industry and employee_count on the customer. A button on the customer page, the automation action “Research the company”, POST /api/v1/customers/:id/research, and the events “customer research is done / failed” for your rules. Guide: /docs/customer-research.
• Quick start on the API tab: next to the token, the calls a sales or research tool needs, ready to paste: read the numbers, create a lead under your own id, add the person, write a note.
• Requests from Stripe and Requests from Plain: every call to your incoming addresses (the Stripe webhook, the Plain webhook and customer card) with the status sumwerk answered and why: accepted, received before, dropped, or refused because the signature was not valid; and the time taken. Under the webhook on the Stripe tab and under Plain on Integrations; also GET /api/v1/webhook-requests. The body is never kept.
• Account → Log: what came in and what it changed, newest first. Every Stripe sync and webhook delivery, every write through the API, every read of Plain and every Plain webhook, imports, what automations did, and every change to a customer with where it came from. Filter by source, 7 or 30 days; also GET /api/v1/log.
• The subscriptions the daily check could not compare are named on Reconciled with Stripe, under their reason, with a link to the customer; and a line says how the numbers add up (“145 compared and 4 not comparable: 149 subscriptions count today”). Also not_compared[] in GET /api/v1/reconciliation.
• Three roles: owner, developer and member (Team page). Owners invite, now with a role, and change a colleague’s role. Developers do the technical part: Stripe key and webhook, signing secrets, sandboxes, integrations, imports, the reporting settings. Members do the day-to-day, automations, at-risk rules and their own API tokens included (for a spreadsheet or Claude); a member revokes their own tokens, owners and developers anybody’s. Everybody who was a member stays one until an owner says otherwise.
• The movements dated by inference are listed on Reconciled with Stripe (/reconciliation) and in GET /api/v1/reconciliation as inferred[]: every movement where no invoice or event says when the change happened, with customer, kind, amount and date. A few are normal; a sudden rise means something is not read yet.
• Rename a sandbox (Account → General → Sandboxes): the data and the tokens stay, only the name changes. Asked for on the feature board.
• Narrow the customer list right there: a form above the list offers the owners, plans, billing intervals, tags, countries, currencies and attributes your account has; combine several, then keep the result as a view.
• A sync that runs by itself is one line on the Overview (with its progress); the step-by-step panel stays for the first import and on the Stripe tab.
• MRR movements by plan: new business, expansion, contraction, churn and reactivation per plan and month, under Segments → Plan and in GET /api/v1/plans/history. A plan change counts in both plans.
• Messages in the app for three more things: a task somebody handed to you, your import that finished or failed, and a webhook that was given up after a day of attempts (owners).
• Feature board: comments under a request (for signed-in users; operators answer as sumwerk), duplicates are merged with their votes, and a done request links to its changelog entry.
• Terms of service, in English and German: what the service is, early access, your data, availability, liability, ending the account. Accepted with the same tick as the agreement below.
• A data processing agreement (Art. 28 GDPR), in English and German, with our security measures and sub-processors. New accounts accept it with a tick at sign-up; owners of existing accounts accept it under Account → General. Who accepted which version, and when, is kept on record.
• The public site has a language switch (English, Deutsch) in the footer.
• The privacy page was rewritten (English, Deutsch): what we process for you and what on your behalf, who processes data for us (Hetzner, Postmark, Cloudflare) and where, how long things are kept, and what is your own side when you connect Stripe, Google, Plain, a webhook or an AI assistant. Nothing about the product changed: there is still no analytics and no tracker.

21 September 2026

New

• MRR by plan, month by month. What each plan was worth at the end of every month, from what every subscription item was worth that day: a customer who moved from one plan to another counts under the old one until the day they moved. The plans of a month add up to the month’s MRR. Segments → Plan, and GET /api/v1/plans/history.
• Revenue retention per segment. NRR and GRR over twelve months for every row on Segments (by owner, plan, tag, country or any attribute of yours), in the CSV and the API too.
• Several of your ids, one customer. An agency’s organisations, or a paying organisation and an empty trial: each id sends its own values and the customer shows them combined (numbers add up, dates take the latest, text follows the main id). The last writer no longer wins. On the customer page an id can be made the main one or split off. How it works.
• Saved views of the customer list. Any narrowed list (tab, search, filters, order) can be kept under a name for the whole team.
• Webhooks are tried again. When your server is down: after 1, 5 and 30 minutes, 2, 6 and 24 hours, each attempt signed anew with the same delivery id. The API tab lists what was sent, with Send again.
• More of the account through the API: GET /api/v1/me (live or which sandbox, and what the token may do), exceptions from your at-risk rules, and grouping products into plans.
• Sandboxes, several per account and with names: one for staging, one per developer. Test tokens start with swk_test_, no email leaves a sandbox. Guide.
• A log of API requests per token: what your system sent (field names, never values), how it was answered, what it did.
• Closed months and restatements. A month closes a few days after it ends; from then on a changed figure is listed with the date, the reason and the customers behind it, never silently. One recalculation is one entry.
• Reconciliation with Stripe after every sync: what sumwerk values each subscription at, against Stripe’s latest regular invoice.
• Your own at-risk rules, with up to five conditions, exceptions per customer, and “+ rule” from every Segments row. Guide.
• Plans: Stripe products under your own plan names, with suggestions for products that only differ by billing words. Guide.
• Joining a team after signing up alone: somebody who signed up before the invitation came can accept it; their empty account is removed.
• A public board of feature requests. Suggest what sumwerk should do and vote for what others asked for. We read every suggestion before it shows; when something is done, everybody who voted gets an email and a message in the app (the bell in the header is new too).
• A public status page, checked every minute from outside our own server.
• Emails from sumwerk (password reset, invitation, restatement notice) have a proper layout; emails your team writes to customers stay plain, they are yours.
• sumwerk.com has a German front door: sumwerk.com/de, with Impressum and Datenschutz in German.
• Three new articles: MRR in several currencies, why a plan change is not churn, and trial conversion by cohort.
• Connect your product: a step-by-step guide for the developer who does it.

Fixed

• A discount on a single subscription item was dated wrongly. It appeared as a contraction at the latest renewal and moved one month on with every renewal. It now counts from the day it started. A coupon that was applied a second time no longer counts twice for the weeks until the next invoice.
• The at-risk CSV export, and the same list in the API, failed for a customer flagged by a rule of your own whose subscription is not ending.
• When a sync or an import failed, the page showed the technical error. It now says what you can do about it, or that the fault is ours.

20 September 2026

• Import from ChartMogul: customers with all their ids, tags, owners, attributes, people, notes, calls and tasks. Importing again finds what is there instead of doubling it. About the import.
• Customers independent of Stripe: leads and trials that are not in Stripe, through the API, with your own id; one customer can have several Stripe customers, each link with a reason.
• Notes, calls and tasks on the customer’s timeline, through the API as well.
• Automations: rules on events (a trial started, a cancellation was scheduled) that add tasks, set owners, tag, send an email or call a signed webhook.
• Email: templates, sending as the team member through their Google mailbox or sumwerk’s sender, sequences, an unsubscribe link in every automated mail.
• Funnel: leads, trials and trial-to-paying conversion by the month a trial started.
• Segments: the customer base by owner, tag, country, currency or any attribute of yours.
• MCP server: ask an AI assistant about your numbers and customers. Guide.
• Support conversations from Plain on the customer’s timeline. Guide.

18 September 2026

• sumwerk is live: MRR from Stripe with a read-only restricted key, every movement linked to the Stripe invoice or event behind it, several currencies at the European Central Bank’s rates, MRR at risk, CSV exports and a JSON API.