Rate limits on a marketing API are not per request, they are per application over a rolling window. That single design detail is why an ads integration fails in the worst possible way: one badly written report that pages through six months of data does not fail on its own, it burns the shared allowance and takes every other call down with it. Campaign lists go blank, sync jobs die halfway, and the operator's first symptom is a screen full of empty tables.
The fix is not clever code at the moment of failure. It is refusing to get near the ceiling in the first place.
Platforms tell you where you stand, on every call
The major ad platforms return usage information with each response: how much of the current window your application has consumed, expressed as a proportion, and how long any existing penalty lasts. Most integrations ignore it entirely, discover the limit by hitting it, then retry immediately, which extends the penalty.
Scalegram reads that figure on every response and keeps it as live state rather than as a log line. The sync scheduler asks one question before it starts any batch of work: given where the allowance sits right now, is this call worth making?
Two thresholds, two different behaviours
The guard has two stages, and the difference between them matters more than the exact figures.
At the first threshold, the sync slows down. Intervals between batches widen, page sizes shrink, and work that was going to run in parallel is queued to run one at a time. Nothing is cancelled. The integration is simply less greedy, which in practice is enough to ride out a normal busy hour without any user noticing.
At the second, higher threshold, optional work stops. Backfills, full refreshes of historical data and anything a person did not directly ask for are parked and retried later. What keeps running is the short list of things a business genuinely cannot defer, and conversion events are top of it: a purchase or a registration fired from the server has a time window in which the platform will still match it to a click, so holding it back to preserve quota for a report would be exactly the wrong trade.
If a penalty does land, the guard waits out the stated duration rather than retrying into it. Retrying into an active throttle is the single most common way a team turns a two minute problem into an afternoon.
Why the local mirror does most of the work
The guard would be under constant strain if every screen in the product asked the platform a live question. It does not. Ad account structure, campaigns, ad sets, creatives and their spend are mirrored into local storage, and every list, filter, sort and search in Scalegram reads from that mirror with plain database queries.
The practical result is that a user typing into a search box generates no platform traffic at all. The API is touched on a schedule, to refresh the mirror, and on demand when someone changes something that has to be pushed. That split is the difference between an integration that stays inside its allowance forever and one that is permanently one enthusiastic user away from a throttle.
A mirror is a copy, and a copy has an age. Scalegram shows what it holds and when it was refreshed rather than pretending the number on screen is live. If you are about to make a spending decision on today's figures, check the refresh time first.
What an operator actually sees
Almost nothing, which is the design goal. Under load, refreshes take a little longer. A backfill that was queued reports itself as queued rather than as failed, because "failed" sends people to support and "queued" does not.
The one place it becomes visible is a first connection on a large ad account, where the initial import is the heaviest work the integration will ever do. That import is deliberately unhurried. Letting it take longer and finish is better than racing, tripping the limit, and leaving the account half imported with no easy way to tell which half.
The same discipline applies to everything else that syncs
Ad platforms are the loudest example, but the pattern repeats across every connection in the product. Checkout platforms have their own limits. Broker affiliate feeds are frequently range queries rather than live streams, which is exactly why purchase and deposit data is cached locally and matched from the cache. Inbound webhooks have the mirror image of the problem: they must be acknowledged fast, so the work they trigger is queued rather than done inside the request, a habit covered in webhook safety.
Every integration is connected once, at the account level, on the Integrations screen. That is not only tidiness. One connection means one place holds the credentials and one scheduler holds the allowance, and a shared allowance cannot be shared safely by two half-configured copies of the same connection.
None of this makes an integration immune. Platforms change limits, and they change them without much notice. What the guard buys is the difference between degrading and dying, and it buys back the hour your team would otherwise spend working out why the campaign list is empty on the morning of a launch. The wider ads workflow that sits on top of it starts with creative hygiene.
"Every integration that has ever gone down on me went down because something retried into a limit it had already hit. Waiting is not a fix people enjoy shipping, but it is the fix."
— Alex Onta, Executive Director, SINGUARD
Key Takeaways
- Marketing API limits apply per application over a rolling window, so one heavy report can take down every other call your integration makes.
- Scalegram reads the usage figure returned on every response and holds it as live state the scheduler checks before starting work.
- At a first threshold the sync slows down; at a higher one optional work is parked, while conversion events keep firing because they have a matching window to meet.
- Lists and searches read a local mirror rather than the live API, and the mirror's refresh time is shown rather than hidden.
Frequently Asked Questions
What happens to my conversion events if the quota runs low?
They keep going. Server side conversion events have a window in which the platform can still match them to a click, so they are treated as work that cannot be deferred. Reports and backfills are what get parked.
Why is my campaign data a few minutes old?
Because lists read from a local mirror refreshed on a schedule rather than querying the platform on every keystroke. The refresh time is shown alongside the data so you know exactly how old it is.
Can I force a full refresh whenever I want?
You can ask for one, and it will run as soon as the allowance supports it. If the guard is already in its second stage the request is queued rather than dropped, and it starts when the window resets.
About the Author
Alex Onta is an Executive Director at SINGUARD. He built eTrader, the terminal, the mobile apps, eTrader Broker, Copytrading, Business and Community, along with the worldwide clustered-server infrastructure it all runs on, with his brother Roman Onta helping on the design, and he leads that division today. Together with Roman he builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals, and the two of them carry worldwide compliance, payment processing and international business structuring side by side. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.