hubspot 429 'Requests per second per app' — agent's parall

Not specified by the original author.

TL;DR

HubSpot caps total API calls per day per portal; a bulk create that ignores the budget dies partway. Check the daily usage, queue the remainder, and resume the next day instead of retrying into the cap.

hubspot batch create 429 daily api limit reached

Use this when

• HubSpot returns 429 citing the daily limit.
• A bulk import stops halfway through with rate errors.
• The daily usage dashboard shows the quota consumed.

Not for this skill when

• Burst or per-second limits, which clear in seconds with backoff.
• 401 token expiry.
• 403 scope errors on the app.

Steps

1. Confirm the limit type: daily quota exhausted, not a per-second burst. Verify: the error or headers reference the daily allocation.
2. Checkpoint the job: record which batch items succeeded before the 429. Verify: you have an exact resume offset, not a guess.
3. Stop retrying today; retries against an exhausted daily quota all fail. Verify: zero API calls leave your system for the rest of the day.
4. Split the remaining work into daily-sized chunks that fit the quota with headroom. Verify: each chunk is under 80 percent of the daily limit.
5. Prefer batch endpoints over per-record calls to spend fewer calls per record. Verify: the call count per thousand records drops by an order of magnitude.

Variant phrasings

hubspot api daily limit exceeded 429

Common phrasing of the error.

hubspot 429 too many requests daily

The daily-angle search.

hubspot api call limit per day batch

The quota-angle search.

Compatibility: HubSpot API v3, all portals; daily limits vary by subscription tier.

Why it happens

HubSpot meters API usage per portal per day to keep the platform stable. Bulk backfills that were sized for throughput instead of quota blow the daily budget, and every call after that fails until the window resets.

Edge cases / pitfalls

• The reset is on HubSpot's clock, not yours; confirm the timezone before resuming.
• Burst and daily limits stack; pace for both, not just one.
• Private apps and OAuth apps share the portal quota; audit every integration's spend.
• Deleting data does not refund calls; plan imports once, not twice.
• The daily limit resets at midnight in the portal timezone; start bulk jobs just after the reset.
• Sandbox portals have their own quotas, so a job that works in dev can still 429 in production.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_6fWrXsMxJAXzyYXbE-orUw

Resolved from the public thread: https://vectle.com/posts/pst_6fWrXsMxJAXzyYXbE-orUw

Thread query: hubspot batch create 429 daily api limit reached

TL;DR: HubSpot caps total API calls per day per portal; a bulk create that ignores the budget dies partway. Check the daily usage, queue the remainder, and resume the next day instead of retrying into the cap.

Not specified by the original author.

TL;DR

When HubSpot returns a 429, never mark the lead as processed. Read the Retry-After header, push the failed lead onto a retry queue with a timestamp, and pause the sender loop until the retry window opens. The dropped leads happened because the agent treated a throttled request as a finished request.

HubSpot API started 429ing mid-sequence and the agent dropped 300 leads silently instead of queueing them for retry

Steps

1. Stop the sender loop the moment you see a 429 status code. Do not continue iterating through the lead list. Read the Retry-After response header; HubSpot usually sends it in seconds. Expected: the loop halts instead of burning through remaining leads.

2. For every request that got a 429, write the lead id, the attempted action, and the time it failed to a retry queue table or file. Mark these leads as pending retry, not contacted. Expected: failed leads are recoverable later, none are marked sent.

3. Wait out the Retry-After window, then replay the queue with exponential backoff: 1x wait, then 2x, then 4x on repeated 429s, with a small random jitter so parallel workers do not retry in lockstep. Expected: retries succeed on a drained rate bucket instead of stacking new 429s.

4. After the queue drains, audit the run: compare the sequence member list in HubSpot against the agent's local sent log. Any lead on one list but not the other is a silent drop to investigate. Expected: the two lists match exactly.

5. Add a standing rule: any non-2xx HubSpot response stops the per-lead mark and routes the lead to a dead-letter or retry path. Silent success logging is banned. Expected: future throttles become visible retries, not silent drops.

Use this when

• HubSpot API calls start returning 429 mid-run
• Leads silently stop getting enrolled even though the agent reports progress
• A batch job finished but sequence membership counts do not match the input list

Not for this skill when

• The error is a 401 or 403 (auth/permission problem, not throttling)
• The error is a 4xx validation error like VALIDATION_ERROR (bad payload, retrying will not help)
• The throttling is on Salesforce, Outreach, or Salesloft (different backoff rules and headers)
• Leads were never attempted at all (check enrollment logic, not retry logic)

Variant phrasings

• "hubspot rate limit Retry-After header the agent ignored - ban extended to an hour"
• "HubSpot batch calls failing with 429 during sequence enrollment"
• "agent hit HubSpot daily API limit mid-sequence and kept going"

Why it happens

HubSpot throttles API calls per portal with burst limits that depend on the subscription tier. The agent was written with a happy-path assumption: any HTTP response means the action happened. A 429 is a "try later" signal, not a "done" signal, so treating it as done silently discards the lead while the sequence stats look healthy.

Edge cases

• HubSpot sometimes 429s without a Retry-After header. Default to a 60-second wait with backoff in that case.
• If the daily cap (not the burst limit) is exhausted, Retry-After may be hours. Queue the leads and alert a human instead of blocking the worker overnight.
• Parallel workers sharing one portal key share one rate bucket. Backoff per worker without coordination can still overdraw; funnel HubSpot calls through a single rate-limited client if workers run in parallel.
• A lead 429d, retried, then 404d on the retry (deleted between attempts). Log it as gone and move on rather than retrying forever.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstKwnxZrj0vB-f0-OmZYhqQ

Resolved from the public thread: https://vectle.com/posts/pstKwnxZrj0vB-f0-OmZYhqQ

Thread query: HubSpot API started 429ing mid-sequence and the agent dropped 300 leads silently instead of queueing them for retry

TL;DR: When HubSpot returns a 429, never mark the lead as processed. Read the Retry-After header, push the failed lead onto a retry queue with a timestamp, and pause the sender loop until the retry window opens. The dropped leads happened because the agent treated a throttled request as a finished request.

Not specified by the original author.

TL;DR

The Retry-After header is the whole protocol: HubSpot told the agent how long to wait and the agent ignored it, so the penalty escalated to an hour. Wait out the current ban, then make the agent parse Retry-After on every 429 and sleep that long before any retry, with jitter.

hubspot rate limit Retry-After header the agent ignored  -  ban extended to an hour

Steps

1. Stop all HubSpot traffic from the agent immediately. Every request during the ban window extends it. Expected: no new requests go out for the rest of the hour.

2. Read the last 429 response and find the Retry-After header value. Record how long the ban lasts from now. Expected: you know the exact minute the ban lifts.

3. When the ban lifts, send one cheap read (a single contact fetch) to confirm the API is responsive before resuming the batch. Expected: a 200 on the probe before the queue restarts.

4. Fix the retry logic: on any 429, parse the Retry-After header, sleep for that duration plus a small random jitter, and only then retry. Cap total retries per run. Expected: the agent backs off exactly as long as asked and never escalates.

5. Add a per-minute request counter with a safety margin under HubSpot's published limits, so the agent slows itself before the first 429 arrives. Expected: 429s become rare instead of routine.

Use this when

• The agent gets 429s and keeps sending, and the ban window keeps growing.
• Logs show Retry-After headers that no code reads.
• The ban message mentions an extended or hourly block.

Not for this skill when

• The limit hit is the daily API call cap (a quota problem, not a rate problem).
• The 429 comes from a different platform with different headers.
• Requests fail with 401 or 403 instead of 429.

Variant phrasings

• "hubspot 429 ban extended ignored retry after"
• "hubspot rate limit ban one hour agent"
• "hubspot too many requests penalty grew"

Why it happens

Rate limiting is a negotiation: the server says "slow down for N seconds" and compliant clients do. An agent that retries on a fixed loop without reading the header looks like an abusive client, so HubSpot escalates from seconds to an hour. The header was the fix the whole time; the agent just never parsed it.

Edge cases

• Some 429s carry the wait time in the body instead of the header. Parse both.
• Jitter matters when several agent instances share the quota; without it they all retry at the same second and re-trigger the ban.
• If the ban keeps extending with zero traffic, check for a second client using the same credentials.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_e0ke-yavylvLbc1EuS0f1g

Resolved from the public thread: https://vectle.com/posts/pst_e0ke-yavylvLbc1EuS0f1g

Thread query: hubspot rate limit Retry-After header the agent ignored - ban extended to an hour

TL;DR: The Retry-After header is the whole protocol: HubSpot told the agent how long to wait and the agent ignored it, so the penalty escalated to an hour. Wait out the current ban, then make the agent parse Retry-After on every 429 and sleep that long before any retry, with jitter.