Monitoring RapidAPI quota burn: staying inside the free tier on a side project

My downloader site, ramrom.io, talks to three paid APIs through RapidAPI: one all-in-one service, plus a dedicated Facebook one and a dedicated YouTube one. Every one of them has a free tier with a monthly request limit, and when the limit runs out the API does not send a polite warning. It just starts returning errors, and my visitors see a broken tool.

So before I wrote any download code, I worked out how much each click actually costs me. One resolve on the homepage is not one API call. A visitor pastes a link, my server checks it, calls the provider, and sometimes retries when the provider says it is busy. A single download can burn two or three requests. Multiply that by a busy afternoon and the free tier stops looking generous.

The first thing I do is count my own calls before RapidAPI counts them for me. Every time resolve.php calls a provider, it appends one line to a small daily log file: the date, the platform, and the result. That is it. No user data, no pasted links, just a tally. A tiny script reads that file and tells me how many requests went out today and how many are left against the tier limit. I check it most evenings, the way you would check a fuel gauge.

The second thing is knowing what the limit actually is. RapidAPI shows your usage in its dashboard, but the dashboard is a day behind in my experience, and it mixes all your APIs together unless you look at each one. So I keep the numbers in a plain text note next to the code: the monthly allowance for each API, the reset date, and the rough cost per visitor. When I add a feature, I check the note first. If a feature would double the calls per download, it does not ship.

The third thing is cutting calls I do not need. The biggest waste was visitors pasting links my APIs could never handle: a random website, a private post, a link with a typo in it. Each of those used to cost me a provider call before the provider told me it was no good. Now the server validates the pasted URL first — is it actually TikTok, Instagram, Facebook or YouTube? — and only then spends a call. That one check probably saves more quota than anything else I have done.

I also debounce the front end. A fast typist used to trigger a resolve on every keystroke change, and every resolve was an API call. Now the button only fires when the visitor actually taps it. It sounds obvious, but the first version of the site did not do this, and the quota burn showed it.

Retries are the other quiet cost. My code retries a flaky provider up to three times, which is right when the provider is briefly busy, but three attempts on a link that will never work is three wasted calls. So the retry only happens on the specific errors that mean "try again" — a timeout or a "service is busy" message. A "not found" or "private video" answer is final on the first try.

Finally, I watch the trend, not just the total. If Tuesday uses twice as many calls as Monday with the same number of visitors, something changed: maybe a provider is failing and my retries are kicking in, or a new kind of link is slipping past validation. The daily log makes that visible in a minute.

None of this is clever. It is a text file, a counter, and a habit of checking it. But it is the difference between a free tier that lasts the whole month and one that runs dry on the 12th. If you are building a side project on someone else's free tier, work out your cost per click first, count your own calls, and never let the provider be the first one to tell you that you have run out.