Pull API vs Push API: Feeding Business Metrics Into Cost Data
Two ways to move a number from the system that counts it to the system that divides cost by it.
A push API receives data that a client sends to it: the producer decides when to call, and the receiver accepts whatever arrives. A pull API works the other way round: the consumer calls an endpoint the producer exposes, on its own schedule, and takes what it finds. Both move the same data. They differ in who initiates the transfer, who holds credentials for whom, and what happens when something fails.
The choice comes up in cloud cost work whenever a business number has to be joined to spend, as in unit economics, where daily active users, orders, or request counts become the denominator of cost per unit.
How the two compare
| Push | Pull | |
|---|---|---|
| Who initiates | The producer, for example a nightly analytics job | The consumer, on its schedule |
| Credentials | Producer holds a token for the receiver | Receiver holds credentials for the producer’s endpoint |
| Network exposure | Producer needs outbound access only | Producer must expose an endpoint the consumer can reach |
| Timing | As soon as the producer has the value | At the consumer’s next fetch |
| Failure handling | Producer must notice failures and retry | Consumer retries on the next cycle |
| Change of logic | Changing the job that sends | Changing the endpoint that answers |
Neither is better in general. Push suits data that already flows through a pipeline you control, because adding one more HTTP call to an existing job is cheap. Pull suits data that already sits behind an endpoint, because nothing new has to run on the producer’s side.
Design points that apply to both
- Idempotency. Sending the same day twice must not double it. Key each value by metric, date, and any dimension, and treat a repeat as an update.
- Explicit dates. Send the date the value describes, not the time it was sent, so a late run lands in the right bucket.
- Backfill path. A new metric needs history. A bulk file upload is simpler than replaying months through an API.
- Security of pull endpoints. A consumer that fetches arbitrary URLs must defend against being pointed at internal addresses, a class of attack known as server-side request forgery.
How ZopNight ingests unit metrics
ZopNight’s unit economics feature accepts denominator values three ways, all writing to the same table by idempotent upsert keyed on organization, metric, date, and dimension:
- Push API: your pipeline POSTs an array of date and value pairs for a metric.
- CSV upload: a multipart file for backfill or one-off loads, capped at 1 MB or 5,000 rows.
- Pull API: you register an HTTPS endpoint, its authentication, and an interval, and ZopNight fetches it on a daily schedule. A Test fetch runs the full pull path immediately so you can check the response before the schedule starts.
Pull credentials are stored encrypted, and every fetch goes through a request-forgery guard that resolves DNS before validating the address, blocks private, loopback, link-local, carrier-grade NAT, and IPv6 internal ranges, re-validates redirects, and enforces a 30-second timeout and a 5 MB response cap.
Picking one
Use CSV once, to load history. Then use push if the number is produced by a job you already run, and pull if it is already published by a service with an API. Mixing is fine, since all three land in the same keyed table.
See unit economics for cloud cost for choosing the unit itself, and how to set up cost per order tracking for a worked setup.