Collection limits

Affiliate networks put a ceiling on how hard anyone may hit them. When we go over it the network stops answering, and collection for every account on that network degrades at once — reports come back empty, or the integration can't even sign in.

Collection limits are how you cap the pace we collect at, per network and per program, without waiting for a release. Use them the moment a network starts refusing us.

They are not an error state. A run that waits its turn is the limit doing its job; nothing about it is flagged as a problem.

Where the limits live

Two screens, three groups of limits. All three use the same four fields.

Screen	Group	What it does
Network → Integration → Limits	Network-wide	One budget shared by every program on the network
Network → Integration → Limits	Default per program	Applied to each program separately, not shared between them
Program → Integration → Limits	This program	Overrides the network's per-program default, for this program only

"Program" here means an affiliate program — the thing a network runs and that holds one or more brands. Limits are set per program, not per brand.

Network-wide and per-program both apply. They aren't alternatives and there is no switch between them: a run has to satisfy the network's shared budget and whatever applies to its own program. Setting one does not turn the other off.

The four fields

Max runs at once — how many runs may be executing simultaneously in this scope. Leave it empty for no limit.

Rate limit — a run count and a window, e.g. 3 runs per 15 minutes. This is a pair: a count with no window, or a window with no count, does nothing at all, so the screen won't let you save half of one. The window's length matters as much as the count — see Windows over 50 minutes.

Retry delay — how long a run that got held back waits before trying again. Leave it empty for the system default of 30 seconds. (A run held back by the rate limit ignores this and waits for the window to refill.)

Empty means unlimited, and so does a typed 0 — the screen clears a 0 back to empty so the two don't look like different settings. Negative numbers aren't accepted; a -1 would read as a real limit and isn't one.

Will this limit keep up?

A rate limit that looks reasonable can be quietly impossible. 5 runs per hour is a sensible-looking number and cannot service a network whose 13 accounts all collect at 11am — eight of them get pushed back every morning, forever, and you find out days later from missing data.

So as you type a run count and a window, the screen checks the number against the accounts actually in scope and tells you what it will do. It is a calculator, not a validation: it never blocks a save, and nothing it says is styled as an error.

It shows how many accounts are in scope, how many collections a day they need, how many the limit allows, and — the figure that matters most — the busiest moment: how many accounts fall due inside a single window, and when.

Three verdicts, because they have different fixes:

Verdict	What it means	What to do
Keeps up	The limit services the accounts with room to spare	Nothing
Too many at once	The daily total is fine, but too many accounts collect at the same time of day	Raise the limit, or stagger when those accounts collect
Cannot keep up	More accounts than this limit can ever collect in a day	The limit has to go up

When a limit falls short, the screen names the smallest one that clears the busiest window, and Use n fills it in for you. That number satisfies the peak, not the daily average — which is the whole point, because a limit sized to the average is exactly what defers a pile every morning.

When it stays quiet

Half a rate limit. A count with no window (or the reverse) does nothing at all, so there is no configuration to check. Fill in both halves.
No limit. An empty or 0 run count means unlimited; there is nothing to test.
No accounts. A network or program with nothing collecting yet says so, rather than reporting a green light for an empty estate.
While creating a settings row. The check runs against a saved row. Save first, then reopen the Limits tab to try numbers.

Windows over 50 minutes

Accounts that share a collection time are automatically nudged apart by up to 50 minutes, so they don't all hit the network in the same instant.

That spreading is the reason a window's length matters as much as the run count. Up to 50 minutes, spreading can move accounts out of a full window. Beyond it, spreading has nowhere left to move them — every account sharing a daily schedule lands inside the same window however well it is spread. If more accounts fall due than the limit allows, the surplus is pushed back every day, indefinitely.

A longer window reads as more generous and is not. A short window — 10 or 15 minutes — is almost always the better choice, because it paces the network just as well and leaves the spreading room to work.

Setting limits on a network

Open the network, go to Integration, and edit its integration settings.
Open the Limits tab.
Under Network-wide, set the shared budget. Prefer a short window — for a network that has started refusing us, 1 run per 15 minutes is a reasonable first cap.
Check what the screen says about it, and take the suggested number if it says the limit can't keep up.
Save.

Every program on that network now collects within that budget. Their own screens show the numbers they inherit.

Tightening one busy program

Set Default per program on the network when you want the same ceiling on each program. Override a single program only when that one needs a tighter cap than the rest.

Open the program, go to Integration → Limits.
Fill in only the fields you want to change. Anything you leave empty keeps showing the number it inherits, and keeps inheriting it.
Save.

A program can only tighten, never loosen

A program's share is carved out of the network's shared budget, never added to it. If you enter a number looser than the network-wide cap, the screen tells you it will have no effect — it saves, it just won't raise anything. To give a program more room, raise the network-wide limit.

Inherited vs set

An empty field on a program shows the inherited number greyed out, with a note saying where it came from. That's deliberate: an empty box would otherwise read as "unlimited" when it actually means "whatever the network says".

If the program's network has no integration settings row at all, the screen says no network default instead — there is nothing to inherit, which is a different statement from "unlimited".

Common tasks

A network started refusing us and collection is failing. Set a network-wide rate limit over a short window — a run or two every 15 minutes — confirm collection recovers, then relax it in steps.

One program is eating the whole network budget. Set Default per program on the network so no single program can take it all, or set an override on the busy program.

I set a rate limit and nothing changed. Check both halves are filled in. A run count with no window does nothing, which is why the screen blocks saving one.

I set a long window and accounts stopped collecting. Two different things go wrong with long windows. Past 50 minutes, spreading can no longer relieve a full window, so a pile defers every day — see above. Past 24 hours, the window is longer than the collection cadence and starves accounts between runs; the screen warns about that one too. Either way, shorten it.

The screen says my limit can't keep up. Take the number it suggests, or leave the limit alone and stagger the accounts' collection times instead. Both work; raising the limit is the faster of the two.

I want to remove a program's override. Clear every field in its Limits tab and save. The program goes back to inheriting the network's per-program default.

When to escalate to engineering

Collection still fails with limits set conservatively — the network may be blocking us for a reason other than pace.
A limit you saved isn't reflected in what the program's screen shows after a reload.
You need a limit on something these two screens don't cover.