MeterFlow

You sell it by the unit. We count it.

How MeterFlow turns what your customers do into credits, limits and invoices — explained without the jargon.

For your engineersA few lines of code inside your app.
For everyone elseA dashboard for prices, plans and balances.
Time to set upAn afternoon, not a quarter.

The problem

One customer click. Six things that have to happen.

Charging by usage sounds like counting. It isn't. Every single action a customer takes sets off a chain, and every link in it can fail.

One click a customer does the thing you sell 1Is this customer allowed to? 2Let your product do the work 3Write down that it happened 4Add it to their running total 5Check it against their limit 6 · And tell somebody Low balance, limit reached, plan renewed — someone needs to act on it. All of it must survive a dropped connection halfway through, a retry that arrives twice, a customer running out mid-request, and a bill dispute six months later.

Why it matters. Steps 1 and 2 have to be fast, because your customer is waiting. Steps 3 to 6 have to be perfect, because they are money. Most teams build this once quickly, and again properly after the first billing dispute.

The shape of it

MeterFlow sits behind your product, not in front of it.

Your product the app your customers pay for MeterFlow SDK a small package your developers install once what happened can they? MeterFlow counts every event keeps every balance holds your plans and prices never edits its own history sends you the alerts the numbers prices, limits The dashboard you and your team, in a browser set what you charge for invite your colleagues look up any customer

Why it is split this way. Your customers only ever see your product. Your engineers only ever touch the left-hand box. Everyone else — finance, support, whoever sets the prices — works entirely in the right-hand box, without needing a release.

The vocabulary

Learn four words and you understand the whole product.

Meter
The thing you count."images.generated"
"minutes.transcribed"
Plan
What you actually sell: a price, a period, and what's included.Starter — £29/month
5,000 images
Subscription
One customer, on one plan, from a date. Renews itself."ana" → Starter
renews 1 Oct
Credits
The balance in a customer's account.+5,000 granted
−1,340 spent
defines is chosen in tops up Meter Plan Subscription Credits every usage event your app reports is counted by a meter — and spends credits back down
Same four names in the dashboard, in the SDK and in the API. Nothing gets renamed on the way through.

The SDK

For your developers, it is about three lines.

  1. Install the packageOne command. It drags nothing else into your product — no other libraries come with it.
  2. Paste in your keyCopied from the dashboard once. It tells MeterFlow which project these numbers belong to.
  3. Say what happenedWherever your product does the thing you charge for, one sentence: this customer just did this.
Node.js today. Python next. Anything else — Go, Ruby, PHP — calls the REST API directly.
// 1. install
npm install meterflow

// 2. connect
const mf = new MeterFlow({
  apiKey: 'mf_live_…'
});

// 3. report what happened
await mf.usage.record({
  customer_external_id: 'ana',
  event_name: 'images.generated',
  value: 1
});

Under the bonnet

What happens in the half-second after a customer clicks.

While your customer waits 01Ask Does Ana have enough credit for this? 02Answer Yes — or a specific "not enough credit" 03Your work runs The image is made, the file stored, the call typed 04Report it Accepted immediately. Your app moves on. 0 ms ≈ 10 ms your product's own speed ≈ 10 ms After your customer has gone Totals updated Limits checked Alerts sent to you Invoice lines built

Why the work is split in two. If MeterFlow did all its arithmetic before answering, your busiest customers would be your slowest ones — the more they use, the longer they'd wait. Instead we accept the event instantly and total it up afterwards, so your product's speed never depends on how much anybody has used.

The safety net · 1 of 3

Asked twice, charged once.

Connections drop. When they do, your app has no way of knowing whether the request arrived or not — so it sends it again. That is the correct thing for it to do.

Your appfirst attempt deduct 1 credit · ticket A7 the reply never arrives Your apptries again deduct 1 credit · ticket A7 the same ticket number, not a new one MeterFlow "I have already seen ticket A7." Returns the same answer as before. Does not charge again. Ana's balance 5,000 ↓ 4,999 once, not twice

Why the ticket number matters. Without it, a two-second network blip costs your customer real money and costs you a support ticket. Every request that changes a balance can carry one, and MeterFlow only ever acts on it the first time.

The safety net · 2 of 3

A balance nobody can type over.

What happened Change Balance Subscription renewed +5,000 5,000 images.generated −1 4,999 images.generated ×350 −350 4,649 Goodwill credit — support +250 4,899 new lines are only ever added here ↓ nothing above this line can ever be changed

A customer's balance is not a number sitting in a box that somebody can edit. It is the sum of every credit they have ever been granted, minus every one they have spent.

Why it works this way. When a customer writes in to say "we never used that much", you do not need to be believed — you show them the list. Every line has a date, a reason and an amount, and no line has ever been altered. That is the difference between a billing conversation and a billing argument.

An append-only ledger with the balance cached alongside it, protected against two things updating it at once.

The safety net · 3 of 3

Running out is a polite refusal, not a crash.

5,000 0 balance reaches zero next request → refused, clearly time →

When the balance hits zero, the next request gets a specific, named answer: not enough credit. Not a timeout. Not a generic failure. Not a silent success that quietly puts the account into debt.

Your app can respond properly

Because the answer is specific, your product can show "you're out of credits — top up" instead of an error page. That screen is one of your best upgrade prompts.

You are never in the red

Nobody can spend money you have not been paid for, and no engineer has to write the code that works out whether a partial charge was allowed.

Notifications

You get told the moment something matters.

You never have to poll or check. When something happens you would want to know about, MeterFlow sends your app a message within seconds — and signs it, so you can prove it came from us.

MeterFlowAna is running low balance.low · customer "ana" · 42 left signature 8f3a·c19d·04be Your app checks it signature matches → accepted Someone elseguessing your address credits.granted · customer "them" · +10,000 signature — missing or wrong Your app checks it no match → ignored

Why the signature is there. The address your app listens on is out on the open internet. Without a signature, anyone who found it could send you a message saying a customer had paid, and your app would believe them. With one, a forged message is thrown away before it does any damage.

The dashboard

Where the non-developers run all of it.

Sign in and you see your organisations, your projects and everything inside them. Changing a price needs no engineer, no release and no database.

  • Organisations your company, and the colleagues you invite
  • Projects one per product, or one each for testing and live
  • API keys the keys your app uses — created and revoked here
  • Meters the things you count
  • Plans what you sell and what it costs
  • Subscriptions who is on which plan
  • Credits & usage balances, history and what got used
The MeterFlow dashboard listing organisations and projects

Everything you own, on one screen. Light or dark.

The procedure

Six steps from empty account to first charge.

one-off setup — you, in the dashboard from then on — usually automatic, from your app 01Create aproject one per product 02Create akey shown once only 03Add yourmeters name what youcount 04Build yourplans price, period,what's included 05Put customerson a plan when they sign up 06Grant credits then watch themcome back down Steps 1 to 4 you do once, by hand, and rarely touch again. Steps 5 and 6 happen every time somebody signs up or pays — so your app does them, through the SDK, without you.

Why the key is only shown once. After you copy it, MeterFlow keeps only a scrambled fingerprint of it — enough to recognise your app, not enough to reconstruct the key. If our database were ever stolen, the keys inside it would be useless. The cost of that is that we cannot show it to you again: lose it, and you revoke it and make a new one.

Day to day

Then you mostly just watch.

The usage screen in MeterFlow showing usage per meter for one customer

One customer's usage, broken down by meter.

Type a customer's name and you get their whole picture: what they have left, what they have spent, and what they spent it on.

  • Balance what this customer has available right now
  • History every top-up and deduction, in order, with the reason
  • By meter which parts of your product they actually use
  • Corrections grant goodwill credit or fix a mistake, on the spot

Why support cares about this screen. "Why is my bill this much?" gets answered in about thirty seconds, by whoever picks up the email — without raising a ticket for engineering.

Safety

Test money and real money never meet.

Your organisation Project — Testing mf_test_4b1c… pretend customers pretend balances experiment freely break it on purpose Project — Live mf_live_9c4b… real customers real money real invoices real disputes cannot see across

Projects are sealed

A key belonging to one project cannot read, change or even detect anything in another. Every record carries the project it belongs to, and every request is checked against it.

Your team, with roles

Invite colleagues as admin, member or viewer. Someone who only needs to look up balances does not also get the power to change your prices.

The alternative

Or your team could build all of that instead.

Building it yourself

  • Months of engineering before you can charge anybody a penny
  • A ledger that has to be right the first time, because you cannot un-charge a customer's trust
  • Retries, duplicate protection, rate limits and background jobs — all of it, before launch
  • Every price change is a code change and a release
  • And someone maintains it for as long as the product lives

Using MeterFlow

  • An afternoon to wire up, and you can charge on day one
  • The ledger is already append-only, already tested, already proven
  • The difficult parts run in the background and are somebody else's job
  • Price changes are a form in the dashboard
  • Your engineers go back to building the thing you actually sell

Getting started

Count it once. Charge for it properly.

Create an account, make a project, copy a key. Your first metered event can be recorded before your coffee goes cold.

Node.jsnpm install meterflow
Pythoncoming next
Everything elseREST API
Create a free account Read the docs
What this is
01/16