Push, pull or sync: three ways to get usage data into your billing system (and why you shouldn't have to choose)

Ask a usage-billing vendor how you send them data and the answer is almost always the same: call our API, or use one of our SDKs. That is one of three possible answers, and whether it is the right one depends entirely on where your usage currently lives.

Getting this wrong is the most common reason a billing project takes a quarter instead of a fortnight. It is worth ten minutes of thought before you choose anything.

Push: your code sends events

The default. Every time something billable happens, your application makes a call — an event with a type, a quantity, a timestamp and whatever properties the rating needs.

await pixel.track({
  event_id: crypto.randomUUID(),
  event_type: "api_call",
  timestamp: new Date().toISOString(),
  account: "acct_orbitapi",
  quantity: 1,
  unit: "requests"
});

Push is the right answer when the billable event only exists inside your application. A token generated by a model you are calling, a document processed, a webhook delivered — there is no file on disk recording it, so somebody has to emit it.

The costs are real, though, and they are not in the seven lines above. Every billable path in your code needs instrumenting, which means finding them all — including the ones added last month by someone who has left. You need an idempotency strategy, because retries will happen and a duplicated event is a double charge. You need to decide what happens when the billing API is unreachable: block the request, drop the event, or queue it somewhere durable. And every one of those decisions is now part of your application, to be maintained by your team for as long as you bill this way.

Pull: an agent reads what already exists

If your usage is produced by infrastructure rather than by your own code, it is almost certainly already written down. A FreeSWITCH or Asterisk switch writes call detail records for every call it handles, whether anyone reads them or not. Gateways write logs. Appliances write counters.

When that is true, instrumenting an application to re-emit those facts is work you do not need to do. An agent installed on the machine reads the records the switch is already writing, normalises them and ships them. No code is written, no billable path can be missed, and adding a second switch is another install rather than another integration.

Pull has its own considerations, and they are operational rather than architectural. Something has to run on your infrastructure, which means an update path and a security review. Files rotate and get truncated, and an agent that mishandles either loses calls. There is a lag between the switch writing a record and the agent shipping it, usually seconds, occasionally longer.

But the trade is stark: for infrastructure-generated usage, pull is one command against several weeks of instrumentation, and it cannot miss a code path because it is not reading code.

Sync: read the warehouse you already fill

The third motion, and the least discussed. Plenty of companies already land their usage in a warehouse — Snowflake, BigQuery, ClickHouse — because analytics needed it before billing did. The pipeline exists, it is tested, and somebody already owns it.

In that situation, pushing events to a billing system means maintaining a second pipeline carrying the same facts, with all the reconciliation pain that implies when the two disagree. Reading from the warehouse instead means one source of truth and one thing to fix when it breaks.

Sync suits batch billing rather than real-time limits, and it inherits whatever latency your warehouse has. If you need to cut off a customer the moment they cross a threshold, this is not the motion for that. If you need a correct invoice at the end of the month, it very often is.

Why you shouldn't have to choose

Here is the problem with a platform that supports one motion: real companies have more than one kind of usage.

A voice operator adding an AI feature has CDRs on a switch and token counts in an application. A SaaS business with an appliance product has application events and device counters. A managed service provider has infrastructure logs for some customers and API calls for others. If your billing platform only accepts pushed events, the parts of your usage that were already written down get an instrumentation project anyway — not because the data is hard to obtain, but because the platform only has one door.

• Usage produced by your own code → push it
• Usage produced by infrastructure that already records it → pull it
• Usage already landing in a warehouse → sync it
• All three at once, which is most companies past a certain size → you need a platform that does not make you choose

Questions worth asking a vendor

• Which of the three motions do you support today, as opposed to on a roadmap?
• If I have CDRs on a switch, what exactly do I have to write?
• If the same event arrives twice, what happens — and how do you decide it is the same event?
• If your API is unreachable for two hours, where do my events go?
• Can I use more than one motion at once, billed on one account?

The last one matters more than it sounds. A platform that supports push and pull but treats them as separate products gives you two dashboards and two invoices, which is not what you wanted when you asked for both.