Plans, limits and billing — the plain answers

One usage event is one record your application sends to MeterFlow — “customer user-842 generated 1 image”, “rendered 42 seconds of video”. Every record counts once, whether you send them one at a time or many in a single batch call.

Events are counted per organization — across all of its projects and all of your customers — over each calendar month (UTC). Reads never count: checking a balance, listing plans or pulling a usage summary is free. Granting or deducting credits is not a usage event either.

How an event turns into a number on a customer’s usage page is explained in the dashboard guide.

Usually, yes — and it is the single biggest lever you have. A usage event carries a quantity in its value field, and a meter whose aggregation is Sum adds those values up. So one event with value 1,300 is one event against your monthly allowance and 1,300 units on the meter.

The style that burns through a plan is one event per API call: 1,000 users making 100 calls a day is roughly 3 million events a month. Aggregate in your own application over whatever window you can afford to lose if it crashes — a request, a job, a minute — then record one event with the total.

Note that batching is not the same thing: sending 100 events in one batch call saves HTTP requests, but each one is still its own record and still counts. Only folding them into a single event with a larger value reduces the count.

Two limits on the trick: it works for Sum meters, because Count meters ignore the value and count occurrences; and it changes nothing about what anyone pays, since a metered plan limit charges per unit either way.

You hear about it well before it bites: we email the organization’s billing contact at 80 % and again at 100 % of the included events, and the Billing page shows the month’s usage against your plan.

Crossing 100 % does not stop ingestion on the spot — a small allowance above the included amount keeps your production traffic flowing while you decide. Past that, new usage events are rejected with a clear “Plan limit reached” error (HTTP 403) until you upgrade, add an event pack, or the new month starts. Nothing is silently dropped, and nothing is charged — MeterFlow never bills overage.

Everything else keeps working: the events already recorded, credit balances, subscriptions, the dashboard and every read endpoint. The counter resets at the start of each calendar month (UTC), and an upgrade raises the limit immediately.

Your application receives the rejection as a normal API error, so treat it like any other 4xx: log it, and don’t retry blindly.

No. Every plan is a flat monthly price with a fixed number of included events. The “Effective price / 1,000 events” row on the pricing page is simply that price divided by the included events — a like-for-like comparison figure, not a rate we charge.

If you need more events than your plan includes you have two ways to get them, and neither is an overage bill: move up a tier, or add an event pack — 100,000 extra events for $15, bought from your Billing page, up to ten at a time. A pack covers the month you buy it in (buy one in the last five days of a month and it covers the next one too) and there is no rollover. It is priced above every paid tier’s effective rate on purpose, so for steady growth an upgrade is the cheaper move and a pack is for the spike you did not plan.

Not at the moment — every plan is billed monthly. If annual billing matters for your procurement, tell us at support@meter-flow.com.

Checkout and billing are handled by Paddle, our merchant of record. Prices are in USD; Paddle shows your local currency and any applicable VAT or sales tax at checkout, takes the payment (cards, PayPal, Apple Pay, Google Pay) and issues the invoice. Businesses can enter their VAT number at checkout.

Yes, at any time. Upgrades raise your limits immediately. If you cancel, your plan stays active until the end of the period you have paid for. Your first payment is covered by a 14-day money-back guarantee — see the refund policy.

Downgrading never deletes anything: if your organization is above the lower plan’s caps, what exists keeps working, you just can’t add more until you are back under them.

A project, almost always. A project is one product or app: it has its own API keys, meters, plans, customer balances and usage, and projects never see each other’s data. All projects in an organization share one event quota and one bill — every paid plan includes 20 of them.

An organization is the billing boundary: its own plan, its own event quota, its own invoice, its own team. Create a second one only when you genuinely need separate billing or a separate team — two companies, say. Each organization is billed on its own plan, and additional ones start free on Drip.

One organization, with one project per product or client. You pay once and the event pool is shared across all of them. Several organizations means several bills.

Give a client their own organization only if they must receive their own invoice and manage their own team — that organization then runs on its own plan.

No. Team seats are your teammates in the dashboard — you plus the people you invite. Your end-users never log into MeterFlow; they exist only as customer IDs in your project, are unlimited on every plan and carry no per-customer fee.

No. The organization cap only counts organizations you own. Inside an organization you were invited to, its owner’s plan applies — to everyone in it.

Yes, and the numbers are published: 20 projects, 75 meters per project, 10 API keys per project and environment, 30 webhook endpoints per project — the same on every paid plan. They are platform ceilings sized so a real integration never meets them, not upsell levers: upgrading doesn’t move them. If your integration genuinely needs more, write to support@meter-flow.com.

The free Drip plan has smaller caps for evaluation (2 projects, 5 meters, 4 API keys per environment, 3 webhooks); there, upgrading does raise them. The API-key cap stays modest even on paid plans on purpose: every active key is a credential and its own rate-limit bucket, so it is a security ceiling — revoke keys you no longer use.

The create action is refused with a message naming the limit — nothing that already exists is affected. On Drip the message invites you to upgrade, because paid caps are higher; on a paid plan it points you to support, because upgrading wouldn’t change the cap and we don’t want to promise otherwise.

No — every plan includes both. Test keys (mf_test_…) and live keys (mf_live_…) write to fully isolated data: balances, subscriptions and usage never mix, while meters and plans are shared configuration you define once. The API-key cap applies per environment, so a project gets the full count of live keys and the full count of test keys.

Retention is how far back your usage history stays queryable for summaries and analytics — from 45 days on Drip to 12 months on Torrent. Credit balances and the transaction ledger are never deleted, whatever the plan: every grant, deduction and charge stays on record.

Community (Drip): the documentation on this site and the issue trackers on the public SDK repositories (Node.js, Python) — read any time, answered when we can, with no guaranteed response. Email (Flow): write to support@meter-flow.com (or use the help form) and a human answers. Priority (Stream and Torrent): your messages are handled ahead of the queue.

No plan includes a contractual SLA yet — we won’t print one until we can honour it.

Node.js (npm install meterflow, docs) and Python (pip install meterflow, docs). Both are fully typed, carry one dependency, and cover the same operations: credits, usage events, subscriptions, plans and entitlement checks, plus a read-only view of your webhook endpoints and their delivery receipts. Any other language calls the REST API directly — the SDKs are thin wrappers over it, not a separate feature set.

The dashboard guide explains every dialog field by field with worked examples, and the dashboard tour shows the screens. This page only covers plans and billing.