Über die Rate-Limits pro Minute hinaus haben manche Aktionen des Connectors eine Obergrenze pro Tag. Mit einem Plan haben Zählungen und Suchzeilen keine. In der Testphase und bei Pay as you go werden sie für das ganze Konto gezählt, alle Keys und der Connector zusammen (1.000 Zählungen und 1.000 Suchzeilen pro Tag über einen KI-Assistenten); Freischaltungen und Exportzeilen werden pro Key gezählt. Eine erreichte Grenze gibt HTTP 429 mit einer strukturierten Antwort zurück:
{
"error": "mcp_quota_exceeded",
"action": "preview_rows",
"daily_limit": 1000,
"used_today": 1000,
"requested_units": 10,
"remaining_today": 0,
"reset": "next_calendar_day",
"scope": "account"
}So liest du es
- action: Kontingente gelten pro Aktion, aufgebrauchte Freischaltungen blockieren also keine Zählungen.
- requested_units: Ein Aufruf, der 50 Zeilen will, kostet 50 Einheiten, nicht eine. Deshalb schont Bündeln das Kontingent mehr als Schleifen.
- remaining_today: was für diese Aktion gerade noch übrig ist.
- reset: der nächste Kalendertag. Es gibt nichts zu klicken und nichts erneut zu versuchen.
Mit der Antwort kommt ein Header Retry-After, ein ordentlicher Client kann sich also ohne Raten neu einplanen.
Was du tust
- Halte den Lauf sauber an und melde, was übrig ist, statt gegen die Wand zu wiederholen.
- Bündle. Ein Export mit 1.000 Zeilen ist ein Auftrag; tausend einzelne Freischaltungen sind tausend Anfragen und tausend Einheiten.
- Prüfe in Batches mit bis zu 500 Adressen pro Aufruf.
- Wenn du die Tagesgrenze regelmäßig erreichst, ist die Lösung eine höhere Stufe, keine klügere Wiederholungsschleife.
Alles schon Erstellte bleibt deins. Berechnete Exporte bleiben herunterladbar, und freigeschaltete Kontakte bleiben freigeschaltet. Ein Stopp durch das Kontingent kostet dich also nie fertige Arbeit.
Der Account-Endpunkt meldet deinen Stand, bevor du anfängst. Für einen Agenten ist es höflich, das zu Beginn eines langen Laufs zu prüfen:
npx argorant whoami