|
4371
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Share chat
Claude finished the response
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
how to work with multiple jobs
how to work with paginated requests Let's consider a situation when there are 600 opportunities to sync. What would be the flow? How would the rate limit be recognized? How would it be handled? What are the potential issues? [API usage guidelines and limits - HubSpot docs](
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
). Example of such a error Client error:
POST https://api.hubapi.com/crm/v3/objects/contact/search
resulted in a
429 Too Many Requests
response: {"status":"error","message":"You have reached your secondly limit.","errorType":"RATE_LIMIT","correlationId":"019dffc4-4 (truncated...). Think carefully about the implementation and potential issue and bottlenecks.
Show more
10:42
Retry
Edit
Copy
Claude responded: Current HubSpot limits (Apr 2026)
Claude responded: Current HubSpot limits (Apr 2026)
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Current HubSpot limits (Apr 2026)
Current HubSpot limits (Apr 2026)
For privately distributed apps (which is what Jiminny presumably uses with HubSpot), the limits are layered: a per-app burst window of 100/10s on Free/Starter, 190/10s on Pro/Enterprise, or 250/10s with the API Limit Increase add-on
, plus a per-account daily cap of 250k / 625k / 1M depending on tier β shared across all private apps in the account
. The burst window is per app; the daily quota is per portal.
hubspot
hubspot
hubspot
hubspot
The Search API is special: five requests per second per account, capped at 200 records per page, with a hard 10,000-result ceiling per query
. That's the limit the 429 in your example is hitting (
secondly limit
on
/crm/v3/objects/contact/search
). It's a separate bucket from the 190/10s, and critically, search responses do not include the
X-HubSpot-RateLimit-*
headers
β you can't read remaining capacity off the response, you have to track it yourself.
hubspot
hubspot
hubspot
hubspot
Non-search endpoints return
X-HubSpot-RateLimit-Remaining
,
-Max
, and
-Interval-Milliseconds
. The daily headers are not returned for OAuth-authenticated calls
, so for those you check the account-info endpoint or maintain your own counter. There's also a soft rule: errors should stay under 5% of total daily requests
β that's enforced for marketplace listing, but it's also a sane operational target.
hubspot
hubspot
hubspot
hubspot
So you have
four buckets
to track at minimum: app-burst (10s sliding), search-secondly (1s sliding), account-daily (24h fixed, midnight in HubSpot's TZ), and per-app daily share (your own budgeting on top of the account cap).
Where to store it
Where to store it
Redis. It's the only realistic option once you have multiple queue workers β DB-backed counters serialize too much, and in-process state can't coordinate across workers. Laravel already speaks Redis natively, and you get atomic
INCR
/
EXPIRE
plus Lua scripting for true CAS semantics.
Key layout I'd use:
Copy to clipboard
hubspot:rl:burst:{portalId}:{appId} ZSET (sliding 10s)
hubspot:rl:search:{portalId} ZSET (sliding 1s)
hubspot:rl:daily:{portalId} STRING + TTL to midnight TZ
hubspot:rl:meta:{portalId} HASH (last seen headers)
The two short-window buckets are sliding-window-log (Redis ZSET, score =
microtime
, member = unique request id). Lua script removes entries older than the window, counts remaining slots, and only adds the new one if there's room β all atomic. Fixed windows are simpler but allow 2Γ the limit at the boundary, which on a 5/s window is brutal.
The daily bucket is a plain
INCR
with TTL set to seconds-until-midnight in
HubSpot's account timezone
, not yours β Sofia is UTC+2/+3 but your portal might be set to US Eastern. Get this once and cache it.
How to read it
How to read it
Two-phase: optimistic pre-check, authoritative post-update.
Before a call, run the Lua acquire script. If it returns "denied," sleep until a slot frees up (the script can return ms-until-next-slot) or push the job back to the queue with a delay. Don't busy-loop.
After the call, parse
X-HubSpot-RateLimit-Remaining
/
-Max
/
-Interval-Milliseconds
and store them in
hubspot:rl:meta:{portalId}
. This is your reality check β if your local counter says 50 remaining but HubSpot's header says 5, you trust HubSpot and clamp your counter. This handles clock drift, missed accounting (e.g., crashed worker that took a token but never made the request), and other apps in the same account consuming the daily budget invisibly.
For search specifically, since headers don't come back, the local counter
is
the source of truth β meaning if you ever crash mid-flight, you've under-counted. Always release tokens on connection-level failure but
not
on 429 (you really did make that request).
How to work with multiple jobs
How to work with multiple jobs
The queue layer needs to enforce concurrency separately from the rate limiter. Both work together:
Concurrency cap
via
Queue::throttle()
or a Redis semaphore β limits how many sync workers run in parallel against HubSpot. Without this, you can have 50 workers all blocked waiting for tokens, which is wasteful and creates retry storms.
Per-tenant fairness
β if you sync many Jiminny customers into different HubSpot portals, each portal has its own bucket but you still want one slow portal not to starve others. Either separate queues per portal or a fair-share scheduler.
Priority lanes
β webhook-driven updates (user-visible latency) should outrank background batch syncs. Two queues:
hubspot-priority
and
hubspot-bulk
, with priority workers taking 70% of the burst budget and bulk taking 30% (enforce via separate sub-buckets if you really want hard separation, otherwise just pull from priority first).
Backoff on 429
β respect the
Retry-After
header. If absent, exponential with jitter (e.g.,
min(2^attempt * 250ms, 30s) Β± 20%
). The jitter is non-negotiable; without it, simultaneous 429s retry in lockstep and you get thundering-herd 429s on retry.
How to work with paginated requests
How to work with paginated requests
The trap is treating "fetch all" as one logical operation. Each page is its own API call and competes for tokens with everything else.
Two practical rules:
Don't hold the worker idle while paginating.
If page N takes 500ms and page N+1 needs to wait 800ms for a token, you've burned 800ms of worker time doing nothing. Instead, fetch page N, dispatch the
processing
of page N as a separate job, and queue a "fetch page N+1" job with a delay equal to the wait time. Each page becomes its own atomic unit.
Always batch where HubSpot offers it.
POST /crm/v3/objects/{type}/batch/{read|update|create}
accepts up to 100 IDs per call. For your "patching IDs" flow this is the difference between 600 calls and 6.
Walkthrough: 600 opportunities
Walkthrough: 600 opportunities
Naive flow (one PATCH per deal): 600 calls. At 190/10s that's ~32s of API time, well under daily. You'd hit burst easily without throttling. Plus likely 1-3 search calls upfront and N association calls.
Sane flow:
Identify deltas
β if you can avoid Search at all, do. Use
lastmodifieddate
filter on a single search if you must, paginate at limit=200. For 600 deals that's 3 search calls @ 5/s = ~600ms naturally throttled.
Batch read
current state β
POST /crm/v3/objects/deals/batch/read
with 100 IDs per call β 6 calls. Burst weight 6.
Compute diff
in your code (no API).
Batch update
β
POST /crm/v3/objects/deals/batch/update
with 100 per call β 6 calls.
Associations
β
POST /crm/v4/associations/{from}/{to}/batch/create
if needed β another few batch calls.
Total: ~15-20 API calls for 600 deals. Burst budget consumed: 20/190 over ~5s. Daily impact: trivial.
Recognition: pre-check denies if
<weight>
slots aren't free; on 429 the response surfaces
policyName
(DAILY/SECONDLY) β log it, push the job back with
Retry-After
delay, increment a metric so you can alarm on sustained 429 rate.
Pitfalls & bottlenecks worth pre-empting
Pitfalls & bottlenecks worth pre-empting
Daily quota is shared across the whole portal
, including any n8n flows, other private apps, marketing automation calling APIs, etc. Budget for ~70-80% of the documented limit, not 100%. Add an internal per-app daily cap so a runaway sync can't starve other apps.
Search is uniquely fragile
: separate 5/s bucket, no headers to read, 10k-result cap per query. If you ever hit 10k+ deals matching a filter, partition by
hs_object_id
ranges or by
lastmodifieddate
windows.
Retry storms after HubSpot incidents
β always jitter, always cap total retries (e.g., 5 attempts, then dead-letter).
Webhook β sync β webhook loops
β when your update fires a HubSpot webhook that triggers another sync. Tag your own writes (e.g., a custom property
jy_last_sync_id
) and ignore webhooks where it just changed.
Token refresh
β OAuth refresh itself counts against burst. Cache the access token in Redis with TTL =
expires_in - 60s
, single-flight the refresh (only one worker refreshes; others wait on a lock).
Search latency for fresh writes
β newly created/updated objects don't appear in search instantly. Don't write-then-search; use returned IDs directly.
Clock skew
β Redis is authoritative. Don't use
time()
from each worker for window scoring; use
redis.call('TIME')
inside the Lua script.
Dead workers with held tokens
β sliding-window-log handles this naturally because tokens expire by score; token-bucket implementations need explicit release-on-crash logic.
The 5% error rule
counts every 429 toward your error budget, even successfully retried ones. If your pre-check is working well, 429s should be near zero β if they're not, your pre-check is wrong, not just slow.
Phantom contention with Laravel
RateLimited
middleware
: it's per-job-class by default, not per-portal. If your
SyncDealJob
and
UpdateActivityJob
are different classes both calling HubSpot, they don't share a Laravel-level limiter β you need a single
HubspotRateLimiter
service that everything routes through.
If you want, I can sketch the Lua script for the sliding-window acquire and the Laravel service wrapper around it.
Copy
Give positive feedback
Give negative feedback
Retry
You said: What will happen if there are two different types of rate limits?
You said: What will happen if there are two different types of rate limits?
What will happen if there are two different types of rate limits?
Search requests that have 5 requests per second
The other rate limit that has, let's say, 100 requests per 10 seconds How do these work together? Is there some conflict? Can I reach the limit with one request and block either as well, or are these separated? Can I still continue making search requests once I hit the normal requests limits?
13:40
Retry
Edit
Copy
Claude responded: They're independent buckets β with one shared bucket on top.
Claude responded: They're independent buckets β with one shared bucket on top.
Analyzed independent rate limit buckets and their practical interactions
Analyzed independent rate limit buckets and their practical interactions
They're independent buckets β with one shared bucket on top.
The three buckets and what each call hits
The three buckets and what each call hits
Copy to clipboard
ββββββββββββββββββββ
Search request βββ β Search: 5/sec β βββ
ββββββββββββββββββββ β
ββββ βββββββββββββββββββ
ββββββββββββββββββββ β β Daily: 250kβ1M β
Non-search call βββ β Burst: 190/10s β βββ β (per portal) β
ββββββββββββββββββββ βββββββββββββββββββ
A search call is only metered against the search bucket and the daily bucket. A non-search call (batch read/update, single PATCH, associations, etc.) is only metered against the burst bucket and the daily bucket. The two short-window buckets do not share counters.
What this means practically
What this means practically
Hitting search secondly limit (5/s):
Only further
/search
calls 429. Your batch reads, batch updates, single PATCHes, association calls β all keep working at full burst speed. This is actually useful: if your sync is bottlenecked on Search, you can pivot to using
lastmodifieddate
filters via batch endpoints, or use the IDs you already have to do batch reads, while Search cools off.
Hitting burst limit (190/10s):
Only non-search calls 429. You can still issue Search calls at 5/s. Useful for: continuing to identify deltas for queueing while in-flight updates drain, or refreshing a small set of records via Search even though your write pipeline is paused.
Hitting daily limit:
Everything stops. Search and non-search alike. Doesn't unblock until midnight in your portal's configured timezone β and remember this is shared across every private app in the portal, plus n8n flows, marketing tools, anything else hitting the API with that account.
So can one type of request block the other?
So can one type of request block the other?
Search β Burst:
No.
Saturating Search at 50 calls per 10s leaves your full 190/10s burst untouched.
Burst β Search:
No.
Saturating burst leaves Search's 5/s untouched.
Either β Daily:
Yes
, but only by contributing to the same daily counter. It's volume that kills you here, not the type.
In theory you can sustain ~50 search + ~190 other =
~240 calls per 10 seconds
indefinitely (until daily runs out), because the two buckets bill independently.
Implementation consequence
Implementation consequence
Your rate limiter needs to know which bucket a request hits before it acquires. Cleanest pattern:
Copy to clipboard
php
$limiter
->
acquire
(
'search'
,
$weight
=
1
)
;
// for search endpoints only
$limiter
->
acquire
(
'burst'
,
$weight
=
1
)
;
// for everything else
$limiter
->
acquire
(
'daily'
,
$weight
=
1
)
;
// every call, both kinds
In Redis: three separate keys, three separate Lua acquire scripts (or one script with a bucket parameter). A search call calls
acquire('search')
+
acquire('daily')
. A batch update calls
acquire('burst')
+
acquire('daily')
.
One subtle pitfall: when you backoff on a 429,
inspect
policyName
in the response body
to know which bucket actually fired. If you see
SECONDLY
from a search endpoint, you only need to delay search-bound jobs β burst-bound jobs in the queue can keep running. If you blanket-pause everything on any 429, you waste capacity on the bucket that's still healthy. Two queues (or two throttle keys) make this clean; one global pause is the lazy version.
The other subtlety: the burst response gives you
X-HubSpot-RateLimit-Remaining
to clamp local state against, but search doesn't return those headers. So your search counter is unverified β be slightly more conservative there (e.g., budget 4/s instead of 5) to absorb the unaccounted-for calls.
Copy
Give positive feedback
Give negative feedback
Retry
You said: Ok, so what will happen each time I make a request?
You said: Ok, so what will happen each time I make a request?
Ok, so what will happen each time I make a request? Let's say I have 100,000 requests to make that are instant. Do I need to increment each request based on the type? For example, if there is a search request, I need to increment both the search bucket and also the daily bucket. If it's a burst, then I can go to the daily and burst buckets. If I need to check if it can make a call, do I need to see both the daily and search, or burst, respectively? Isn't that too heavy for the infrastructure, adding additional load to each request?
13:44
Retry
Edit
Copy
Claude responded: Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out.
Claude responded: Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out.
Analyzed per-request overhead concerns and quantified Redis performance impact
Analyzed per-request overhead concerns and quantified Redis performance impact
Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out. But the overhead is much smaller than it sounds, and importantly, it's nowhere near your bottleneck.
What "two buckets per request" actually costs
What "two buckets per request" actually costs
Each request makes
one round trip to Redis
β not two β because you fold both bucket checks into a single Lua script that runs atomically server-side:
Copy to clipboard
lua
-- KEYS[1] = burst bucket key (or search)
-- KEYS[2] = daily bucket key
-- ARGV[1] = now (ms) ARGV[2] = window_ms
-- ARGV[3] = bucket_max ARGV[4] = daily_max
-- ARGV[5] = request_id ARGV[6] = daily_ttl
-- Trim sliding window
redis
.
call
(
'ZREMRANGEBYSCORE'
,
KEYS
[
1
]
,
0
,
ARGV
[
1
]
-
ARGV
[
2
]
)
local
burst_used
=
redis
.
call
(
'ZCARD'
,
KEYS
[
1
]
)
local
daily_used
=
tonumber
(
redis
.
call
(
'GET'
,
KEYS
[
2
]
)
or
'0'
)
if
burst_used
>=...
|
Claude
|
Claude
|
NULL
|
4371
|
|
4370
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Share chat
Claude finished the response
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
how to work with multiple jobs
how to work with paginated requests Let's consider a situation when there are 600 opportunities to sync. What would be the flow? How would the rate limit be recognized? How would it be handled? What are the potential issues? [API usage guidelines and limits - HubSpot docs](
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
). Example of such a error Client error:
POST https://api.hubapi.com/crm/v3/objects/contact/search
resulted in a
429 Too Many Requests
response: {"status":"error","message":"You have reached your secondly limit.","errorType":"RATE_LIMIT","correlationId":"019dffc4-4 (truncated...). Think carefully about the implementation and potential issue and bottlenecks.
Show more
10:42
Retry
Edit
Copy
Claude responded: Current HubSpot limits (Apr 2026)
Claude responded: Current HubSpot limits (Apr 2026)
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Current HubSpot limits (Apr 2026)
Current HubSpot limits (Apr 2026)
For privately distributed apps (which is what Jiminny presumably uses with HubSpot), the limits are layered: a per-app burst window of 100/10s on Free/Starter, 190/10s on Pro/Enterprise, or 250/10s with the API Limit Increase add-on
, plus a per-account daily cap of 250k / 625k / 1M depending on tier β shared across all private apps in the account
. The burst window is per app; the daily quota is per portal.
hubspot
hubspot
hubspot
hubspot
The Search API is special: five requests per second per account, capped at 200 records per page, with a hard 10,000-result ceiling per query
. That's the limit the 429 in your example is hitting (
secondly limit
on
/crm/v3/objects/contact/search
). It's a separate bucket from the 190/10s, and critically, search responses do not include the
X-HubSpot-RateLimit-*
headers
β you can't read remaining capacity off the response, you have to track it yourself.
hubspot
hubspot
hubspot
hubspot
Non-search endpoints return
X-HubSpot-RateLimit-Remaining
,
-Max
, and
-Interval-Milliseconds
. The daily headers are not returned for OAuth-authenticated calls
, so for those you check the account-info endpoint or maintain your own counter. There's also a soft rule: errors should stay under 5% of total daily requests
β that's enforced for marketplace listing, but it's also a sane operational target.
hubspot
hubspot
hubspot
hubspot
So you have
four buckets
to track at minimum: app-burst (10s sliding), search-secondly (1s sliding), account-daily (24h fixed, midnight in HubSpot's TZ), and per-app daily share (your own budgeting on top of the account cap).
Where to store it
Where to store it
Redis. It's the only realistic option once you have multiple queue workers β DB-backed counters serialize too much, and in-process state can't coordinate across workers. Laravel already speaks Redis natively, and you get atomic
INCR
/
EXPIRE
plus Lua scripting for true CAS semantics.
Key layout I'd use:
Copy to clipboard
hubspot:rl:burst:{portalId}:{appId} ZSET (sliding 10s)
hubspot:rl:search:{portalId} ZSET (sliding 1s)
hubspot:rl:daily:{portalId} STRING + TTL to midnight TZ
hubspot:rl:meta:{portalId} HASH (last seen headers)
The two short-window buckets are sliding-window-log (Redis ZSET, score =
microtime
, member = unique request id). Lua script removes entries older than the window, counts remaining slots, and only adds the new one if there's room β all atomic. Fixed windows are simpler but allow 2Γ the limit at the boundary, which on a 5/s window is brutal.
The daily bucket is a plain
INCR
with TTL set to seconds-until-midnight in
HubSpot's account timezone
, not yours β Sofia is UTC+2/+3 but your portal might be set to US Eastern. Get this once and cache it.
How to read it
How to read it
Two-phase: optimistic pre-check, authoritative post-update.
Before a call, run the Lua acquire script. If it returns "denied," sleep until a slot frees up (the script can return ms-until-next-slot) or push the job back to the queue with a delay. Don't busy-loop.
After the call, parse
X-HubSpot-RateLimit-Remaining
/
-Max
/
-Interval-Milliseconds
and store them in
hubspot:rl:meta:{portalId}
. This is your reality check β if your local counter says 50 remaining but HubSpot's header says 5, you trust HubSpot and clamp your counter. This handles clock drift, missed accounting (e.g., crashed worker that took a token but never made the request), and other apps in the same account consuming the daily budget invisibly.
For search specifically, since headers don't come back, the local counter
is
the source of truth β meaning if you ever crash mid-flight, you've under-counted. Always release tokens on connection-level failure but
not
on 429 (you really did make that request).
How to work with multiple jobs
How to work with multiple jobs
The queue layer needs to enforce concurrency separately from the rate limiter. Both work together:
Concurrency cap
via
Queue::throttle()
or a Redis semaphore β limits how many sync workers run in parallel against HubSpot. Without this, you can have 50 workers all blocked waiting for tokens, which is wasteful and creates retry storms.
Per-tenant fairness
β if you sync many Jiminny customers into different HubSpot portals, each portal has its own bucket but you still want one slow portal not to starve others. Either separate queues per portal or a fair-share scheduler.
Priority lanes
β webhook-driven updates (user-visible latency) should outrank background batch syncs. Two queues:
hubspot-priority
and
hubspot-bulk
, with priority workers taking 70% of the burst budget and bulk taking 30% (enforce via separate sub-buckets if you really want hard separation, otherwise just pull from priority first).
Backoff on 429
β respect the
Retry-After
header. If absent, exponential with jitter (e.g.,
min(2^attempt * 250ms, 30s) Β± 20%
). The jitter is non-negotiable; without it, simultaneous 429s retry in lockstep and you get thundering-herd 429s on retry.
How to work with paginated requests
How to work with paginated requests
The trap is treating "fetch all" as one logical operation. Each page is its own API call and competes for tokens with everything else.
Two practical rules:
Don't hold the worker idle while paginating.
If page N takes 500ms and page N+1 needs to wait 800ms for a token, you've burned 800ms of worker time doing nothing. Instead, fetch page N, dispatch the
processing
of page N as a separate job, and queue a "fetch page N+1" job with a delay equal to the wait time. Each page becomes its own atomic unit.
Always batch where HubSpot offers it.
POST /crm/v3/objects/{type}/batch/{read|update|create}
accepts up to 100 IDs per call. For your "patching IDs" flow this is the difference between 600 calls and 6.
Walkthrough: 600 opportunities
Walkthrough: 600 opportunities
Naive flow (one PATCH per deal): 600 calls. At 190/10s that's ~32s of API time, well under daily. You'd hit burst easily without throttling. Plus likely 1-3 search calls upfront and N association calls.
Sane flow:
Identify deltas
β if you can avoid Search at all, do. Use
lastmodifieddate
filter on a single search if you must, paginate at limit=200. For 600 deals that's 3 search calls @ 5/s = ~600ms naturally throttled.
Batch read
current state β
POST /crm/v3/objects/deals/batch/read
with 100 IDs per call β 6 calls. Burst weight 6.
Compute diff
in your code (no API).
Batch update
β
POST /crm/v3/objects/deals/batch/update
with 100 per call β 6 calls.
Associations
β
POST /crm/v4/associations/{from}/{to}/batch/create
if needed β another few batch calls.
Total: ~15-20 API calls for 600 deals. Burst budget consumed: 20/190 over ~5s. Daily impact: trivial.
Recognition: pre-check denies if
<weight>
slots aren't free; on 429 the response surfaces
policyName
(DAILY/SECONDLY) β log it, push the job back with
Retry-After
delay, increment a metric so you can alarm on sustained 429 rate.
Pitfalls & bottlenecks worth pre-empting
Pitfalls & bottlenecks worth pre-empting
Daily quota is shared across the whole portal
, including any n8n flows, other private apps, marketing automation calling APIs, etc. Budget for ~70-80% of the documented limit, not 100%. Add an internal per-app daily cap so a runaway sync can't starve other apps.
Search is uniquely fragile
: separate 5/s bucket, no headers to read, 10k-result cap per query. If you ever hit 10k+ deals matching a filter, partition by
hs_object_id
ranges or by
lastmodifieddate
windows.
Retry storms after HubSpot incidents
β always jitter, always cap total retries (e.g., 5 attempts, then dead-letter).
Webhook β sync β webhook loops
β when your update fires a HubSpot webhook that triggers another sync. Tag your own writes (e.g., a custom property
jy_last_sync_id
) and ignore webhooks where it just changed.
Token refresh
β OAuth refresh itself counts against burst. Cache the access token in Redis with TTL =
expires_in - 60s
, single-flight the refresh (only one worker refreshes; others wait on a lock).
Search latency for fresh writes
β newly created/updated objects don't appear in search instantly. Don't write-then-search; use returned IDs directly.
Clock skew
β Redis is authoritative. Don't use
time()
from each worker for window scoring; use
redis.call('TIME')
inside the Lua script.
Dead workers with held tokens
β sliding-window-log handles this naturally because tokens expire by score; token-bucket implementations need explicit release-on-crash logic.
The 5% error rule
counts every 429 toward your error budget, even successfully retried ones. If your pre-check is working well, 429s should be near zero β if they're not, your pre-check is wrong, not just slow.
Phantom contention with Laravel
RateLimited
middleware
: it's per-job-class by default, not per-portal. If your
SyncDealJob
and
UpdateActivityJob
are different classes both calling HubSpot, they don't share a Laravel-level limiter β you need a single
HubspotRateLimiter
service that everything routes through.
If you want, I can sketch the Lua script for the sliding-window acquire and the Laravel service wrapper around it.
Copy
Give positive feedback
Give negative feedback
Retry
You said: What will happen if there are two different types of rate limits?
You said: What will happen if there are two different types of rate limits?
What will happen if there are two different types of rate limits?
Search requests that have 5 requests per second
The other rate limit that has, let's say, 100 requests per 10 seconds How do these work together? Is there some conflict? Can I reach the limit with one request and block either as well, or are these separated? Can I still continue making search requests once I hit the normal requests limits?
13:40
Retry
Edit
Copy
Claude responded: They're independent buckets β with one shared bucket on top.
Claude responded: They're independent buckets β with one shared bucket on top.
Analyzed independent rate limit buckets and their practical interactions
Analyzed independent rate limit buckets and their practical interactions
They're independent buckets β with one shared bucket on top.
The three buckets and what each call hits
The three buckets and what each call hits
Copy to clipboard
ββββββββββββββββββββ
Search request βββ β Search: 5/sec β βββ
ββββββββββββββββββββ β
ββββ βββββββββββββββββββ
ββββββββββββββββββββ β β Daily: 250kβ1M β
Non-search call βββ β Burst: 190/10s β βββ β (per portal) β
ββββββββββββββββββββ βββββββββββββββββββ
A search call is only metered against the search bucket and the daily bucket. A non-search call (batch read/update, single PATCH, associations, etc.) is only metered against the burst bucket and the daily bucket. The two short-window buckets do not share counters.
What this means practically
What this means practically
Hitting search secondly limit (5/s):
Only further
/search
calls 429. Your batch reads, batch updates, single PATCHes, association calls β all keep working at full burst speed. This is actually useful: if your sync is bottlenecked on Search, you can pivot to using
lastmodifieddate
filters via batch endpoints, or use the IDs you already have to do batch reads, while Search cools off.
Hitting burst limit (190/10s):
Only non-search calls 429. You can still issue Search calls at 5/s. Useful for: continuing to identify deltas for queueing while in-flight updates drain, or refreshing a small set of records via Search even though your write pipeline is paused.
Hitting daily limit:
Everything stops. Search and non-search alike. Doesn't unblock until midnight in your portal's configured timezone β and remember this is shared across every private app in the portal, plus n8n flows, marketing tools, anything else hitting the API with that account.
So can one type of request block the other?
So can one type of request block the other?
Search β Burst:
No.
Saturating Search at 50 calls per 10s leaves your full 190/10s burst untouched.
Burst β Search:
No.
Saturating burst leaves Search's 5/s untouched.
Either β Daily:
Yes
, but only by contributing to the same daily counter. It's volume that kills you here, not the type.
In theory you can sustain ~50 search + ~190 other =
~240 calls per 10 seconds
indefinitely (until daily runs out), because the two buckets bill independently.
Implementation consequence
Implementation consequence
Your rate limiter needs to know which bucket a request hits before it acquires. Cleanest pattern:
Copy to clipboard
php
$limiter
->
acquire
(
'search'
,
$weight
=
1
)
;
// for search endpoints only
$limiter
->
acquire
(
'burst'
,
$weight
=
1...
|
Claude
|
Claude
|
NULL
|
4370
|
|
4369
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Share chat
Claude finished the response
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
how to work with multiple jobs
how to work with paginated requests Let's consider a situation when there are 600 opportunities to sync. What would be the flow? How would the rate limit be recognized? How would it be handled? What are the potential issues? [API usage guidelines and limits - HubSpot docs](
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
). Example of such a error Client error:
POST https://api.hubapi.com/crm/v3/objects/contact/search
resulted in a
429 Too Many Requests
response: {"status":"error","message":"You have reached your secondly limit.","errorType":"RATE_LIMIT","correlationId":"019dffc4-4 (truncated...). Think carefully about the implementation and potential issue and bottlenecks.
Show more
10:42
Retry
Edit
Copy
Claude responded: Current HubSpot limits (Apr 2026)
Claude responded: Current HubSpot limits (Apr 2026)
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Current HubSpot limits (Apr 2026)
Current HubSpot limits (Apr 2026)
For privately distributed apps (which is what Jiminny presumably uses with HubSpot), the limits are layered: a per-app burst window of 100/10s on Free/Starter, 190/10s on Pro/Enterprise, or 250/10s with the API Limit Increase add-on
, plus a per-account daily cap of 250k / 625k / 1M depending on tier β shared across all private apps in the account
. The burst window is per app; the daily quota is per portal.
hubspot
hubspot
hubspot
hubspot
The Search API is special: five requests per second per account, capped at 200 records per page, with a hard 10,000-result ceiling per query
. That's the limit the 429 in your example is hitting (
secondly limit
on
/crm/v3/objects/contact/search
). It's a separate bucket from the 190/10s, and critically, search responses do not include the
X-HubSpot-RateLimit-*
headers
β you can't read remaining capacity off the response, you have to track it yourself.
hubspot
hubspot
hubspot
hubspot
Non-search endpoints return
X-HubSpot-RateLimit-Remaining
,
-Max
, and
-Interval-Milliseconds
. The daily headers are not returned for OAuth-authenticated calls
, so for those you check the account-info endpoint or maintain your own counter. There's also a soft rule: errors should stay under 5% of total daily requests
β that's enforced for marketplace listing, but it's also a sane operational target.
hubspot
hubspot
hubspot
hubspot
So you have
four buckets
to track at minimum: app-burst (10s sliding), search-secondly (1s sliding), account-daily (24h fixed, midnight in HubSpot's TZ), and per-app daily share (your own budgeting on top of the account cap).
Where to store it
Where to store it
Redis. It's the only realistic option once you have multiple queue workers β DB-backed counters serialize too much, and in-process state can't coordinate across workers. Laravel already speaks Redis natively, and you get atomic
INCR
/
EXPIRE
plus Lua scripting for true CAS semantics.
Key layout I'd use:
Copy to clipboard
hubspot:rl:burst:{portalId}:{appId} ZSET (sliding 10s)
hubspot:rl:search:{portalId} ZSET (sliding 1s)
hubspot:rl:daily:{portalId} STRING + TTL to midnight TZ
hubspot:rl:meta:{portalId} HASH (last seen headers)
The two short-window buckets are sliding-window-log (Redis ZSET, score =
microtime
, member = unique request id). Lua script removes entries older than the window, counts remaining slots, and only adds the new one if there's room β all atomic. Fixed windows are simpler but allow 2Γ the limit at the boundary, which on a 5/s window is brutal.
The daily bucket is a plain
INCR
with TTL set to seconds-until-midnight in
HubSpot's account timezone
, not yours β Sofia is UTC+2/+3 but your portal might be set to US Eastern. Get this once and cache it.
How to read it
How to read it
Two-phase: optimistic pre-check, authoritative post-update.
Before a call, run the Lua acquire script. If it returns "denied," sleep until a slot frees up (the script can return ms-until-next-slot) or push the job back to the queue with a delay. Don't busy-loop.
After the call, parse
X-HubSpot-RateLimit-Remaining
/
-Max
/
-Interval-Milliseconds
and store them in
hubspot:rl:meta:{portalId}
. This is your reality check β if your local counter says 50 remaining but HubSpot's header says 5, you trust HubSpot and clamp your counter. This handles clock drift, missed accounting (e.g., crashed worker that took a token but never made the request), and other apps in the same account consuming the daily budget invisibly.
For search specifically, since headers don't come back, the local counter
is
the source of truth β meaning if you ever crash mid-flight, you've under-counted. Always release tokens on connection-level failure but
not
on 429 (you really did make that request).
How to work with multiple jobs
How to work with multiple jobs
The queue layer needs to enforce concurrency separately from the rate limiter. Both work together:
Concurrency cap
via
Queue::throttle()
or a Redis semaphore β limits how many sync workers run in parallel against HubSpot. Without this, you can have 50 workers all blocked waiting for tokens, which is wasteful and creates retry storms.
Per-tenant fairness
β if you sync many Jiminny customers into different HubSpot portals, each portal has its own bucket but you still want one slow portal not to starve others. Either separate queues per portal or a fair-share scheduler.
Priority lanes
β webhook-driven updates (user-visible latency) should outrank background batch syncs. Two queues:
hubspot-priority
and
hubspot-bulk
, with priority workers taking 70% of the burst budget and bulk taking 30% (enforce via separate sub-buckets if you really want hard separation, otherwise just pull from priority first).
Backoff on 429
β respect the
Retry-After
header. If absent, exponential with jitter (e.g.,
min(2^attempt * 250ms, 30s) Β± 20%
). The jitter is non-negotiable; without it, simultaneous 429s retry in lockstep and you get thundering-herd 429s on retry.
How to work with paginated requests
How to work with paginated requests
The trap is treating "fetch all" as one logical operation. Each page is its own API call and competes for tokens with everything else.
Two practical rules:
Don't hold the worker idle while paginating.
If page N takes 500ms and page N+1 needs to wait 800ms for a token, you've burned 800ms of worker time doing nothing. Instead, fetch page N, dispatch the
processing
of page N as a separate job, and queue a "fetch page N+1" job with a delay equal to the wait time. Each page becomes its own atomic unit.
Always batch where HubSpot offers it.
POST /crm/v3/objects/{type}/batch/{read|update|create}
accepts up to 100 IDs per call. For your "patching IDs" flow this is the difference between 600 calls and 6.
Walkthrough: 600 opportunities
Walkthrough: 600 opportunities
Naive flow (one PATCH per deal): 600 calls. At 190/10s that's ~32s of API time, well under daily. You'd hit burst easily without throttling. Plus likely 1-3 search calls upfront and N association calls.
Sane flow:
Identify deltas
β if you can avoid Search at all, do. Use
lastmodifieddate
filter on a single search if you must, paginate at limit=200. For 600 deals that's 3 search calls @ 5/s = ~600ms naturally throttled.
Batch read
current state β
POST /crm/v3/objects/deals/batch/read
with 100 IDs per call β 6 calls. Burst weight 6.
Compute diff
in your code (no API).
Batch update
β
POST /crm/v3/objects/deals/batch/update
with 100 per call β 6 calls.
Associations
β
POST /crm/v4/associations/{from}/{to}/batch/create
if needed β another few batch calls.
Total: ~15-20 API calls for 600 deals. Burst budget consumed: 20/190 over ~5s. Daily impact: trivial.
Recognition: pre-check denies if
<weight>
slots aren't free; on 429 the response surfaces
policyName
(DAILY/SECONDLY) β log it, push the job back with
Retry-After
delay, increment a metric so you can alarm on sustained 429 rate.
Pitfalls & bottlenecks worth pre-empting
Pitfalls & bottlenecks worth pre-empting
Daily quota is shared across the whole portal
, including any n8n flows, other private apps, marketing automation calling APIs, etc. Budget for ~70-80% of the documented limit, not 100%. Add an internal per-app daily cap so a runaway sync can't starve other apps.
Search is uniquely fragile
: separate 5/s bucket, no headers to read, 10k-result cap per query. If you ever hit 10k+ deals matching a filter, partition by
hs_object_id
ranges or by
lastmodifieddate
windows.
Retry storms after HubSpot incidents
β always jitter, always cap total retries (e.g., 5 attempts, then dead-letter).
Webhook β sync β webhook loops
β when your update fires a HubSpot webhook that triggers another sync. Tag your own writes (e.g., a custom property
jy_last_sync_id
) and ignore webhooks where it just changed.
Token refresh
β OAuth refresh itself counts against burst. Cache the access token in Redis with TTL =
expires_in - 60s
, single-flight the refresh (only one worker refreshes; others wait on a lock).
Search latency for fresh writes
β newly created/updated objects don't appear in search instantly. Don't write-then-search; use returned IDs directly.
Clock skew
β Redis is authoritative. Don't use
time()
from each worker for window scoring; use
redis.call('TIME')
inside the Lua script.
Dead workers with held tokens
β sliding-window-log handles this naturally because tokens expire by score; token-bucket implementations need explicit release-on-crash logic.
The 5% error rule
counts every 429 toward your error budget, even successfully retried ones. If your pre-check is working well, 429s should be near zero β if they're not, your pre-check is wrong, not just slow.
Phantom contention with Laravel
RateLimited
middleware
: it's per-job-class by default, not per-portal. If your
SyncDealJob
and
UpdateActivityJob
are different classes both calling HubSpot, they don't share a Laravel-level limiter β you need a single
HubspotRateLimiter
service that everything routes through.
If you want, I can sketch the Lua script for the sliding-window acquire and the Laravel service wrapper around it.
Copy
Give positive feedback
Give negative feedback
Retry
You said: What will happen if there are two different types of rate limits?
You said: What will happen if there are two different types of rate limits?
What will happen if there are two different types of rate limits?
Search requests that have 5 requests per second
The other rate limit that has, let's say, 100 requests per 10 seconds How do these work together? Is there some conflict? Can I reach the limit with one request and block either as well, or are these separated? Can I still continue making search requests once I hit the normal requests limits?
13:40
Retry
Edit
Copy
Claude responded: They're independent buckets β with one shared bucket on top.
Claude responded: They're independent buckets β with one shared bucket on top.
Analyzed independent rate limit buckets and their practical interactions
Analyzed independent rate limit buckets and their practical interactions
They're independent buckets β with one shared bucket on top.
The three buckets and what each call hits
The three buckets and what each call hits
Copy to clipboard
ββββββββββββββββββββ
Search request βββ β Search: 5/sec β βββ
ββββββββββββββββββββ β
ββββ βββββββββββββββββββ
ββββββββββββββββββββ β β Daily: 250kβ1M β
Non-search call βββ β Burst: 190/10s β βββ β (per portal) β
ββββββββββββββββββββ βββββββββββββββββββ
A search call is only metered against the search bucket and the daily bucket. A non-search call (batch read/update, single PATCH, associations, etc.) is only metered against the burst bucket and the daily bucket. The two short-window buckets do not share counters.
What this means practically
What this means practically
Hitting search secondly limit (5/s):
Only further
/search
calls 429. Your batch reads, batch updates, single PATCHes, association calls β all keep working at full burst speed. This is actually useful: if your sync is bottlenecked on Search, you can pivot to using
lastmodifieddate
filters via batch endpoints, or use the IDs you already have to do batch reads, while Search cools off.
Hitting burst limit (190/10s):
Only non-search calls 429. You can still issue Search calls at 5/s. Useful for: continuing to identify deltas for queueing while in-flight updates drain, or refreshing a small set of records via Search even though your write pipeline is paused.
Hitting daily limit:
Everything stops. Search and non-search alike. Doesn't unblock until midnight in your portal's configured timezone β and remember this is shared across every private app in the portal, plus n8n flows, marketing tools, anything else hitting the API with that account.
So can one type of request block the other?
So can one type of request block the other?
Search β Burst:
No.
Saturating Search at 50 calls per 10s leaves your full 190/10s burst untouched.
Burst β Search:
No.
Saturating burst leaves Search's 5/s untouched.
Either β Daily:
Yes
, but only by contributing to the same daily counter. It's volume that kills you here, not the type.
In theory you can sustain ~50 search + ~190 other =
~240 calls per 10 seconds
indefinitely (until daily runs out), because the two buckets bill independently.
Implementation consequence
Implementation consequence
Your rate limiter needs to know which bucket a request hits before it acquires. Cleanest pattern:
Copy to clipboard
php
$limiter
->...
|
Claude
|
Claude
|
NULL
|
4369
|
|
4368
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Share chat
Claude finished the response
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
how to work with multiple jobs
how to work with paginated requests Let's consider a situation when there are 600 opportunities to sync. What would be the flow? How would the rate limit be recognized? How would it be handled? What are the potential issues? [API usage guidelines and limits - HubSpot docs](
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
). Example of such a error Client error:
POST https://api.hubapi.com/crm/v3/objects/contact/search
resulted in a
429 Too Many Requests
response: {"status":"error","message":"You have reached your secondly limit.","errorType":"RATE_LIMIT","correlationId":"019dffc4-4 (truncated...). Think carefully about the implementation and potential issue and bottlenecks.
Show more
10:42
Retry
Edit
Copy
Claude responded: Current HubSpot limits (Apr 2026)
Claude responded: Current HubSpot limits (Apr 2026)
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Current HubSpot limits (Apr 2026)
Current HubSpot limits (Apr 2026)
For privately distributed apps (which is what Jiminny presumably uses with HubSpot), the limits are layered: a per-app burst window of 100/10s on Free/Starter, 190/10s on Pro/Enterprise, or 250/10s with the API Limit Increase add-on
, plus a per-account daily cap of 250k / 625k / 1M depending on tier β shared across all private apps in the account
. The burst window is per app; the daily quota is per portal.
hubspot
hubspot
hubspot
hubspot
The Search API is special: five requests per second per account, capped at 200 records per page, with a hard 10,000-result ceiling per query
. That's the limit the 429 in your example is hitting (
secondly limit
on
/crm/v3/objects/contact/search
). It's a separate bucket from the 190/10s, and critically, search responses do not include the
X-HubSpot-RateLimit-*
headers
β you can't read remaining capacity off the response, you have to track it yourself.
hubspot
hubspot
hubspot
hubspot
Non-search endpoints return
X-HubSpot-RateLimit-Remaining
,
-Max
, and
-Interval-Milliseconds
. The daily headers are not returned for OAuth-authenticated calls
, so for those you check the account-info endpoint or maintain your own counter. There's also a soft rule: errors should stay under 5% of total daily requests
β that's enforced for marketplace listing, but it's also a sane operational target.
hubspot
hubspot
hubspot
hubspot
So you have
four buckets
to track at minimum: app-burst (10s sliding), search-secondly (1s sliding), account-daily (24h fixed, midnight in HubSpot's TZ), and per-app daily share (your own budgeting on top of the account cap).
Where to store it
Where to store it
Redis. It's the only realistic option once you have multiple queue workers β DB-backed counters serialize too much, and in-process state can't coordinate across workers. Laravel already speaks Redis natively, and you get atomic
INCR
/
EXPIRE
plus Lua scripting for true CAS semantics.
Key layout I'd use:
Copy to clipboard
hubspot:rl:burst:{portalId}:{appId} ZSET (sliding 10s)
hubspot:rl:search:{portalId} ZSET (sliding 1s)
hubspot:rl:daily:{portalId} STRING + TTL to midnight TZ
hubspot:rl:meta:{portalId} HASH (last seen headers)
The two short-window buckets are sliding-window-log (Redis ZSET, score =
microtime
, member = unique request id). Lua script removes entries older than the window, counts remaining slots, and only adds the new one if there's room β all atomic. Fixed windows are simpler but allow 2Γ the limit at the boundary, which on a 5/s window is brutal.
The daily bucket is a plain
INCR
with TTL set to seconds-until-midnight in
HubSpot's account timezone
, not yours β Sofia is UTC+2/+3 but your portal might be set to US Eastern. Get this once and cache it.
How to read it
How to read it
Two-phase: optimistic pre-check, authoritative post-update.
Before a call, run the Lua acquire script. If it returns "denied," sleep until a slot frees up (the script can return ms-until-next-slot) or push the job back to the queue with a delay. Don't busy-loop.
After the call, parse
X-HubSpot-RateLimit-Remaining
/
-Max
/
-Interval-Milliseconds
and store them in
hubspot:rl:meta:{portalId}
. This is your reality check β if your local counter says 50 remaining but HubSpot's header says 5, you trust HubSpot and clamp your counter. This handles clock drift, missed accounting (e.g., crashed worker that took a token but never made the request), and other apps in the same account consuming the daily budget invisibly.
For search specifically, since headers don't come back, the local counter
is
the source of truth β meaning if you ever crash mid-flight, you've under-counted. Always release tokens on connection-level failure but
not
on 429 (you really did make that request).
How to work with multiple jobs
How to work with multiple jobs
The queue layer needs to enforce concurrency separately from the rate limiter. Both work together:
Concurrency cap
via
Queue::throttle()
or a Redis semaphore β limits how many sync workers run in parallel against HubSpot. Without this, you can have 50 workers all blocked waiting for tokens, which is wasteful and creates retry storms.
Per-tenant fairness
β if you sync many Jiminny customers into different HubSpot portals, each portal has its own bucket but you still want one slow portal not to starve others. Either separate queues per portal or a fair-share scheduler.
Priority lanes
β webhook-driven updates (user-visible latency) should outrank background batch syncs. Two queues:
hubspot-priority
and
hubspot-bulk
, with priority workers taking 70% of the burst budget and bulk taking 30% (enforce via separate sub-buckets if you really want hard separation, otherwise just pull from priority first).
Backoff on 429
β respect the
Retry-After
header. If absent, exponential with jitter (e.g.,
min(2^attempt * 250ms, 30s) Β± 20%
). The jitter is non-negotiable; without it, simultaneous 429s retry in lockstep and you get thundering-herd 429s on retry.
How to work with paginated requests
How to work with paginated requests
The trap is treating "fetch all" as one logical operation. Each page is its own API call and competes for tokens with everything else.
Two practical rules:
Don't hold the worker idle while paginating.
If page N takes 500ms and page N+1 needs to wait 800ms for a token, you've burned 800ms of worker time doing nothing. Instead, fetch page N, dispatch the
processing
of page N as a separate job, and queue a "fetch page N+1" job with a delay equal to the wait time. Each page becomes its own atomic unit.
Always batch where HubSpot offers it.
POST /crm/v3/objects/{type}/batch/{read|update|create}
accepts up to 100 IDs per call. For your "patching IDs" flow this is the difference between 600 calls and 6.
Walkthrough: 600 opportunities
Walkthrough: 600 opportunities
Naive flow (one PATCH per deal): 600 calls. At 190/10s that's ~32s of API time, well under daily. You'd hit burst easily without throttling. Plus likely 1-3 search calls upfront and N association calls.
Sane flow:
Identify deltas
β if you can avoid Search at all, do. Use
lastmodifieddate
filter on a single search if you must, paginate at limit=200. For 600 deals that's 3 search calls @ 5/s = ~600ms naturally throttled.
Batch read
current state β
POST /crm/v3/objects/deals/batch/read
with 100 IDs per call β 6 calls. Burst weight 6.
Compute diff
in your code (no API).
Batch update
β
POST /crm/v3/objects/deals/batch/update
with 100 per call β 6 calls.
Associations
β
POST /crm/v4/associations/{from}/{to}/batch/create
if needed β another few batch calls.
Total: ~15-20 API calls for 600 deals. Burst budget consumed: 20/190 over ~5s. Daily impact: trivial.
Recognition: pre-check denies if
<weight>
slots aren't free; on 429 the response surfaces
policyName
(DAILY/SECONDLY) β log it, push the job back with
Retry-After
delay, increment a metric so you can alarm on sustained 429 rate.
Pitfalls & bottlenecks worth pre-empting
Pitfalls & bottlenecks worth pre-empting
Daily quota is shared across the whole portal
, including any n8n flows, other private apps, marketing automation calling APIs, etc. Budget for ~70-80% of the documented limit, not 100%. Add an internal per-app daily cap so a runaway sync can't starve other apps.
Search is uniquely fragile
: separate 5/s bucket, no headers to read, 10k-result cap per query. If you ever hit 10k+ deals matching a filter, partition by
hs_object_id
ranges or by
lastmodifieddate
windows.
Retry storms after HubSpot incidents
β always jitter, always cap total retries (e.g., 5 attempts, then dead-letter).
Webhook β sync β webhook loops
β when your update fires a HubSpot webhook that triggers another sync. Tag your own writes (e.g., a custom property
jy_last_sync_id
) and ignore webhooks where it just changed.
Token refresh
β OAuth refresh itself counts against burst. Cache the access token in Redis with TTL =
expires_in - 60s
, single-flight the refresh (only one worker refreshes; others wait on a lock).
Search latency for fresh writes
β newly created/updated objects don't appear in search instantly. Don't write-then-search; use returned IDs directly.
Clock skew
β Redis is authoritative. Don't use
time()
from each worker for window scoring; use
redis.call('TIME')
inside the Lua script.
Dead workers with held tokens
β sliding-window-log handles this naturally because tokens expire by score; token-bucket implementations need explicit release-on-crash logic.
The 5% error rule
counts every 429 toward your error budget, even successfully retried ones. If your pre-check is working well, 429s should be near zero β if they're not, your pre-check is wrong, not just slow.
Phantom contention with Laravel
RateLimited
middleware
: it's per-job-class by default, not per-portal. If your
SyncDealJob
and
UpdateActivityJob
are different classes both calling HubSpot, they don't share a Laravel-level limiter β you need a single
HubspotRateLimiter
service that everything routes through.
If you want, I can sketch the Lua script for the sliding-window acquire and the Laravel service wrapper around it.
Copy
Give positive feedback
Give negative feedback
Retry
You said: What will happen if there are two different types of rate limits?
You said: What will happen if there are two different types of rate limits?
What will happen if there are two different types of rate limits?
Search requests that have 5 requests per second
The other rate limit that has, let's say, 100 requests per 10 seconds How do these work together? Is there some conflict? Can I reach the limit with one request and block either as well, or are these separated? Can I still continue making search requests once I hit the normal requests limits?
13:40
Retry
Edit
Copy
Claude responded: They're independent buckets β with one shared bucket on top.
Claude responded: They're independent buckets β with one shared bucket on top.
Analyzed independent rate limit buckets and their practical interactions
Analyzed independent rate limit buckets and their practical interactions
They're independent buckets β with one shared bucket on top.
The three buckets and what each call hits
The three buckets and what each call hits
Copy to clipboard
ββββββββββββββββββββ
Search request βββ β Search: 5/sec β βββ
ββββββββββββββββββββ β
ββββ βββββββββββββββββββ
ββββββββββββββββββββ β β Daily: 250kβ1M β
Non-search call βββ β Burst: 190/10s β βββ β (per portal) β
ββββββββββββββββββββ βββββββββββββββββββ
A search call is only metered against the search bucket and the daily bucket. A non-search call (batch read/update, single PATCH, associations, etc.) is only metered against the burst bucket and the daily bucket. The two short-window buckets do not share counters.
What this means practically
What this means practically
Hitting search secondly limit (5/s):
Only further
/search
calls 429. Your batch reads, batch updates, single PATCHes, association calls β all keep working at full burst speed. This is actually useful: if your sync is bottlenecked on Search, you can pivot to using
lastmodifieddate
filters via batch endpoints, or use the IDs you already have to do batch reads, while Search cools off.
Hitting burst limit (190/10s):
Only non-search calls 429. You can still issue Search calls at 5/s. Useful for: continuing to identify deltas for queueing while in-flight updates drain, or refreshing a small set of records via Search even though your write pipeline is paused.
Hitting daily limit:
Everything stops. Search and non-search alike. Doesn't unblock until midnight in your portal's configured timezone β and remember this is shared across every private app in the portal, plus n8n flows, marketing tools, anything else hitting the API with that account.
So can one type of request block the other?
So can one type of request block the other?
Search β Burst:
No.
Saturating Search at 50 calls per 10s leaves your full 190/10s burst untouched.
Burst β Search:
No.
Saturating burst leaves Search's 5/s untouched.
Either β Daily:
Yes
, but only by contributing to the same daily counter. It's volume that kills you here, not the type.
In theory you can sustain ~50 search + ~190 other =
~240 calls per 10 seconds
indefinitely (until daily runs out), because the two buckets bill independently.
Implementation consequence
Implementation consequence
Your rate limiter needs to know which bucket a request hits before it acquires. Cleanest pattern:
Copy to clipboard
php
$limiter
->
acquire
(
'search'
,
$weight
=
1
)
;
// for search endpoints only
$limiter
->
acquire
(
'burst'
,
$weight
=
1
)
;
// for everything else
$limiter
->
acquire
(
'daily'
,
$weight
=
1
)
;
// every call, both kinds
In Redis: three separate keys, three separate Lua acquire scripts (or one script with a bucket parameter). A search call calls
acquire('search')
+
acquire('daily')
. A batch update calls
acquire('burst')
+
acquire('daily')
.
One subtle pitfall: when you backoff on a 429,
inspect
policyName
in the response body
to know which bucket actually fired. If you see
SECONDLY
from a search endpoint, you only need to delay search-bound jobs β burst-bound jobs in the queue can keep running. If you blanket-pause everything on any 429, you waste capacity on the bucket that's still healthy. Two queues (or two throttle keys) make this clean; one global pause is the lazy version.
The other subtlety: the burst response gives you
X-HubSpot-RateLimit-Remaining
to clamp local state against, but search doesn't return those headers. So your search counter is unverified β be slightly more conservative there (e.g., budget 4/s instead of 5) to absorb the unaccounted-for calls.
Copy
Give positive feedback
Give negative feedback
Retry
You said: Ok, so what will happen each time I make a request?
You said: Ok, so what will happen each time I make a request?
Ok, so what will happen each time I make a request? Let's say I have 100,000 requests to make that are instant. Do I need to increment each request based on the type? For example, if there is a search request, I need to increment both the search bucket and also the daily bucket. If it's a burst, then I can go to the daily and burst buckets. If I need to check if it can make a call, do I need to see both the daily and search, or burst, respectively? Isn't that too heavy for the infrastructure, adding additional load to each request?
13:44
Retry
Edit
Copy
Claude responded: Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out.
Claude responded: Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out.
Analyzed per-request overhead concerns and quantified Redis performance impact
Analyzed per-request overhead concerns and quantified Redis performance impact
Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out. But the overhead is much smaller than it sounds, and importantly, it's nowhere near your bottleneck.
What "two buckets per request" actually costs
What "two buckets per request" actually costs
Each request makes
one round trip to Redis
β not two β because you fold both bucket checks into a single Lua script that runs atomically server-side:
Copy to clipboard
lua
-- KEYS[1] = burst bucket key (or search)
-- KEYS[2] = daily bucket key
-- ARGV[1] = now (ms) ARGV[2] = window_ms
-- ARGV[3] = bucket_max ARGV[4] = daily_max
-- ARGV[5] = request_id ARGV[6] = daily_ttl
-- Trim sliding window
redis
.
call
(...
|
Claude
|
Claude
|
NULL
|
4368
|
|
4367
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Share chat
Claude finished the response
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
how to work with multiple jobs
how to work with paginated requests Let's consider a situation when there are 600 opportunities to sync. What would be the flow? How would the rate limit be recognized? How would it be handled? What are the potential issues? [API usage guidelines and limits - HubSpot docs](
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
). Example of such a error Client error:
POST https://api.hubapi.com/crm/v3/objects/contact/search
resulted in a
429 Too Many Requests
response: {"status":"error","message":"You have reached your secondly limit.","errorType":"RATE_LIMIT","correlationId":"019dffc4-4 (truncated...). Think carefully about the implementation and potential issue and bottlenecks.
Show more
10:42
Retry
Edit
Copy
Claude responded: Current HubSpot limits (Apr 2026)
Claude responded: Current HubSpot limits (Apr 2026)
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Current HubSpot limits (Apr 2026)
Current HubSpot limits (Apr 2026)
For privately distributed apps (which is what Jiminny presumably uses with HubSpot), the limits are layered: a per-app burst window of 100/10s on Free/Starter, 190/10s on Pro/Enterprise, or 250/10s with the API Limit Increase add-on
, plus a per-account daily cap of 250k / 625k / 1M depending on tier β shared across all private apps in the account
. The burst window is per app; the daily quota is per portal.
hubspot
hubspot
hubspot
hubspot
The Search API is special: five requests per second per account, capped at 200 records per page, with a hard 10,000-result ceiling per query
. That's the limit the 429 in your example is hitting (
secondly limit
on
/crm/v3/objects/contact/search
). It's a separate bucket from the 190/10s, and critically, search responses do not include the
X-HubSpot-RateLimit-*
headers
β you can't read remaining capacity off the response, you have to track it yourself.
hubspot
hubspot
hubspot
hubspot
Non-search endpoints return
X-HubSpot-RateLimit-Remaining
,
-Max
, and
-Interval-Milliseconds
. The daily headers are not returned for OAuth-authenticated calls
, so for those you check the account-info endpoint or maintain your own counter. There's also a soft rule: errors should stay under 5% of total daily requests
β that's enforced for marketplace listing, but it's also a sane operational target.
hubspot
hubspot
hubspot
hubspot
So you have
four buckets
to track at minimum: app-burst (10s sliding), search-secondly (1s sliding), account-daily (24h fixed, midnight in HubSpot's TZ), and per-app daily share (your own budgeting on top of the account cap).
Where to store it
Where to store it
Redis. It's the only realistic option once you have multiple queue workers β DB-backed counters serialize too much, and in-process state can't coordinate across workers. Laravel already speaks Redis natively, and you get atomic
INCR
/
EXPIRE
plus Lua scripting for true CAS semantics.
Key layout I'd use:
Copy to clipboard
hubspot:rl:burst:{portalId}:{appId} ZSET (sliding 10s)
hubspot:rl:search:{portalId} ZSET (sliding 1s)
hubspot:rl:daily:{portalId} STRING + TTL to midnight TZ
hubspot:rl:meta:{portalId} HASH (last seen headers)
The two short-window buckets are sliding-window-log (Redis ZSET, score =
microtime
, member = unique request id). Lua script removes entries older than the window, counts remaining slots, and only adds the new one if there's room β all atomic. Fixed windows are simpler but allow 2Γ the limit at the boundary, which on a 5/s window is brutal.
The daily bucket is a plain
INCR
with TTL set to seconds-until-midnight in
HubSpot's account timezone
, not yours β Sofia is UTC+2/+3 but your portal might be set to US Eastern. Get this once and cache it.
How to read it
How to read it
Two-phase: optimistic pre-check, authoritative post-update.
Before a call, run the Lua acquire script. If it returns "denied," sleep until a slot frees up (the script can return ms-until-next-slot) or push the job back to the queue with a delay. Don't busy-loop.
After the call, parse
X-HubSpot-RateLimit-Remaining
/
-Max
/
-Interval-Milliseconds
and store them in
hubspot:rl:meta:{portalId}
. This is your reality check β if your local counter says 50 remaining but HubSpot's header says 5, you trust HubSpot and clamp your counter. This handles clock drift, missed accounting (e.g., crashed worker that took a token but never made the request), and other apps in the same account consuming the daily budget invisibly.
For search specifically, since headers don't come back, the local counter
is
the source of truth β meaning if you ever crash mid-flight, you've under-counted. Always release tokens on connection-level failure but
not
on 429 (you really did make that request).
How to work with multiple jobs
How to work with multiple jobs
The queue layer needs to enforce concurrency separately from the rate limiter. Both work together:
Concurrency cap
via
Queue::throttle()
or a Redis semaphore β limits how many sync workers run in parallel against HubSpot. Without this, you can have 50 workers all blocked waiting for tokens, which is wasteful and creates retry storms.
Per-tenant fairness
β if you sync many Jiminny customers into different HubSpot portals, each portal has its own bucket but you still want one slow portal not to starve others. Either separate queues per portal or a fair-share scheduler.
Priority lanes
β webhook-driven updates (user-visible latency) should outrank background batch syncs. Two queues:
hubspot-priority
and
hubspot-bulk
, with priority workers taking 70% of the burst budget and bulk taking 30% (enforce via separate sub-buckets if you really want hard separation, otherwise just pull from priority first).
Backoff on 429
β respect the
Retry-After
header. If absent, exponential with jitter (e.g.,
min(2^attempt * 250ms, 30s) Β± 20%
). The jitter is non-negotiable; without it, simultaneous 429s retry in lockstep and you get thundering-herd 429s on retry.
How to work with paginated requests
How to work with paginated requests
The trap is treating "fetch all" as one logical operation. Each page is its own API call and competes for tokens with everything else.
Two practical rules:
Don't hold the worker idle while paginating.
If page N takes 500ms and page N+1 needs to wait 800ms for a token, you've burned 800ms of worker time doing nothing. Instead, fetch page N, dispatch the
processing
of page N as a separate job, and queue a "fetch page N+1" job with a delay equal to the wait time. Each page becomes its own atomic unit.
Always batch where HubSpot offers it.
POST /crm/v3/objects/{type}/batch/{read|update|create}
accepts up to 100 IDs per call. For your "patching IDs" flow this is the difference between 600 calls and 6.
Walkthrough: 600 opportunities
Walkthrough: 600 opportunities
Naive flow (one PATCH per deal): 600 calls. At 190/10s that's ~32s of API time, well under daily. You'd hit burst easily without throttling. Plus likely 1-3 search calls upfront and N association calls.
Sane flow:
Identify deltas
β if you can avoid Search at all, do. Use
lastmodifieddate
filter on a single search if you must, paginate at limit=200. For 600 deals that's 3 search calls @ 5/s = ~600ms naturally throttled.
Batch read
current state β
POST /crm/v3/objects/deals/batch/read
with 100 IDs per call β 6 calls. Burst weight 6.
Compute diff
in your code (no API).
Batch update
β
POST /crm/v3/objects/deals/batch/update
with 100 per call β 6 calls.
Associations
β
POST /crm/v4/associations/{from}/{to}/batch/create
if needed β another few batch calls.
Total: ~15-20 API calls for 600 deals. Burst budget consumed: 20/190 over ~5s. Daily impact: trivial.
Recognition: pre-check denies if
<weight>
slots aren't free; on 429 the response surfaces
policyName
(DAILY/SECONDLY) β log it, push the job back with
Retry-After
delay, increment a metric so you can alarm on sustained 429 rate.
Pitfalls & bottlenecks worth pre-empting
Pitfalls & bottlenecks worth pre-empting
Daily quota is shared across the whole portal
, including any n8n flows, other private apps, marketing automation calling APIs, etc. Budget for ~70-80% of the documented limit, not 100%. Add an internal per-app daily cap so a runaway sync can't starve other apps.
Search is uniquely fragile
: separate 5/s bucket, no headers to read, 10k-result cap per query. If you ever hit 10k+ deals matching a filter, partition by
hs_object_id
ranges or by
lastmodifieddate
windows.
Retry storms after HubSpot incidents
β always jitter, always cap total retries (e.g., 5 attempts, then dead-letter).
Webhook β sync β webhook loops
β when your update fires a HubSpot webhook that triggers another sync. Tag your own writes (e.g., a custom property
jy_last_sync_id
) and ignore webhooks where it just changed.
Token refresh
β OAuth refresh itself counts against burst. Cache the access token in Redis with TTL =
expires_in - 60s
, single-flight the refresh (only one worker refreshes; others wait on a lock).
Search latency for fresh writes
β newly created/updated objects don't appear in search instantly. Don't write-then-search; use returned IDs directly.
Clock skew
β Redis is authoritative. Don't use
time()
from each worker for window scoring; use
redis.call('TIME')
inside the Lua script....
|
Claude
|
Claude
|
NULL
|
4367
|
|
4366
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Share chat
Claude finished the response
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
how to work with multiple jobs
how to work with paginated requests Let's consider a situation when there are 600 opportunities to sync. What would be the flow? How would the rate limit be recognized? How would it be handled? What are the potential issues? [API usage guidelines and limits - HubSpot docs](
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
). Example of such a error Client error:
POST https://api.hubapi.com/crm/v3/objects/contact/search
resulted in a
429 Too Many Requests
response: {"status":"error","message":"You have reached your secondly limit.","errorType":"RATE_LIMIT","correlationId":"019dffc4-4 (truncated...). Think carefully about the implementation and potential issue and bottlenecks.
Show more
10:42
Retry
Edit
Copy
Claude responded: Current HubSpot limits (Apr 2026)
Claude responded: Current HubSpot limits (Apr 2026)
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Current HubSpot limits (Apr 2026)
Current HubSpot limits (Apr 2026)
For privately distributed apps (which is what Jiminny presumably uses with HubSpot), the limits are layered: a per-app burst window of 100/10s on Free/Starter, 190/10s on Pro/Enterprise, or 250/10s with the API Limit Increase add-on
, plus a per-account daily cap of 250k / 625k / 1M depending on tier β shared across all private apps in the account
. The burst window is per app; the daily quota is per portal.
hubspot
hubspot
hubspot
hubspot
The Search API is special: five requests per second per account, capped at 200 records per page, with a hard 10,000-result ceiling per query
. That's the limit the 429 in your example is hitting (
secondly limit
on
/crm/v3/objects/contact/search
). It's a separate bucket from the 190/10s, and critically, search responses do not include the
X-HubSpot-RateLimit-*
headers
β you can't read remaining capacity off the response, you have to track it yourself.
hubspot
hubspot
hubspot
hubspot
Non-search endpoints return
X-HubSpot-RateLimit-Remaining
,
-Max
, and
-Interval-Milliseconds
. The daily headers are not returned for OAuth-authenticated calls
, so for those you check the account-info endpoint or maintain your own counter. There's also a soft rule: errors should stay under 5% of total daily requests
β that's enforced for marketplace listing, but it's also a sane operational target.
hubspot
hubspot
hubspot
hubspot
So you have
four buckets
to track at minimum: app-burst (10s sliding), search-secondly (1s sliding), account-daily (24h fixed, midnight in HubSpot's TZ), and per-app daily share (your own budgeting on top of the account cap).
Where to store it
Where to store it
Redis. It's the only realistic option once you have multiple queue workers β DB-backed counters serialize too much, and in-process state can't coordinate across workers. Laravel already speaks Redis natively, and you get atomic
INCR
/
EXPIRE
plus Lua scripting for true CAS semantics.
Key layout I'd use:
Copy to clipboard
hubspot:rl:burst:{portalId}:{appId} ZSET (sliding 10s)
hubspot:rl:search:{portalId} ZSET (sliding 1s)
hubspot:rl:daily:{portalId} STRING + TTL to midnight TZ
hubspot:rl:meta:{portalId} HASH (last seen headers)
The two short-window buckets are sliding-window-log (Redis ZSET, score =
microtime
, member = unique request id). Lua script removes entries older than the window, counts remaining slots, and only adds the new one if there's room β all atomic. Fixed windows are simpler but allow 2Γ the limit at the boundary, which on a 5/s window is brutal.
The daily bucket is a plain
INCR
with TTL set to seconds-until-midnight in
HubSpot's account timezone
, not yours β Sofia is UTC+2/+3 but your portal might be set to US Eastern. Get this once and cache it.
How to read it
How to read it
Two-phase: optimistic pre-check, authoritative post-update.
Before a call, run the Lua acquire script. If it returns "denied," sleep until a slot frees up (the script can return ms-until-next-slot) or push the job back to the queue with a delay. Don't busy-loop.
After the call, parse
X-HubSpot-RateLimit-Remaining
/
-Max
/
-Interval-Milliseconds
and store them in
hubspot:rl:meta:{portalId}
. This is your reality check β if your local counter says 50 remaining but HubSpot's header says 5, you trust HubSpot and clamp your counter. This handles clock drift, missed accounting (e.g., crashed worker that took a token but never made the request), and other apps in the same account consuming the daily budget invisibly.
For search specifically, since headers don't come back, the local counter
is
the source of truth β meaning if you ever crash mid-flight, you've under-counted. Always release tokens on connection-level failure but
not
on 429 (you really did make that request).
How to work with multiple jobs
How to work with multiple jobs
The queue layer needs to enforce concurrency separately from the rate limiter. Both work together:
Concurrency cap
via
Queue::throttle()
or a Redis semaphore β limits how many sync workers run in parallel against HubSpot. Without this, you can have 50 workers all blocked waiting for tokens, which is wasteful and creates retry storms.
Per-tenant fairness
β if you sync many Jiminny customers into different HubSpot portals, each portal has its own bucket but you still want one slow portal not to starve others. Either separate queues per portal or a fair-share scheduler.
Priority lanes
β webhook-driven updates (user-visible latency) should outrank background batch syncs. Two queues:
hubspot-priority
and
hubspot-bulk
, with priority workers taking 70% of the burst budget and bulk taking 30% (enforce via separate sub-buckets if you really want hard separation, otherwise just pull from priority first).
Backoff on 429
β respect the
Retry-After
header. If absent, exponential with jitter (e.g.,
min(2^attempt * 250ms, 30s) Β± 20%
). The jitter is non-negotiable; without it, simultaneous 429s retry in lockstep and you get thundering-herd 429s on retry.
How to work with paginated requests
How to work with paginated requests
The trap is treating "fetch all" as one logical operation. Each page is its own API call and competes for tokens with everything else.
Two practical rules:
Don't hold the worker idle while paginating.
If page N takes 500ms and page N+1 needs to wait 800ms for a token, you've burned 800ms of worker time doing nothing. Instead, fetch page N, dispatch the
processing
of page N as a separate job, and queue a "fetch page N+1" job with a delay equal to the wait time. Each page becomes its own atomic unit.
Always batch where HubSpot offers it.
POST /crm/v3/objects/{type}/batch/{read|update|create}
accepts up to 100 IDs per call. For your "patching IDs" flow this is the difference between 600 calls and 6.
Walkthrough: 600 opportunities
Walkthrough: 600 opportunities
Naive flow (one PATCH per deal): 600 calls. At 190/10s that's ~32s of API time, well under daily. You'd hit burst easily without throttling. Plus likely 1-3 search calls upfront and N association calls.
Sane flow:
Identify deltas
β if you can avoid Search at all, do. Use
lastmodifieddate
filter on a single search if you must, paginate at limit=200. For 600 deals that's 3 search calls @ 5/s = ~600ms naturally throttled.
Batch read
current state β
POST /crm/v3/objects/deals/batch/read...
|
Claude
|
Claude
|
NULL
|
4366
|
|
4365
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Share chat
Claude finished the response
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
how to work with multiple jobs
how to work with paginated requests Let's consider a situation when there are 600 opportunities to sync. What would be the flow? How would the rate limit be recognized? How would it be handled? What are the potential issues? [API usage guidelines and limits - HubSpot docs](
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
). Example of such a error Client error:
POST https://api.hubapi.com/crm/v3/objects/contact/search
resulted in a
429 Too Many Requests
response: {"status":"error","message":"You have reached your secondly limit.","errorType":"RATE_LIMIT","correlationId":"019dffc4-4 (truncated...). Think carefully about the implementation and potential issue and bottlenecks.
Show more
10:42
Retry
Edit
Copy
Claude responded: Current HubSpot limits (Apr 2026)
Claude responded: Current HubSpot limits (Apr 2026)
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Current HubSpot limits (Apr 2026)
Current HubSpot limits (Apr 2026)
For privately distributed apps (which is what Jiminny presumably uses with HubSpot), the limits are layered: a per-app burst window of 100/10s on Free/Starter, 190/10s on Pro/Enterprise, or 250/10s with the API Limit Increase add-on
, plus a per-account daily cap of 250k / 625k / 1M depending on tier β shared across all private apps in the account
. The burst window is per app; the daily quota is per portal.
hubspot
hubspot
hubspot
hubspot
The Search API is special: five requests per second per account, capped at 200 records per page, with a hard 10,000-result ceiling per query
. That's the limit the 429 in your example is hitting (
secondly limit
on
/crm/v3/objects/contact/search
). It's a separate bucket from the 190/10s, and critically, search responses do not include the
X-HubSpot-RateLimit-*
headers
β you can't read remaining capacity off the response, you have to track it yourself.
hubspot
hubspot
hubspot
hubspot
Non-search endpoints return
X-HubSpot-RateLimit-Remaining
,
-Max
, and
-Interval-Milliseconds
. The daily headers are not returned for OAuth-authenticated calls
, so for those you check the account-info endpoint or maintain your own counter. There's also a soft rule: errors should stay under 5% of total daily requests
β that's enforced for marketplace listing, but it's also a sane operational target.
hubspot
hubspot
hubspot
hubspot
So you have
four buckets
to track at minimum: app-burst (10s sliding), search-secondly (1s sliding), account-daily (24h fixed, midnight in HubSpot's TZ), and per-app daily share (your own budgeting on top of the account cap).
Where to store it
Where to store it
Redis. It's the only realistic option once you have multiple queue workers β DB-backed counters serialize too much, and in-process state can't coordinate across workers. Laravel already speaks Redis natively, and you get atomic
INCR
/
EXPIRE
plus Lua scripting for true CAS semantics.
Key layout I'd use:
Copy to clipboard
hubspot:rl:burst:{portalId}:{appId} ZSET (sliding 10s)
hubspot:rl:search:{portalId} ZSET (sliding 1s)
hubspot:rl:daily:{portalId} STRING + TTL to midnight TZ
hubspot:rl:meta:{portalId} HASH (last seen headers)
The two short-window buckets are sliding-window-log (Redis ZSET, score =
microtime
, member = unique request id). Lua script removes entries older than the window, counts remaining slots, and only adds the new one if there's room β all atomic. Fixed windows are simpler but allow 2Γ the limit at the boundary, which on a 5/s window is brutal.
The daily bucket is a plain
INCR
with TTL set to seconds-until-midnight in
HubSpot's account timezone
, not yours β Sofia is UTC+2/+3 but your portal might be set to US Eastern. Get this once and cache it.
How to read it
How to read it
Two-phase: optimistic pre-check, authoritative post-update.
Before a call, run the Lua acquire script. If it returns "denied," sleep until a slot frees up (the script can return ms-until-next-slot) or push the job back to the queue with a delay. Don't busy-loop.
After the call, parse
X-HubSpot-RateLimit-Remaining
/
-Max
/
-Interval-Milliseconds
and store them in
hubspot:rl:meta:{portalId}
. This is your reality check β if your local counter says 50 remaining but HubSpot's header says 5, you trust HubSpot and clamp your counter. This handles clock drift, missed accounting (e.g., crashed worker that took a token but never made the request), and other apps in the same account consuming the daily budget invisibly.
For search specifically, since headers don't come back, the local counter
is
the source of truth β meaning if you ever crash mid-flight, you've under-counted. Always release tokens on connection-level failure but
not
on 429 (you really did make that request).
How to work with multiple jobs
How to work with multiple jobs
The queue layer needs to enforce concurrency separately from the rate limiter. Both work together:
Concurrency cap
via
Queue::throttle()
or a Redis semaphore β limits how many sync workers run in parallel against HubSpot. Without this, you can have 50 workers all blocked waiting for tokens, which is wasteful and creates retry storms.
Per-tenant fairness
β if you sync many Jiminny customers into different HubSpot portals, each portal has its own bucket but you still want one slow portal not to starve others. Either separate queues per portal or a fair-share scheduler.
Priority lanes
β webhook-driven updates (user-visible latency) should outrank background batch syncs. Two queues:
hubspot-priority
and
hubspot-bulk
, with priority workers taking 70% of the burst budget and bulk taking 30% (enforce via separate sub-buckets if you really want hard separation, otherwise just pull from priority first).
Backoff on 429
β respect the
Retry-After
header. If absent, exponential with jitter (e.g.,
min(2^attempt * 250ms, 30s) Β± 20%
). The jitter is non-negotiable; without it, simultaneous 429s retry in lockstep and you get thundering-herd 429s on retry.
How to work with paginated requests
How to work with paginated requests
The trap is treating "fetch all" as one logical operation. Each page is its own API call and competes for tokens with everything else.
Two practical rules:
Don't hold the worker idle while paginating.
If page N takes 500ms and page N+1 needs to wait 800ms for a token, you've burned 800ms of worker time doing nothing. Instead, fetch page N, dispatch the
processing
of page N as a separate job, and queue a "fetch page N+1" job with a delay equal to the wait time. Each page becomes its own atomic unit.
Always batch where HubSpot offers it.
POST /crm/v3/objects/{type}/batch/{read|update|create}
accepts up to 100 IDs per call. For your "patching IDs" flow this is the difference between 600 calls and 6.
Walkthrough: 600 opportunities
Walkthrough: 600 opportunities
Naive flow (one PATCH per deal): 600 calls. At 190/10s that's ~32s of API time, well under daily. You'd hit burst easily without throttling. Plus likely 1-3 search calls upfront and N association calls.
Sane flow:
Identify deltas
β if you can avoid Search at all, do. Use
lastmodifieddate
filter on a single search if you must, paginate at limit=200. For 600 deals that's 3 search calls @ 5/s = ~600ms naturally throttled.
Batch read
current state β
POST /crm/v3/objects/deals/batch/read
with 100 IDs per call β 6 calls. Burst weight 6.
Compute diff
in your code (no API).
Batch update
β
POST /crm/v3/objects/deals/batch/update
with 100 per call β 6 calls.
Associations
β
POST /crm/v4/associations/{from}/{to}/batch/create
if needed β another few batch calls.
Total: ~15-20 API calls for 600 deals. Burst budget consumed: 20/190 over ~5s. Daily impact: trivial.
Recognition: pre-check denies if
<weight>
slots aren't free; on 429 the response surfaces
policyName
(DAILY/SECONDLY) β log it, push the job back with
Retry-After
delay, increment a metric so you can alarm on sustained 429 rate.
Pitfalls & bottlenecks worth pre-empting
Pitfalls & bottlenecks worth pre-empting
Daily quota is shared across the whole portal
, including any n8n flows, other private apps, marketing automation calling APIs, etc. Budget for ~70-80% of the documented limit, not 100%. Add an internal per-app daily cap so a runaway sync can't starve other apps.
Search is uniquely fragile
: separate 5/s bucket, no headers to read, 10k-result cap per query. If you ever hit 10k+ deals matching a filter, partition by
hs_object_id
ranges or by
lastmodifieddate
windows.
Retry storms after HubSpot incidents
β always jitter, always cap total retries (e.g., 5 attempts, then dead-letter).
Webhook β sync β webhook loops
β when your update fires a HubSpot webhook that triggers another sync. Tag your own writes (e.g., a custom property
jy_last_sync_id
) and ignore webhooks where it just changed.
Token refresh
β OAuth refresh itself counts against burst. Cache the access token in Redis with TTL =
expires_in - 60s
, single-flight the refresh (only one worker refreshes; others wait on a lock).
Search latency for fresh writes
β newly created/updated objects don't appear in search instantly. Don't write-then-search; use returned IDs directly.
Clock skew
β Redis is authoritative. Don't use
time()
from each worker for window scoring; use
redis.call('TIME')
inside the Lua script.
Dead workers with held tokens
β sliding-window-log handles this naturally because tokens expire by score; token-bucket implementations need explicit release-on-crash logic.
The 5% error rule
counts every 429 toward your error budget, even successfully retried ones. If your pre-check is working well, 429s should be near zero β if they're not, your pre-check is wrong, not just slow.
Phantom contention with Laravel
RateLimited
middleware
: it's per-job-class by default, not per-portal. If your
SyncDealJob
and
UpdateActivityJob
are different classes both calling HubSpot, they don't share a Laravel-level limiter β you need a single
HubspotRateLimiter
service that everything routes through.
If you want, I can sketch the Lua script for the sliding-window acquire and the Laravel service wrapper around it.
Copy
Give positive feedback
Give negative feedback
Retry
You said: What will happen if there are two different types of rate limits?
You said: What will happen if there are two different types of rate limits?
What will happen if there are two different types of rate limits?
Search requests that have 5 requests per second
The other rate limit that has, let's say, 100 requests per 10 seconds How do these work together? Is there some conflict? Can I reach the limit with one request and block either as well, or are these separated? Can I still continue making search requests once I hit the normal requests limits?
13:40
Retry
Edit
Copy
Claude responded: They're independent buckets β with one shared bucket on top.
Claude responded: They're independent buckets β with one shared bucket on top.
Analyzed independent rate limit buckets and their practical interactions
Analyzed independent rate limit buckets and their practical interactions
They're independent buckets β with one shared bucket on top.
The three buckets and what each call hits
The three buckets and what each call hits
Copy to clipboard
ββββββββββββββββββββ
Search request βββ β Search: 5/sec β βββ
ββββββββββββββββββββ β
ββββ βββββββββββββββββββ
ββββββββββββββββββββ β β Daily: 250kβ1M β
Non-search call βββ β Burst: 190/10s β βββ β (per portal) β
ββββββββββββββββββββ βββββββββββββββββββ
A search call is only metered against the search bucket and the daily bucket. A non-search call (batch read/update, single PATCH, associations, etc.) is only metered against the burst bucket and the daily bucket. The two short-window buckets do not share counters.
What this means practically
What this means practically
Hitting search secondly limit (5/s):
Only further
/search
calls 429. Your batch reads, batch updates, single PATCHes, association calls β all keep working at full burst speed. This is actually useful: if your sync is bottlenecked on Search, you can pivot to using
lastmodifieddate
filters via batch endpoints, or use the IDs you already have to do batch reads, while Search cools off.
Hitting burst limit (190/10s):
Only non-search calls 429. You can still issue Search calls at 5/s. Useful for: continuing to identify deltas for queueing while in-flight updates drain, or refreshing a small set of records via Search even though your write pipeline is paused.
Hitting daily limit:
Everything stops. Search and non-search alike. Doesn't unblock until midnight in your portal's configured timezone β and remember this is shared across every private app in the portal, plus n8n flows, marketing tools, anything else hitting the API with that account.
So can one type of request block the other?
So can one type of request block the other?
Search β Burst:
No.
Saturating Search at 50 calls per 10s leaves your full 190/10s burst untouched.
Burst β Search:
No.
Saturating burst leaves Search's 5/s untouched.
Either β Daily:
Yes
, but only by contributing to the same daily counter. It's volume that kills you here, not the type.
In theory you can sustain ~50 search + ~190 other =
~240 calls per 10 seconds
indefinitely (until daily runs out), because the two buckets bill independently.
Implementation consequence
Implementation consequence
Your rate limiter needs to know which bucket a request hits before it acquires. Cleanest pattern:
Copy to clipboard
php
$limiter
->
acquire
(
'search'
,
$weight
=
1
)
;
// for search endpoints only
$limiter...
|
Claude
|
Claude
|
NULL
|
4365
|
|
4364
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Share chat
Claude finished the response
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
how to work with multiple jobs
how to work with paginated requests Let's consider a situation when there are 600 opportunities to sync. What would be the flow? How would the rate limit be recognized? How would it be handled? What are the potential issues? [API usage guidelines and limits - HubSpot docs](
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
). Example of such a error Client error:
POST https://api.hubapi.com/crm/v3/objects/contact/search
resulted in a
429 Too Many Requests
response: {"status":"error","message":"You have reached your secondly limit.","errorType":"RATE_LIMIT","correlationId":"019dffc4-4 (truncated...). Think carefully about the implementation and potential issue and bottlenecks.
Show more
10:42
Retry
Edit
Copy
Claude responded: Current HubSpot limits (Apr 2026)
Claude responded: Current HubSpot limits (Apr 2026)
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Current HubSpot limits (Apr 2026)
Current HubSpot limits (Apr 2026)
For privately distributed apps (which is what Jiminny presumably uses with HubSpot), the limits are layered: a per-app burst window of 100/10s on Free/Starter, 190/10s on Pro/Enterprise, or 250/10s with the API Limit Increase add-on
, plus a per-account daily cap of 250k / 625k / 1M depending on tier β shared across all private apps in the account
. The burst window is per app; the daily quota is per portal.
hubspot
hubspot
hubspot
hubspot
The Search API is special: five requests per second per account, capped at 200 records per page, with a hard 10,000-result ceiling per query
. That's the limit the 429 in your example is hitting (
secondly limit
on
/crm/v3/objects/contact/search
). It's a separate bucket from the 190/10s, and critically, search responses do not include the
X-HubSpot-RateLimit-*
headers
β you can't read remaining capacity off the response, you have to track it yourself.
hubspot
hubspot
hubspot
hubspot
Non-search endpoints return
X-HubSpot-RateLimit-Remaining
,
-Max
, and
-Interval-Milliseconds
. The daily headers are not returned for OAuth-authenticated calls
, so for those you check the account-info endpoint or maintain your own counter. There's also a soft rule: errors should stay under 5% of total daily requests
β that's enforced for marketplace listing, but it's also a sane operational target.
hubspot
hubspot
hubspot
hubspot
So you have
four buckets
to track at minimum: app-burst (10s sliding), search-secondly (1s sliding), account-daily (24h fixed, midnight in HubSpot's TZ), and per-app daily share (your own budgeting on top of the account cap).
Where to store it
Where to store it
Redis. It's the only realistic option once you have multiple queue workers β DB-backed counters serialize too much, and in-process state can't coordinate across workers. Laravel already speaks Redis natively, and you get atomic
INCR
/
EXPIRE
plus Lua scripting for true CAS semantics.
Key layout I'd use:
Copy to clipboard
hubspot:rl:burst:{portalId}:{appId} ZSET (sliding 10s)
hubspot:rl:search:{portalId} ZSET (sliding 1s)
hubspot:rl:daily:{portalId} STRING + TTL to midnight TZ
hubspot:rl:meta:{portalId} HASH (last seen headers)
The two short-window buckets are sliding-window-log (Redis ZSET, score =
microtime
, member = unique request id). Lua script removes entries older than the window, counts remaining slots, and only adds the new one if there's room β all atomic. Fixed windows are simpler but allow 2Γ the limit at the boundary, which on a 5/s window is brutal.
The daily bucket is a plain
INCR
with TTL set to seconds-until-midnight in
HubSpot's account timezone
, not yours β Sofia is UTC+2/+3 but your portal might be set to US Eastern. Get this once and cache it.
How to read it
How to read it
Two-phase: optimistic pre-check, authoritative post-update.
Before a call, run the Lua acquire script. If it returns "denied," sleep until a slot frees up (the script can return ms-until-next-slot) or push the job back to the queue with a delay. Don't busy-loop.
After the call, parse
X-HubSpot-RateLimit-Remaining
/
-Max
/
-Interval-Milliseconds
and store them in
hubspot:rl:meta:{portalId}
. This is your reality check β if your local counter says 50 remaining but HubSpot's header says 5, you trust HubSpot and clamp your counter. This handles clock drift, missed accounting (e.g., crashed worker that took a token but never made the request), and other apps in the same account consuming the daily budget invisibly.
For search specifically, since headers don't come back, the local counter
is
the source of truth β meaning if you ever crash mid-flight, you've under-counted. Always release tokens on connection-level failure but
not
on 429 (you really did make that request).
How to work with multiple jobs
How to work with multiple jobs
The queue layer needs to enforce concurrency separately from the rate limiter. Both work together:
Concurrency cap
via
Queue::throttle()
or a Redis semaphore β limits how many sync workers run in parallel against HubSpot. Without this, you can have 50 workers all blocked waiting for tokens, which is wasteful and creates retry storms.
Per-tenant fairness
β if you sync many Jiminny customers into different HubSpot portals, each portal has its own bucket but you still want one slow portal not to starve others. Either separate queues per portal or a fair-share scheduler.
Priority lanes
β webhook-driven updates (user-visible latency) should outrank background batch syncs. Two queues:
hubspot-priority
and
hubspot-bulk
, with priority workers taking 70% of the burst budget and bulk taking 30% (enforce via separate sub-buckets if you really want hard separation, otherwise just pull from priority first).
Backoff on 429
β respect the
Retry-After
header. If absent, exponential with jitter (e.g.,
min(2^attempt * 250ms, 30s) Β± 20%
). The jitter is non-negotiable; without it, simultaneous 429s retry in lockstep and you get thundering-herd 429s on retry.
How to work with paginated requests
How to work with paginated requests
The trap is treating "fetch all" as one logical operation. Each page is its own API call and competes for tokens with everything else.
Two practical rules:
Don't hold the worker idle while paginating.
If page N takes 500ms and page N+1 needs to wait 800ms for a token, you've burned 800ms of worker time doing nothing. Instead, fetch page N, dispatch the
processing
of page N as a separate job, and queue a "fetch page N+1" job with a delay equal to the wait time. Each page becomes its own atomic unit.
Always batch where HubSpot offers it.
POST /crm/v3/objects/{type}/batch/{read|update|create}
accepts up to 100 IDs per call. For your "patching IDs" flow this is the difference between 600 calls and 6.
Walkthrough: 600 opportunities
Walkthrough: 600 opportunities
Naive flow (one PATCH per deal): 600 calls. At 190/10s that's ~32s of API time, well under daily. You'd hit burst easily without throttling. Plus likely 1-3 search calls upfront and N association calls.
Sane flow:
Identify deltas
β if you can avoid Search at all, do. Use
lastmodifieddate
filter on a single search if you must, paginate at limit=200. For 600 deals that's 3 search calls @ 5/s = ~600ms naturally throttled.
Batch read
current state β
POST /crm/v3/objects/deals/batch/read
with 100 IDs per call β 6 calls. Burst weight 6.
Compute diff
in your code (no API).
Batch update
β
POST /crm/v3/objects/deals/batch/update
with 100 per call β 6 calls.
Associations
β
POST /crm/v4/associations/{from}/{to}/batch/create
if needed β another few batch calls.
Total: ~15-20 API calls for 600 deals. Burst budget consumed: 20/190 over ~5s. Daily impact: trivial.
Recognition: pre-check denies if
<weight>
slots aren't free; on 429 the response surfaces
policyName
(DAILY/SECONDLY) β log it, push the job back with
Retry-After
delay, increment a metric so you can alarm on sustained 429 rate.
Pitfalls & bottlenecks worth pre-empting
Pitfalls & bottlenecks worth pre-empting
Daily quota is shared across the whole portal
, including any n8n flows, other private apps, marketing automation calling APIs, etc. Budget for ~70-80% of the documented limit, not 100%. Add an internal per-app daily cap so a runaway sync can't starve other apps.
Search is uniquely fragile
: separate 5/s bucket, no headers to read, 10k-result cap per query. If you ever hit 10k+ deals matching a filter, partition by
hs_object_id
ranges or by
lastmodifieddate
windows.
Retry storms after HubSpot incidents
β always jitter, always cap total retries (e.g., 5 attempts, then dead-letter).
Webhook β sync β webhook loops
β when your update fires a HubSpot webhook that triggers another sync. Tag your own writes (e.g., a custom property
jy_last_sync_id
) and ignore webhooks where it just changed.
Token refresh
β OAuth refresh itself counts against burst. Cache the access token in Redis with TTL =
expires_in - 60s
, single-flight the refresh (only one worker refreshes; others wait on a lock).
Search latency for fresh writes
β newly created/updated objects don't appear in search instantly. Don't write-then-search; use returned IDs directly.
Clock skew
β Redis is authoritative. Don't use
time()
from each worker for window scoring; use
redis.call('TIME')
inside the Lua script.
Dead workers with held tokens
β sliding-window-log handles this naturally because tokens expire by score; token-bucket implementations need explicit release-on-crash logic.
The 5% error rule
counts every 429 toward your error budget, even successfully retried ones. If your pre-check is working well, 429s should be near zero β if they're not, your pre-check is wrong, not just slow.
Phantom contention with Laravel
RateLimited
middleware
: it's per-job-class by default, not per-portal. If your
SyncDealJob
and
UpdateActivityJob
are different classes both calling HubSpot, they don't share a Laravel-level limiter β you need a single
HubspotRateLimiter
service that everything routes through.
If you want, I can sketch the Lua script for the sliding-window acquire and the Laravel service wrapper around it.
Copy
Give positive feedback
Give negative feedback
Retry
You said: What will happen if there are two different types of rate limits?
You said: What will happen if there are two different types of rate limits?
What will happen if there are two different types of rate limits?
Search requests that have 5 requests per second
The other rate limit that has, let's say, 100 requests per 10 seconds How do these work together? Is there some conflict? Can I reach the limit with one request and block either as well, or are these separated? Can I still continue making search requests once I hit the normal requests limits?
13:40
Retry
Edit
Copy
Claude responded: They're independent buckets β with one shared bucket on top.
Claude responded: They're independent buckets β with one shared bucket on top.
Analyzed independent rate limit buckets and their practical interactions
Analyzed independent rate limit buckets and their practical interactions
They're independent buckets β with one shared bucket on top.
The three buckets and what each call hits
The three buckets and what each call hits
Copy to clipboard
ββββββββββββββββββββ
Search request βββ β Search: 5/sec β βββ
ββββββββββββββββββββ β
ββββ βββββββββββββββββββ
ββββββββββββββββββββ β β Daily: 250kβ1M β
Non-search call βββ β Burst: 190/10s β βββ β (per portal) β
ββββββββββββββββββββ βββββββββββββββββββ
A search call is only metered against the search bucket and the daily bucket. A non-search call (batch read/update, single PATCH, associations, etc.) is only metered against the burst bucket and the daily bucket. The two short-window buckets do not share counters.
What this means practically
What this means practically
Hitting search secondly limit (5/s):
Only further
/search
calls 429. Your batch reads, batch updates, single PATCHes, association calls β all keep working at full burst speed. This is actually useful: if your sync is bottlenecked on Search, you can pivot to using
lastmodifieddate
filters via batch endpoints, or use the IDs you already have to do batch reads, while Search cools off.
Hitting burst limit (190/10s):
Only non-search calls 429. You can still issue Search calls at 5/s. Useful for: continuing to identify deltas for queueing while in-flight updates drain, or refreshing a small set of records via Search even though your write pipeline is paused.
Hitting daily limit:
Everything stops. Search and non-search alike. Doesn't unblock until midnight in your portal's configured timezone β and remember this is shared across every private app in the portal, plus n8n flows, marketing tools, anything else hitting the API with that account.
So can one type of request block the other?
So can one type of request block the other?
Search β Burst:
No.
Saturating Search at 50 calls per 10s leaves your full 190/10s burst untouched.
Burst β Search:
No.
Saturating burst leaves Search's 5/s untouched.
Either β Daily:
Yes
, but only by contributing to the same daily counter. It's volume that kills you here, not the type.
In theory you can sustain ~50 search + ~190 other =
~240 calls per 10 seconds
indefinitely (until daily runs out), because the two buckets bill independently.
Implementation consequence
Implementation consequence
Your rate limiter needs to know which bucket a request hits before it acquires. Cleanest pattern:
Copy to clipboard
php
$limiter
->
acquire
(
'search'
,
$weight
=
1
)
;
// for search endpoints only
$limiter
->
acquire
(
'burst'
,
$weight
=
1
)
;
// for everything else
$limiter
->
acquire
(
'daily'
,
$weight
=
1
)
;
// every call, both kinds
In Redis: three separate keys, three separate Lua acquire scripts (or one script with a bucket parameter). A search call calls
acquire('search')
+
acquire('daily')
. A batch update calls
acquire('burst')
+
acquire('daily')
.
One subtle pitfall: when you backoff on a 429,
inspect
policyName
in the response body
to know which bucket actually fired. If you see
SECONDLY
from a search endpoint, you only need to delay search-bound jobs β burst-bound jobs in the queue can keep running. If you blanket-pause everything on any 429, you waste capacity on the bucket that's still healthy. Two queues (or two throttle keys) make this clean; one global pause is the lazy version.
The other subtlety: the burst response gives you
X-HubSpot-RateLimit-Remaining
to clamp local state against, but search doesn't return those headers. So your search counter is unverified β be slightly more conservative there (e.g., budget 4/s instead of 5) to absorb the unaccounted-for calls.
Copy
Give positive feedback
Give negative feedback
Retry
You said: Ok, so what will happen each time I make a request?
You said: Ok, so what will happen each time I make a request?
Ok, so what will happen each time I make a request? Let's say I have 100,000 requests to make that are instant. Do I need to increment each request based on the type? For example, if there is a search request, I need to increment both the search bucket and also the daily bucket. If it's a burst, then I can go to the daily and burst buckets. If I need to check if it can make a call, do I need to see both the daily and search, or burst, respectively? Isn't that too heavy for the infrastructure, adding additional load to each request?
13:44
Retry
Edit
Copy
Claude responded: Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out.
Claude responded: Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out.
Analyzed per-request overhead concerns and quantified Redis performance impact
Analyzed per-request overhead concerns and quantified Redis performance impact
Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out. But the overhead is much smaller than it sounds, and importantly, it's nowhere near your bottleneck.
What "two buckets per request" actually costs
What "two buckets per request" actually costs
Each request makes
one round trip to Redis
β not two β because you fold both bucket checks into a single Lua script that runs atomically server-side:
Copy to clipboard
lua
-- KEYS[1] = burst bucket key (or search)
-- KEYS[2] = daily bucket key
-- ARGV[1] = now (ms) ARGV[2] = window_ms
-- ARGV[3] = bucket_max ARGV[4] = daily_max
-- ARGV[5] = request_id ARGV[6] = daily_ttl
-- Trim sliding window
redis
.
call
(
'ZREMRANGEBYSCORE'
,
KEYS
[
1
]
,
0
,
ARGV
[
1
]
-
ARGV
[
2
]
)
local
burst_used
=
redis
.
call
(
'ZCARD'
,
KEYS
[
1
]
)
local
daily_used
=
tonumber
(
redis
.
call
(
'GET'
,
KEYS
[
2
]
)
or
'0'
)
if
burst_used
>=
tonumber
(
ARGV
[
3
]
)
then
-- Tell caller how long to sleep until oldest entry expires
local
oldest
=
redis
.
call
(...
|
Claude
|
Claude
|
NULL
|
4364
|
|
4363
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Share chat
Claude finished the response
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
how to work with multiple jobs
how to work with paginated requests Let's consider a situation when there are 600 opportunities to sync. What would be the flow? How would the rate limit be recognized? How would it be handled? What are the potential issues? [API usage guidelines and limits - HubSpot docs](
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
). Example of such a error Client error:
POST https://api.hubapi.com/crm/v3/objects/contact/search
resulted in a
429 Too Many Requests
response: {"status":"error","message":"You have reached your secondly limit.","errorType":"RATE_LIMIT","correlationId":"019dffc4-4 (truncated...). Think carefully about the implementation and potential issue and bottlenecks.
Show more
10:42
Retry
Edit
Copy
Claude responded: Current HubSpot limits (Apr 2026)
Claude responded: Current HubSpot limits (Apr 2026)
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Current HubSpot limits (Apr 2026)
Current HubSpot limits (Apr 2026)
For privately distributed apps (which is what Jiminny presumably uses with HubSpot), the limits are layered: a per-app burst window of 100/10s on Free/Starter, 190/10s on Pro/Enterprise, or 250/10s with the API Limit Increase add-on
, plus a per-account daily cap of 250k / 625k / 1M depending on tier β shared across all private apps in the account
. The burst window is per app; the daily quota is per portal.
hubspot
hubspot
hubspot
hubspot
The Search API is special: five requests per second per account, capped at 200 records per page, with a hard 10,000-result ceiling per query
. That's the limit the 429 in your example is hitting (
secondly limit
on
/crm/v3/objects/contact/search
). It's a separate bucket from the 190/10s, and critically, search responses do not include the
X-HubSpot-RateLimit-*
headers
β you can't read remaining capacity off the response, you have to track it yourself.
hubspot
hubspot
hubspot
hubspot
Non-search endpoints return
X-HubSpot-RateLimit-Remaining
,
-Max
, and
-Interval-Milliseconds
. The daily headers are not returned for OAuth-authenticated calls
, so for those you check the account-info endpoint or maintain your own counter. There's also a soft rule: errors should stay under 5% of total daily requests
β that's enforced for marketplace listing, but it's also a sane operational target.
hubspot
hubspot
hubspot
hubspot
So you have
four buckets
to track at minimum: app-burst (10s sliding), search-secondly (1s sliding), account-daily (24h fixed, midnight in HubSpot's TZ), and per-app daily share (your own budgeting on top of the account cap).
Where to store it
Where to store it
Redis. It's the only realistic option once you have multiple queue workers β DB-backed counters serialize too much, and in-process state can't coordinate across workers. Laravel already speaks Redis natively, and you get atomic
INCR
/
EXPIRE
plus Lua scripting for true CAS semantics.
Key layout I'd use:
Copy to clipboard
hubspot:rl:burst:{portalId}:{appId} ZSET (sliding 10s)
hubspot:rl:search:{portalId} ZSET (sliding 1s)
hubspot:rl:daily:{portalId} STRING + TTL to midnight TZ
hubspot:rl:meta:{portalId} HASH (last seen headers)
The two short-window buckets are sliding-window-log (Redis ZSET, score =
microtime
, member = unique request id). Lua script removes entries older than the window, counts remaining slots, and only adds the new one if there's room β all atomic. Fixed windows are simpler but allow 2Γ the limit at the boundary, which on a 5/s window is brutal.
The daily bucket is a plain
INCR
with TTL set to seconds-until-midnight in
HubSpot's account timezone
, not yours β Sofia is UTC+2/+3 but your portal might be set to US Eastern. Get this once and cache it.
How to read it
How to read it
Two-phase: optimistic pre-check, authoritative post-update.
Before a call, run the Lua acquire script. If it returns "denied," sleep until a slot frees up (the script can return ms-until-next-slot) or push the job back to the queue with a delay. Don't busy-loop.
After the call, parse
X-HubSpot-RateLimit-Remaining
/
-Max
/
-Interval-Milliseconds
and store them in
hubspot:rl:meta:{portalId}
. This is your reality check β if your local counter says 50 remaining but HubSpot's header says 5, you trust HubSpot and clamp your counter. This handles clock drift, missed accounting (e.g., crashed worker that took a token but never made the request), and other apps in the same account consuming the daily budget invisibly.
For search specifically, since headers don't come back, the local counter
is
the source of truth β meaning if you ever crash mid-flight, you've under-counted. Always release tokens on connection-level failure but
not
on 429 (you really did make that request).
How to work with multiple jobs
How to work with multiple jobs
The queue layer needs to enforce concurrency separately from the rate limiter. Both work together:
Concurrency cap
via
Queue::throttle()
or a Redis semaphore β limits how many sync workers run in parallel against HubSpot. Without this, you can have 50 workers all blocked waiting for tokens, which is wasteful and creates retry storms.
Per-tenant fairness
β if you sync many Jiminny customers into different HubSpot portals, each portal has its own bucket but you still want one slow portal not to starve others. Either separate queues per portal or a fair-share scheduler.
Priority lanes
β webhook-driven updates (user-visible latency) should outrank background batch syncs. Two queues:
hubspot-priority
and
hubspot-bulk
, with priority workers taking 70% of the burst budget and bulk taking 30% (enforce via separate sub-buckets if you really want hard separation, otherwise just pull from priority first).
Backoff on 429
β respect the
Retry-After
header. If absent, exponential with jitter (e.g.,
min(2^attempt * 250ms, 30s) Β± 20%
). The jitter is non-negotiable; without it, simultaneous 429s retry in lockstep and you get thundering-herd 429s on retry.
How to work with paginated requests
How to work with paginated requests
The trap is treating "fetch all" as one logical operation. Each page is its own API call and competes for tokens with everything else.
Two practical rules:
Don't hold the worker idle while paginating.
If page N takes 500ms and page N+1 needs to wait 800ms for a token, you've burned 800ms of worker time doing nothing. Instead, fetch page N, dispatch the
processing
of page N as a separate job, and queue a "fetch page N+1" job with a delay equal to the wait time. Each page becomes its own atomic unit.
Always batch where HubSpot offers it.
POST /crm/v3/objects/{type}/batch/{read|update|create}
accepts up to 100 IDs per call. For your "patching IDs" flow this is the difference between 600 calls and 6.
Walkthrough: 600 opportunities
Walkthrough: 600 opportunities
Naive flow (one PATCH per deal): 600 calls. At 190/10s that's ~32s of API time, well under daily. You'd hit burst easily without throttling. Plus likely 1-3 search calls upfront and N association calls.
Sane flow:
Identify deltas
β if you can avoid Search at all, do. Use
lastmodifieddate
filter on a single search if you must, paginate at limit=200. For 600 deals that's 3 search calls @ 5/s = ~600ms naturally throttled.
Batch read
current state β
POST /crm/v3/objects/deals/batch/read
with 100 IDs per call β 6 calls. Burst weight 6.
Compute diff
in your code (no API).
Batch update
β
POST /crm/v3/objects/deals/batch/update
with 100 per call β 6 calls.
Associations
β
POST /crm/v4/associations/{from}/{to}/batch/create
if needed β another few batch calls.
Total: ~15-20 API calls for 600 deals. Burst budget consumed: 20/190 over ~5s. Daily impact: trivial.
Recognition: pre-check denies if
<weight>
slots aren't free; on 429 the response surfaces
policyName
(DAILY/SECONDLY) β log it, push the job back with
Retry-After
delay, increment a metric so you can alarm on sustained 429 rate.
Pitfalls & bottlenecks worth pre-empting
Pitfalls & bottlenecks worth pre-empting
Daily quota is shared across the whole portal
, including any n8n flows, other private apps, marketing automation calling APIs, etc. Budget for ~70-80% of the documented limit, not 100%. Add an internal per-app daily cap so a runaway sync can't starve other apps.
Search is uniquely fragile
: separate 5/s bucket, no headers to read, 10k-result cap per query. If you ever hit 10k+ deals matching a filter, partition by
hs_object_id
ranges or by
lastmodifieddate
windows.
Retry storms after HubSpot incidents
β always jitter, always cap total retries (e.g., 5 attempts, then dead-letter).
Webhook β sync β webhook loops
β when your update fires a HubSpot webhook that triggers another sync. Tag your own writes (e.g., a custom property
jy_last_sync_id
) and ignore webhooks where it just changed.
Token refresh
β OAuth refresh itself counts against burst. Cache the access token in Redis with TTL =
expires_in - 60s
, single-flight the refresh (only one worker refreshes; others wait on a lock).
Search latency for fresh writes
β newly created/updated objects don't appear in search instantly. Don't write-then-search; use returned IDs directly.
Clock skew
β Redis is authoritative. Don't use
time()
from each worker for window scoring; use
redis.call('TIME')
inside the Lua script.
Dead workers with held tokens
β sliding-window-log handles this naturally because tokens expire by score; token-bucket implementations need explicit release-on-crash logic.
The 5% error rule
counts every 429 toward your error budget, even successfully retried ones. If your pre-check is working well, 429s should be near zero β if they're not, your pre-check is wrong, not just slow.
Phantom contention with Laravel
RateLimited
middleware
: it's per-job-class by default, not per-portal. If your
SyncDealJob
and
UpdateActivityJob
are different classes both calling HubSpot, they don't share a Laravel-level limiter β you need a single
HubspotRateLimiter
service that everything routes through.
If you want, I can sketch the Lua script for the sliding-window acquire and the Laravel service wrapper around it.
Copy
Give positive feedback
Give negative feedback
Retry
You said: What will happen if there are two different types of rate limits?
You said: What will happen if there are two different types of rate limits?
What will happen if there are two different types of rate limits?
Search requests that have 5 requests per second
The other rate limit that has, let's say, 100 requests per 10 seconds How do these work together? Is there some conflict? Can I reach the limit with one request and block either as well, or are these separated? Can I still continue making search requests once I hit the normal requests limits?
13:40
Retry
Edit
Copy
Claude responded: They're independent buckets β with one shared bucket on top.
Claude responded: They're independent buckets β with one shared bucket on top.
Analyzed independent rate limit buckets and their practical interactions
Analyzed independent rate limit buckets and their practical interactions
They're independent buckets β with one shared bucket on top.
The three buckets and what each call hits
The three buckets and what each call hits
Copy to clipboard
ββββββββββββββββββββ
Search request βββ β Search: 5/sec β βββ
ββββββββββββββββββββ β
ββββ βββββββββββββββββββ
ββββββββββββββββββββ β β Daily: 250kβ1M β
Non-search call βββ β Burst: 190/10s β βββ β (per portal) β
ββββββββββββββββββββ βββββββββββββββββββ
A search call is only metered against the search bucket and the daily bucket. A non-search call (batch read/update, single PATCH, associations, etc.) is only metered against the burst bucket and the daily bucket. The two short-window buckets do not share counters.
What this means practically
What this means practically
Hitting search secondly limit (5/s):
Only further
/search
calls 429. Your batch reads, batch updates, single PATCHes, association calls β all keep working at full burst speed. This is actually useful: if your sync is bottlenecked on Search, you can pivot to using
lastmodifieddate
filters via batch endpoints, or use the IDs you already have to do batch reads, while Search cools off.
Hitting burst limit (190/10s):
Only non-search calls 429. You can still issue Search calls at 5/s. Useful for: continuing to identify deltas for queueing while in-flight updates drain, or refreshing a small set of records via Search even though your write pipeline is paused.
Hitting daily limit:
Everything stops. Search and non-search alike. Doesn't unblock until midnight in your portal's configured timezone β and remember this is shared across every private app in the portal, plus n8n flows, marketing tools, anything else hitting the API with that account.
So can one type of request block the other?
So can one type of request block the other?
Search β Burst:
No.
Saturating Search at 50 calls per 10s leaves your full 190/10s burst untouched.
Burst β Search:
No.
Saturating burst leaves Search's 5/s untouched.
Either β Daily:
Yes
, but only by contributing to the same daily counter. It's volume that kills you here, not the type.
In theory you can sustain ~50 search + ~190 other =
~240 calls per 10 seconds
indefinitely (until daily runs out), because the two buckets bill independently.
Implementation consequence
Implementation consequence
Your rate limiter needs to know which bucket a request hits before it acquires. Cleanest pattern:
Copy to clipboard
php
$limiter
->
acquire
(
'search'
,
$weight
=
1
)
;
// for search endpoints only
$limiter
->
acquire
(
'burst'
,
$weight
=
1
)
;
// for everything else
$limiter
->
acquire
(
'daily'
,
$weight
=
1
)
;
// every call, both kinds
In Redis: three separate keys, three separate Lua acquire scripts (or one script with a bucket parameter). A search call calls
acquire('search')
+
acquire('daily')
. A batch update calls
acquire('burst')
+
acquire('daily')
.
One subtle pitfall: when you backoff on a 429,
inspect
policyName
in the response body
to know which bucket actually fired. If you see
SECONDLY
from a search endpoint, you only need to delay search-bound jobs β burst-bound jobs in the queue can keep running. If you blanket-pause everything on any 429, you waste capacity on the bucket that's still healthy. Two queues (or two throttle keys) make this clean; one global pause is the lazy version.
The other subtlety: the burst response gives you
X-HubSpot-RateLimit-Remaining
to clamp local state against, but search doesn't return those headers. So your search counter is unverified β be slightly more conservative there (e.g., budget 4/s instead of 5) to absorb the unaccounted-for calls.
Copy
Give positive feedback
Give negative feedback
Retry
You said: Ok, so what will happen each time I make a request?
You said: Ok, so what will happen each time I make a request?
Ok, so what will happen each time I make a request? Let's say I have 100,000 requests to make that are instant. Do I need to increment each request based on the type? For example, if there is a search request, I need to increment both the search bucket and also the daily bucket. If it's a burst, then I can go to the daily and burst buckets. If I need to check if it can make a call, do I need to see both the daily and search, or burst, respectively? Isn't that too heavy for the infrastructure, adding additional load to each request?
13:44
Retry
Edit
Copy
Claude responded: Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out.
Claude responded: Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out.
Analyzed per-request overhead concerns and quantified Redis performance impact
Analyzed per-request overhead concerns and quantified Redis performance impact
Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out. But the overhead is much smaller than it sounds, and importantly, it's nowhere near your bottleneck.
What "two buckets per request" actually costs
What "two buckets per request" actually costs
Each request makes
one round trip to Redis
β not two β because you fold both bucket checks into a single Lua script that runs atomically server-side:
Copy to clipboard
lua
-- KEYS[1] = burst bucket key (or search)
-- KEYS[2] = daily bucket key
-- ARGV[1] = now (ms) ARGV[2] = window_ms
-- ARGV[3] = bucket_max ARGV[4] = daily_max
-- ARGV[5] = request_id ARGV[6] = daily_ttl
-- Trim sliding window
redis
.
call
(
'ZREMRANGEBYSCORE'
,
KEYS
[
1
]
,...
|
Claude
|
Claude
|
NULL
|
4363
|
|
4362
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Share chat
Claude finished the response
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
how to work with multiple jobs
how to work with paginated requests Let's consider a situation when there are 600 opportunities to sync. What would be the flow? How would the rate limit be recognized? How would it be handled? What are the potential issues? [API usage guidelines and limits - HubSpot docs](
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
). Example of such a error Client error:
POST https://api.hubapi.com/crm/v3/objects/contact/search
resulted in a
429 Too Many Requests
response: {"status":"error","message":"You have reached your secondly limit.","errorType":"RATE_LIMIT","correlationId":"019dffc4-4 (truncated...). Think carefully about the implementation and potential issue and bottlenecks.
Show more
10:42
Retry
Edit
Copy
Claude responded: Current HubSpot limits (Apr 2026)
Claude responded: Current HubSpot limits (Apr 2026)
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Current HubSpot limits (Apr 2026)
Current HubSpot limits (Apr 2026)
For privately distributed apps (which is what Jiminny presumably uses with HubSpot), the limits are layered: a per-app burst window of 100/10s on Free/Starter, 190/10s on Pro/Enterprise, or 250/10s with the API Limit Increase add-on
, plus a per-account daily cap of 250k / 625k / 1M depending on tier β shared across all private apps in the account
. The burst window is per app; the daily quota is per portal.
hubspot
hubspot
hubspot
hubspot
The Search API is special: five requests per second per account, capped at 200 records per page, with a hard 10,000-result ceiling per query
. That's the limit the 429 in your example is hitting (
secondly limit
on
/crm/v3/objects/contact/search
). It's a separate bucket from the 190/10s, and critically, search responses do not include the
X-HubSpot-RateLimit-*
headers
β you can't read remaining capacity off the response, you have to track it yourself.
hubspot
hubspot
hubspot
hubspot
Non-search endpoints return
X-HubSpot-RateLimit-Remaining
,
-Max
, and
-Interval-Milliseconds
. The daily headers are not returned for OAuth-authenticated calls
, so for those you check the account-info endpoint or maintain your own counter. There's also a soft rule: errors should stay under 5% of total daily requests
β that's enforced for marketplace listing, but it's also a sane operational target.
hubspot
hubspot
hubspot
hubspot
So you have
four buckets
to track at minimum: app-burst (10s sliding), search-secondly (1s sliding), account-daily (24h fixed, midnight in HubSpot's TZ), and per-app daily share (your own budgeting on top of the account cap).
Where to store it
Where to store it
Redis. It's the only realistic option once you have multiple queue workers β DB-backed counters serialize too much, and in-process state can't coordinate across workers. Laravel already speaks Redis natively, and you get atomic
INCR
/
EXPIRE
plus Lua scripting for true CAS semantics.
Key layout I'd use:
Copy to clipboard
hubspot:rl:burst:{portalId}:{appId} ZSET (sliding 10s)
hubspot:rl:search:{portalId} ZSET (sliding 1s)
hubspot:rl:daily:{portalId} STRING + TTL to midnight TZ
hubspot:rl:meta:{portalId} HASH (last seen headers)
The two short-window buckets are sliding-window-log (Redis ZSET, score =
microtime
, member = unique request id). Lua script removes entries older than the window, counts remaining slots, and only adds the new one if there's room β all atomic. Fixed windows are simpler but allow 2Γ the limit at the boundary, which on a 5/s window is brutal.
The daily bucket is a plain
INCR
with TTL set to seconds-until-midnight in
HubSpot's account timezone
, not yours β Sofia is UTC+2/+3 but your portal might be set to US Eastern. Get this once and cache it.
How to read it
How to read it
Two-phase: optimistic pre-check, authoritative post-update.
Before a call, run the Lua acquire script. If it returns "denied," sleep until a slot frees up (the script can return ms-until-next-slot) or push the job back to the queue with a delay. Don't busy-loop.
After the call, parse
X-HubSpot-RateLimit-Remaining
/
-Max
/
-Interval-Milliseconds
and store them in
hubspot:rl:meta:{portalId}
. This is your reality check β if your local counter says 50 remaining but HubSpot's header says 5, you trust HubSpot and clamp your counter. This handles clock drift, missed accounting (e.g., crashed worker that took a token but never made the request), and other apps in the same account consuming the daily budget invisibly.
For search specifically, since headers don't come back, the local counter
is
the source of truth β meaning if you ever crash mid-flight, you've under-counted. Always release tokens on connection-level failure but
not
on 429 (you really did make that request).
How to work with multiple jobs
How to work with multiple jobs
The queue layer needs to enforce concurrency separately from the rate limiter. Both work together:
Concurrency cap
via
Queue::throttle()
or a Redis semaphore β limits how many sync workers run in parallel against HubSpot. Without this, you can have 50 workers all blocked waiting for tokens, which is wasteful and creates retry storms.
Per-tenant fairness
β if you sync many Jiminny customers into different HubSpot portals, each portal has its own bucket but you still want one slow portal not to starve others. Either separate queues per portal or a fair-share scheduler.
Priority lanes
β webhook-driven updates (user-visible latency) should outrank background batch syncs. Two queues:
hubspot-priority
and
hubspot-bulk
, with priority workers taking 70% of the burst budget and bulk taking 30% (enforce via separate sub-buckets if you really want hard separation, otherwise just pull from priority first).
Backoff on 429
β respect the
Retry-After
header. If absent, exponential with jitter (e.g.,
min(2^attempt * 250ms, 30s) Β± 20%
). The jitter is non-negotiable; without it, simultaneous 429s retry in lockstep and you get thundering-herd 429s on retry.
How to work with paginated requests
How to work with paginated requests
The trap is treating "fetch all" as one logical operation. Each page is its own API call and competes for tokens with everything else.
Two practical rules:
Don't hold the worker idle while paginating.
If page N takes 500ms and page N+1 needs to wait 800ms for a token, you've burned 800ms of worker time doing nothing. Instead, fetch page N, dispatch the
processing
of page N as a separate job, and queue a "fetch page N+1" job with a delay equal to the wait time. Each page becomes its own atomic unit.
Always batch where HubSpot offers it.
POST /crm/v3/objects/{type}/batch/{read|update|create}
accepts up to 100 IDs per call. For your "patching IDs" flow this is the difference between 600 calls and 6.
Walkthrough: 600 opportunities
Walkthrough: 600 opportunities
Naive flow (one PATCH per deal): 600 calls. At 190/10s that's ~32s of API time, well under daily. You'd hit burst easily without throttling. Plus likely 1-3 search calls upfront and N association calls.
Sane flow:
Identify deltas
β if you can avoid Search at all, do. Use
lastmodifieddate
filter on a single search if you must, paginate at limit=200. For 600 deals that's 3 search calls @ 5/s = ~600ms naturally throttled.
Batch read
current state β
POST /crm/v3/objects/deals/batch/read
with 100 IDs per call β 6 calls. Burst weight 6.
Compute diff
in your code (no API).
Batch update
β
POST /crm/v3/objects/deals/batch/update
with 100 per call β 6 calls.
Associations
β
POST /crm/v4/associations/{from}/{to}/batch/create
if needed β another few batch calls.
Total: ~15-20 API calls for 600 deals. Burst budget consumed: 20/190 over ~5s. Daily impact: trivial.
Recognition: pre-check denies if
<weight>
slots aren't free; on 429 the response surfaces
policyName
(DAILY/SECONDLY) β log it, push the job back with
Retry-After
delay, increment a metric so you can alarm on sustained 429 rate.
Pitfalls & bottlenecks worth pre-empting
Pitfalls & bottlenecks worth pre-empting
Daily quota is shared across the whole portal
, including any n8n flows, other private apps, marketing automation calling APIs, etc. Budget for ~70-80% of the documented limit, not 100%. Add an internal per-app daily cap so a runaway sync can't starve other apps.
Search is uniquely fragile
: separate 5/s bucket, no headers to read, 10k-result cap per query. If you ever hit 10k+ deals matching a filter, partition by
hs_object_id
ranges or by
lastmodifieddate
windows.
Retry storms after HubSpot incidents
β always jitter, always cap total retries (e.g., 5 attempts, then dead-letter).
Webhook β sync β webhook loops
β when your update fires a HubSpot webhook that triggers another sync. Tag your own writes (e.g., a custom property
jy_last_sync_id
) and ignore webhooks where it just changed.
Token refresh
β OAuth refresh itself counts against burst. Cache the access token in Redis with TTL =
expires_in - 60s
, single-flight the refresh (only one worker refreshes; others wait on a lock).
Search latency for fresh writes
β newly created/updated objects don't appear in search instantly. Don't write-then-search; use returned IDs directly.
Clock skew
β Redis is authoritative. Don't use
time()
from each worker for window scoring; use
redis.call('TIME')
inside the Lua script.
Dead workers with held tokens
β sliding-window-log handles this naturally because tokens expire by score; token-bucket implementations need explicit release-on-crash logic.
The 5% error rule
counts every 429 toward your error budget, even successfully retried ones. If your pre-check is working well, 429s should be near zero β if they're not, your pre-check is wrong, not just slow.
Phantom contention with Laravel
RateLimited
middleware
: it's per-job-class by default, not per-portal. If your
SyncDealJob
and
UpdateActivityJob
are different classes both calling HubSpot, they don't share a Laravel-level limiter β you need a single
HubspotRateLimiter
service that everything routes through.
If you want, I can sketch the Lua script for the sliding-window acquire and the Laravel service wrapper around it.
Copy
Give positive feedback
Give negative feedback
Retry
You said: What will happen if there are two different types of rate limits?
You said: What will happen if there are two different types of rate limits?
What will happen if there are two different types of rate limits?
Search requests that have 5 requests per second
The other rate limit that has, let's say, 100 requests per 10 seconds How do these work together? Is there some conflict? Can I reach the limit with one request and block either as well, or are these separated? Can I still continue making search requests once I hit the normal requests limits?
13:40
Retry
Edit
Copy
Claude responded: They're independent buckets β with one shared bucket on top.
Claude responded: They're independent buckets β with one shared bucket on top.
Analyzed independent rate limit buckets and their practical interactions
Analyzed independent rate limit buckets and their practical interactions
They're independent buckets β with one shared bucket on top.
The three buckets and what each call hits
The three buckets and what each call hits
Copy to clipboard
ββββββββββββββββββββ
Search request βββ β Search: 5/sec β βββ
ββββββββββββββββββββ β
ββββ βββββββββββββββββββ
ββββββββββββββββββββ β β Daily: 250kβ1M β
Non-search call βββ β Burst: 190/10s β βββ β (per portal) β
ββββββββββββββββββββ βββββββββββββββββββ
A search call is only metered against the search bucket and the daily bucket. A non-search call (batch read/update, single PATCH, associations, etc.) is only metered against the burst bucket and the daily bucket. The two short-window buckets do not share counters.
What this means practically
What this means practically
Hitting search secondly limit (5/s):
Only further
/search
calls 429. Your batch reads, batch updates, single PATCHes, association calls β all keep working at full burst speed. This is actually useful: if your sync is bottlenecked on Search, you can pivot to using
lastmodifieddate
filters via batch endpoints, or use the IDs you already have to do batch reads, while Search cools off.
Hitting burst limit (190/10s):
Only non-search calls 429. You can still issue Search calls at 5/s. Useful for: continuing to identify deltas for queueing while in-flight updates drain, or refreshing a small set of records via Search even though your write pipeline is paused.
Hitting daily limit:
Everything stops. Search and non-search alike. Doesn't unblock until midnight in your portal's configured timezone β and remember this is shared across every private app in the portal, plus n8n flows, marketing tools, anything else hitting the API with that account.
So can one type of request block the other?
So can one type of request block the other?
Search β Burst:
No.
Saturating Search at 50 calls per 10s leaves your full 190/10s burst untouched.
Burst β Search:
No.
Saturating burst leaves Search's 5/s untouched.
Either β Daily:
Yes
, but only by contributing to the same daily counter. It's volume that kills you here, not the type.
In theory you can sustain ~50 search + ~190 other =
~240 calls per 10 seconds
indefinitely (until daily runs out), because the two buckets bill independently.
Implementation consequence
Implementation consequence
Your rate limiter needs to know which bucket a request hits before it acquires. Cleanest pattern:
Copy to clipboard
php
$limiter
->
acquire
(
'search'
,
$weight
=
1
)
;
// for search endpoints only
$limiter
->
acquire
(
'burst'
,
$weight
=
1
)
;
// for everything else
$limiter
->
acquire
(
'daily'
,
$weight
=
1
)
;
// every call, both kinds
In Redis: three separate keys, three separate Lua acquire scripts (or one script with a bucket parameter). A search call calls
acquire('search')
+
acquire('daily')
. A batch update calls
acquire('burst')
+
acquire('daily')
.
One subtle pitfall: when you backoff on a 429,
inspect
policyName
in the response body
to know which bucket actually fired. If you see
SECONDLY
from a search endpoint, you only need to delay search-bound jobs β burst-bound jobs in the queue can keep running. If you blanket-pause everything on any 429, you waste capacity on the bucket that's still healthy. Two queues (or two throttle keys) make this clean; one global pause is the lazy version.
The other subtlety: the burst response gives you
X-HubSpot-RateLimit-Remaining
to clamp local state against, but search doesn't return those headers. So your search counter is unverified β be slightly more conservative there (e.g., budget 4/s instead of 5) to absorb the unaccounted-for calls.
Copy...
|
Claude
|
Claude
|
NULL
|
4362
|
|
4361
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Share chat
Claude finished the response
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
how to work with multiple jobs
how to work with paginated requests Let's consider a situation when there are 600 opportunities to sync. What would be the flow? How would the rate limit be recognized? How would it be handled? What are the potential issues? [API usage guidelines and limits - HubSpot docs](
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
). Example of such a error Client error:
POST https://api.hubapi.com/crm/v3/objects/contact/search
resulted in a
429 Too Many Requests
response: {"status":"error","message":"You have reached your secondly limit.","errorType":"RATE_LIMIT","correlationId":"019dffc4-4 (truncated...). Think carefully about the implementation and potential issue and bottlenecks.
Show more
10:42
Retry
Edit
Copy
Claude responded: Current HubSpot limits (Apr 2026)
Claude responded: Current HubSpot limits (Apr 2026)
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Current HubSpot limits (Apr 2026)
Current HubSpot limits (Apr 2026)
For privately distributed apps (which is what Jiminny presumably uses with HubSpot), the limits are layered: a per-app burst window of 100/10s on Free/Starter, 190/10s on Pro/Enterprise, or 250/10s with the API Limit Increase add-on
, plus a per-account daily cap of 250k / 625k / 1M depending on tier β shared across all private apps in the account
. The burst window is per app; the daily quota is per portal.
hubspot
hubspot
hubspot
hubspot
The Search API is special: five requests per second per account, capped at 200 records per page, with a hard 10,000-result ceiling per query
. That's the limit the 429 in your example is hitting (
secondly limit
on
/crm/v3/objects/contact/search
). It's a separate bucket from the 190/10s, and critically, search responses do not include the
X-HubSpot-RateLimit-*
headers
β you can't read remaining capacity off the response, you have to track it yourself.
hubspot
hubspot
hubspot
hubspot
Non-search endpoints return
X-HubSpot-RateLimit-Remaining
,
-Max
, and
-Interval-Milliseconds
. The daily headers are not returned for OAuth-authenticated calls
, so for those you check the account-info endpoint or maintain your own counter. There's also a soft rule: errors should stay under 5% of total daily requests
β that's enforced for marketplace listing, but it's also a sane operational target.
hubspot
hubspot
hubspot
hubspot
So you have
four buckets
to track at minimum: app-burst (10s sliding), search-secondly (1s sliding), account-daily (24h fixed, midnight in HubSpot's TZ), and per-app daily share (your own budgeting on top of the account cap).
Where to store it
Where to store it
Redis. It's the only realistic option once you have multiple queue workers β DB-backed counters serialize too much, and in-process state can't coordinate across workers. Laravel already speaks Redis natively, and you get atomic
INCR
/
EXPIRE
plus Lua scripting for true CAS semantics.
Key layout I'd use:
Copy to clipboard
hubspot:rl:burst:{portalId}:{appId} ZSET (sliding 10s)
hubspot:rl:search:{portalId} ZSET (sliding 1s)
hubspot:rl:daily:{portalId} STRING + TTL to midnight TZ
hubspot:rl:meta:{portalId} HASH (last seen headers)
The two short-window buckets are sliding-window-log (Redis ZSET, score =
microtime
, member = unique request id). Lua script removes entries older than the window, counts remaining slots, and only adds the new one if there's room β all atomic. Fixed windows are simpler but allow 2Γ the limit at the boundary, which on a 5/s window is brutal.
The daily bucket is a plain
INCR
with TTL set to seconds-until-midnight in
HubSpot's account timezone
, not yours β Sofia is UTC+2/+3 but your portal might be set to US Eastern. Get this once and cache it.
How to read it
How to read it
Two-phase: optimistic pre-check, authoritative post-update.
Before a call, run the Lua acquire script. If it returns "denied," sleep until a slot frees up (the script can return ms-until-next-slot) or push the job back to the queue with a delay. Don't busy-loop.
After the call, parse
X-HubSpot-RateLimit-Remaining
/
-Max
/
-Interval-Milliseconds
and store them in
hubspot:rl:meta:{portalId}
. This is your reality check β if your local counter says 50 remaining but HubSpot's header says 5, you trust HubSpot and clamp your counter. This handles clock drift, missed accounting (e.g., crashed worker that took a token but never made the request), and other apps in the same account consuming the daily budget invisibly.
For search specifically, since headers don't come back, the local counter
is
the source of truth β meaning if you ever crash mid-flight, you've under-counted. Always release tokens on connection-level failure but
not
on 429 (you really did make that request).
How to work with multiple jobs
How to work with multiple jobs
The queue layer needs to enforce concurrency separately from the rate limiter. Both work together:
Concurrency cap
via
Queue::throttle()
or a Redis semaphore β limits how many sync workers run in parallel against HubSpot. Without this, you can have 50 workers all blocked waiting for tokens, which is wasteful and creates retry storms.
Per-tenant fairness
β if you sync many Jiminny customers into different HubSpot portals, each portal has its own bucket but you still want one slow portal not to starve others. Either separate queues per portal or a fair-share scheduler.
Priority lanes
β webhook-driven updates (user-visible latency) should outrank background batch syncs. Two queues:
hubspot-priority
and
hubspot-bulk
, with priority workers taking 70% of the burst budget and bulk taking 30% (enforce via separate sub-buckets if you really want hard separation, otherwise just pull from priority first).
Backoff on 429
β respect the
Retry-After
header. If absent, exponential with jitter (e.g.,
min(2^attempt * 250ms, 30s) Β± 20%
). The jitter is non-negotiable; without it, simultaneous 429s retry in lockstep and you get thundering-herd 429s on retry.
How to work with paginated requests
How to work with paginated requests
The trap is treating "fetch all" as one logical operation. Each page is its own API call and competes for tokens with everything else.
Two practical rules:
Don't hold the worker idle while paginating.
If page N takes 500ms and page N+1 needs to wait 800ms for a token, you've burned 800ms of worker time doing nothing. Instead, fetch page N, dispatch the
processing
of page N as a separate job, and queue a "fetch page N+1" job with a delay equal to the wait time. Each page becomes its own atomic unit.
Always batch where HubSpot offers it.
POST /crm/v3/objects/{type}/batch/{read|update|create}
accepts up to 100 IDs per call. For your "patching IDs" flow this is the difference between 600 calls and 6.
Walkthrough: 600 opportunities
Walkthrough: 600 opportunities
Naive flow (one PATCH per deal): 600 calls. At 190/10s that's ~32s of API time, well under daily. You'd hit burst easily without throttling. Plus likely 1-3 search calls upfront and N association calls.
Sane flow:
Identify deltas
β if you can avoid Search at all, do. Use
lastmodifieddate
filter on a single search if you must, paginate at limit=200. For 600 deals that's 3 search calls @ 5/s = ~600ms naturally throttled.
Batch read
current state β
POST /crm/v3/objects/deals/batch/read
with 100 IDs per call β 6 calls. Burst weight 6.
Compute diff
in your code (no API).
Batch update
β
POST /crm/v3/objects/deals/batch/update
with 100 per call β 6 calls.
Associations
β
POST /crm/v4/associations/{from}/{to}/batch/create
if needed β another few batch calls.
Total: ~15-20 API calls for 600 deals. Burst budget consumed: 20/190 over ~5s. Daily impact: trivial.
Recognition: pre-check denies if
<weight>
slots aren't free; on 429 the response surfaces
policyName
(DAILY/SECONDLY) β log it, push the job back with
Retry-After
delay, increment a metric so you can alarm on sustained 429 rate.
Pitfalls & bottlenecks worth pre-empting
Pitfalls & bottlenecks worth pre-empting
Daily quota is shared across the whole portal
, including any n8n flows, other private apps, marketing automation calling APIs, etc. Budget for ~70-80% of the documented limit, not 100%. Add an internal per-app daily cap so a runaway sync can't starve other apps.
Search is uniquely fragile
: separate 5/s bucket, no headers to read, 10k-result cap per query. If you ever hit 10k+ deals matching a filter, partition by
hs_object_id
ranges or by
lastmodifieddate
windows.
Retry storms after HubSpot incidents
β always jitter, always cap total retries (e.g., 5 attempts, then dead-letter).
Webhook β sync β webhook loops
β when your update fires a HubSpot webhook that triggers another sync. Tag your own writes (e.g., a custom property
jy_last_sync_id
) and ignore webhooks where it just changed.
Token refresh
β OAuth refresh itself counts against burst. Cache the access token in Redis with TTL =
expires_in - 60s
, single-flight the refresh (only one worker refreshes; others wait on a lock).
Search latency for fresh writes
β newly created/updated objects don't appear in search instantly. Don't write-then-search; use returned IDs directly.
Clock skew
β Redis is authoritative. Don't use
time()
from each worker for window scoring; use
redis.call('TIME')
inside the Lua script.
Dead workers with held tokens
β sliding-window-log handles this naturally because tokens expire by score; token-bucket implementations need explicit release-on-crash logic.
The 5% error rule
counts every 429 toward your error budget, even successfully retried ones. If your pre-check is working well, 429s should be near zero β if they're not, your pre-check is wrong, not just slow.
Phantom contention with Laravel
RateLimited
middleware
: it's per-job-class by default, not per-portal. If your
SyncDealJob
and
UpdateActivityJob
are different classes both calling HubSpot, they don't share a Laravel-level limiter β you need a single
HubspotRateLimiter
service that everything routes through.
If you want, I can sketch the Lua script for the sliding-window acquire and the Laravel service wrapper around it.
Copy
Give positive feedback
Give negative feedback
Retry
You said: What will happen if there are two different types of rate limits?
You said: What will happen if there are two different types of rate limits?
What will happen if there are two different types of rate limits?
Search requests that have 5 requests per second
The other rate limit that has, let's say, 100 requests per 10 seconds How do these work together? Is there some conflict? Can I reach the limit with one request and block either as well, or are these separated? Can I still continue making search requests once I hit the normal requests limits?
13:40
Retry
Edit
Copy
Claude responded: They're independent buckets β with one shared bucket on top.
Claude responded: They're independent buckets β with one shared bucket on top.
Analyzed independent rate limit buckets and their practical interactions
Analyzed independent rate limit buckets and their practical interactions
They're independent buckets β with one shared bucket on top.
The three buckets and what each call hits
The three buckets and what each call hits
Copy to clipboard
ββββββββββββββββββββ
Search request βββ β Search: 5/sec β βββ
ββββββββββββββββββββ β
ββββ βββββββββββββββββββ
ββββββββββββββββββββ β β Daily: 250kβ1M β
Non-search call βββ β Burst: 190/10s β βββ β (per portal) β
ββββββββββββββββββββ βββββββββββββββββββ
A search call is only metered against the search bucket and the daily bucket. A non-search call (batch read/update, single PATCH, associations, etc.) is only metered against the burst bucket and the daily bucket. The two short-window buckets do not share counters.
What this means practically
What this means practically
Hitting search secondly limit (5/s):
Only further
/search
calls 429. Your batch reads, batch updates, single PATCHes, association calls β all keep working at full burst speed. This is actually useful: if your sync is bottlenecked on Search, you can pivot to using
lastmodifieddate
filters via batch endpoints, or use the IDs you already have to do batch reads, while Search cools off.
Hitting burst limit (190/10s):
Only non-search calls 429. You can still issue Search calls at 5/s. Useful for: continuing to identify deltas for queueing while in-flight updates drain, or refreshing a small set of records via Search even though your write pipeline is paused.
Hitting daily limit:
Everything stops. Search and non-search alike. Doesn't unblock until midnight in your portal's configured timezone β and remember this is shared across every private app in the portal, plus n8n flows, marketing tools, anything else hitting the API with that account.
So can one type of request block the other?
So can one type of request block the other?
Search β Burst:
No.
Saturating Search at 50 calls per 10s leaves your full 190/10s burst untouched.
Burst β Search:
No.
Saturating burst leaves Search's 5/s untouched.
Either β Daily:
Yes
, but only by contributing to the same daily counter. It's volume that kills you here, not the type.
In theory you can sustain ~50 search + ~190 other =
~240 calls per 10 seconds
indefinitely (until daily runs out), because the two buckets bill independently.
Implementation consequence
Implementation consequence
Your rate limiter needs to know which bucket a request hits before it acquires. Cleanest pattern:
Copy to clipboard
php
$limiter
->
acquire
(
'search'
,
$weight
=
1
)
;
// for search endpoints only
$limiter
->
acquire
(
'burst'
,
$weight
=
1
)
;
// for everything else
$limiter
->
acquire
(
'daily'
,
$weight
=
1
)
;
// every call, both kinds
In Redis: three separate keys, three separate Lua acquire scripts (or one script with a bucket parameter). A search call calls
acquire('search')
+
acquire('daily')
. A batch update calls
acquire('burst')
+
acquire('daily')
.
One subtle pitfall: when you backoff on a 429,
inspect
policyName
in the response body
to know which bucket actually fired. If you see
SECONDLY
from a search endpoint, you only need to delay search-bound jobs β burst-bound jobs in the queue can keep running. If you blanket-pause everything on any 429, you waste capacity on the bucket that's still healthy. Two queues (or two throttle keys) make this clean; one global pause is the lazy version.
The other subtlety: the burst response gives you
X-HubSpot-RateLimit-Remaining
to clamp local state against, but search doesn't return those headers. So your search counter is unverified β be slightly more conservative there (e.g., budget 4/s instead of 5) to absorb the unaccounted-for calls.
Copy
Give positive feedback
Give negative feedback
Retry
You said: Ok, so what will happen each time I make a request?
You said: Ok, so what will happen each time I make a request?
Ok, so what will happen each time I make a request? Let's say I have 100,000 requests to make that are instant. Do I need to increment each request based on the type? For example, if there is a search request, I need to increment both the search bucket and also the daily bucket. If it's a burst, then I can go to the daily and burst buckets. If I need to check if it can make a call, do I need to see both the daily and search, or burst, respectively? Isn't that too heavy for the infrastructure, adding additional load to each request?
13:44
Retry
Edit
Copy
Claude responded: Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out.
Claude responded: Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out.
Analyzed per-request overhead concerns and quantified Redis performance impact
Analyzed per-request overhead concerns and quantified Redis performance impact
Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out. But the overhead is much smaller than it sounds, and importantly, it's nowhere near your bottleneck.
What "two buckets per request" actually costs
What "two buckets per request" actually costs
Each request makes
one round trip to Redis
β not two β because you fold both bucket checks into a single Lua script that runs atomically server-side:
Copy to clipboard
lua
-- KEYS[1] = burst bucket key (or search)
-- KEYS[2] = daily bucket key
-- ARGV[1] = now (ms) ARGV[2] = window_ms
-- ARGV[3] = bucket_max ARGV[4] = daily_max
-- ARGV[5] = request_id ARGV[6] = daily_ttl
-- Trim sliding window
redis
.
call
(
'ZREMRANGEBYSCORE'
,
KEYS
[
1
]
,
0
,
ARGV
[
1
]
-
ARGV
[
2...
|
Claude
|
Claude
|
NULL
|
4361
|
|
4360
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Share chat
Claude finished the response
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
how to work with multiple jobs
how to work with paginated requests Let's consider a situation when there are 600 opportunities to sync. What would be the flow? How would the rate limit be recognized? How would it be handled? What are the potential issues? [API usage guidelines and limits - HubSpot docs](
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
). Example of such a error Client error:
POST https://api.hubapi.com/crm/v3/objects/contact/search
resulted in a
429 Too Many Requests
response: {"status":"error","message":"You have reached your secondly limit.","errorType":"RATE_LIMIT","correlationId":"019dffc4-4 (truncated...). Think carefully about the implementation and potential issue and bottlenecks.
Show more
10:42
Retry
Edit
Copy
Claude responded: Current HubSpot limits (Apr 2026)
Claude responded: Current HubSpot limits (Apr 2026)
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Current HubSpot limits (Apr 2026)
Current HubSpot limits (Apr 2026)
For privately distributed apps (which is what Jiminny presumably uses with HubSpot), the limits are layered: a per-app burst window of 100/10s on Free/Starter, 190/10s on Pro/Enterprise, or 250/10s with the API Limit Increase add-on
, plus a per-account daily cap of 250k / 625k / 1M depending on tier β shared across all private apps in the account
. The burst window is per app; the daily quota is per portal.
hubspot
hubspot
hubspot
hubspot
The Search API is special: five requests per second per account, capped at 200 records per page, with a hard 10,000-result ceiling per query
. That's the limit the 429 in your example is hitting (
secondly limit
on
/crm/v3/objects/contact/search
). It's a separate bucket from the 190/10s, and critically, search responses do not include the
X-HubSpot-RateLimit-*
headers
β you can't read remaining capacity off the response, you have to track it yourself.
hubspot
hubspot
hubspot
hubspot
Non-search endpoints return
X-HubSpot-RateLimit-Remaining
,
-Max
, and
-Interval-Milliseconds
. The daily headers are not returned for OAuth-authenticated calls
, so for those you check the account-info endpoint or maintain your own counter. There's also a soft rule: errors should stay under 5% of total daily requests
β that's enforced for marketplace listing, but it's also a sane operational target.
hubspot
hubspot
hubspot
hubspot
So you have
four buckets
to track at minimum: app-burst (10s sliding), search-secondly (1s sliding), account-daily (24h fixed, midnight in HubSpot's TZ), and per-app daily share (your own budgeting on top of the account cap).
Where to store it
Where to store it
Redis. It's the only realistic option once you have multiple queue workers β DB-backed counters serialize too much, and in-process state can't coordinate across workers. Laravel already speaks Redis natively, and you get atomic
INCR
/
EXPIRE
plus Lua scripting for true CAS semantics.
Key layout I'd use:
Copy to clipboard
hubspot:rl:burst:{portalId}:{appId} ZSET (sliding 10s)
hubspot:rl:search:{portalId} ZSET (sliding 1s)
hubspot:rl:daily:{portalId} STRING + TTL to midnight TZ
hubspot:rl:meta:{portalId} HASH (last seen headers)
The two short-window buckets are sliding-window-log (Redis ZSET, score =
microtime
, member = unique request id). Lua script removes entries older than the window, counts remaining slots, and only adds the new one if there's room β all atomic. Fixed windows are simpler but allow 2Γ the limit at the boundary, which on a 5/s window is brutal.
The daily bucket is a plain
INCR
with TTL set to seconds-until-midnight in
HubSpot's account timezone
, not yours β Sofia is UTC+2/+3 but your portal might be set to US Eastern. Get this once and cache it.
How to read it
How to read it
Two-phase: optimistic pre-check, authoritative post-update.
Before a call, run the Lua acquire script. If it returns "denied," sleep until a slot frees up (the script can return ms-until-next-slot) or push the job back to the queue with a delay. Don't busy-loop.
After the call, parse
X-HubSpot-RateLimit-Remaining
/
-Max
/
-Interval-Milliseconds
and store them in
hubspot:rl:meta:{portalId}
. This is your reality check β if your local counter says 50 remaining but HubSpot's header says 5, you trust HubSpot and clamp your counter. This handles clock drift, missed accounting (e.g., crashed worker that took a token but never made the request), and other apps in the same account consuming the daily budget invisibly.
For search specifically, since headers don't come back, the local counter
is
the source of truth β meaning if you ever crash mid-flight, you've under-counted. Always release tokens on connection-level failure but
not
on 429 (you really did make that request).
How to work with multiple jobs
How to work with multiple jobs
The queue layer needs to enforce concurrency separately from the rate limiter. Both work together:
Concurrency cap
via
Queue::throttle()
or a Redis semaphore β limits how many sync workers run in parallel against HubSpot. Without this, you can have 50 workers all blocked waiting for tokens, which is wasteful and creates retry storms.
Per-tenant fairness
β if you sync many Jiminny customers into different HubSpot portals, each portal has its own bucket but you still want one slow portal not to starve others. Either separate queues per portal or a fair-share scheduler.
Priority lanes
β webhook-driven updates (user-visible latency) should outrank background batch syncs. Two queues:
hubspot-priority
and
hubspot-bulk
, with priority workers taking 70% of the burst budget and bulk taking 30% (enforce via separate sub-buckets if you really want hard separation, otherwise just pull from priority first).
Backoff on 429
β respect the
Retry-After
header. If absent, exponential with jitter (e.g.,
min(2^attempt * 250ms, 30s) Β± 20%
). The jitter is non-negotiable; without it, simultaneous 429s retry in lockstep and you get thundering-herd 429s on retry.
How to work with paginated requests
How to work with paginated requests
The trap is treating "fetch all" as one logical operation. Each page is its own API call and competes for tokens with everything else.
Two practical rules:
Don't hold the worker idle while paginating.
If page N takes 500ms and page N+1 needs to wait 800ms for a token, you've burned 800ms of worker time doing nothing. Instead, fetch page N, dispatch the
processing
of page N as a separate job, and queue a "fetch page N+1" job with a delay equal to the wait time. Each page becomes its own atomic unit.
Always batch where HubSpot offers it.
POST /crm/v3/objects/{type}/batch/{read|update|create}
accepts up to 100 IDs per call. For your "patching IDs" flow this is the difference between 600 calls and 6.
Walkthrough: 600 opportunities
Walkthrough: 600 opportunities
Naive flow (one PATCH per deal): 600 calls. At 190/10s that's ~32s of API time, well under daily. You'd hit burst easily without throttling. Plus likely 1-3 search calls upfront and N association calls.
Sane flow:
Identify deltas
β if you can avoid Search at all, do. Use
lastmodifieddate
filter on a single search if you must, paginate at limit=200. For 600 deals that's 3 search calls @ 5/s = ~600ms naturally throttled.
Batch read
current state β
POST /crm/v3/objects/deals/batch/read
with 100 IDs per call β 6 calls. Burst weight 6.
Compute diff
in your code (no API).
Batch update
β
POST /crm/v3/objects/deals/batch/update
with 100 per call β 6 calls.
Associations
β
POST /crm/v4/associations/{from}/{to}/batch/create
if needed β another few batch calls.
Total: ~15-20 API calls for 600 deals. Burst budget consumed: 20/190 over ~5s. Daily impact: trivial.
Recognition: pre-check denies if
<weight>
slots aren't free; on 429 the response surfaces
policyName
(DAILY/SECONDLY) β log it, push the job back with
Retry-After
delay, increment a metric so you can alarm on sustained 429 rate.
Pitfalls & bottlenecks worth pre-empting
Pitfalls & bottlenecks worth pre-empting
Daily quota is shared across the whole portal
, including any n8n flows, other private apps, marketing automation calling APIs, etc. Budget for ~70-80% of the documented limit, not 100%. Add an internal per-app daily cap so a runaway sync can't starve other apps.
Search is uniquely fragile
: separate 5/s bucket, no headers to read, 10k-result cap per query. If you ever hit 10k+ deals matching a filter, partition by
hs_object_id
ranges or by
lastmodifieddate
windows.
Retry storms after HubSpot incidents
β always jitter, always cap total retries (e.g., 5 attempts, then dead-letter).
Webhook β sync β webhook loops
β when your update fires a HubSpot webhook that triggers another sync. Tag your own writes (e.g., a custom property
jy_last_sync_id
) and ignore webhooks where it just changed.
Token refresh
β OAuth refresh itself counts against burst. Cache the access token in Redis with TTL =
expires_in - 60s
, single-flight the refresh (only one worker refreshes; others wait on a lock).
Search latency for fresh writes
β newly created/updated objects don't appear in search instantly. Don't write-then-search; use returned IDs directly.
Clock skew
β Redis is authoritative. Don't use
time()
from each worker for window scoring; use
redis.call('TIME')
inside the Lua script.
Dead workers with held tokens
β sliding-window-log handles this naturally because tokens expire by score; token-bucket implementations need explicit release-on-crash logic.
The 5% error rule
counts every 429 toward your error budget, even successfully retried ones. If your pre-check is working well, 429s should be near zero β if they're not, your pre-check is wrong, not just slow.
Phantom contention with Laravel
RateLimited
middleware
: it's per-job-class by default, not per-portal. If your
SyncDealJob
and
UpdateActivityJob
are different classes both calling HubSpot, they don't share a Laravel-level limiter β you need a single
HubspotRateLimiter
service that everything routes through.
If you want, I can sketch the Lua script for the sliding-window acquire and the Laravel service wrapper around it.
Copy
Give positive feedback
Give negative feedback
Retry
You said: What will happen if there are two different types of rate limits?
You said: What will happen if there are two different types of rate limits?
What will happen if there are two different types of rate limits?
Search requests that have 5 requests per second
The other rate limit that has, let's say, 100 requests per 10 seconds How do these work together? Is there some conflict? Can I reach the limit with one request and block either as well, or are these separated? Can I still continue making search requests once I hit the normal requests limits?
13:40
Retry
Edit
Copy
Claude responded: They're independent buckets β with one shared bucket on top.
Claude responded: They're independent buckets β with one shared bucket on top.
Analyzed independent rate limit buckets and their practical interactions
Analyzed independent rate limit buckets and their practical interactions
They're independent buckets β with one shared bucket on top.
The three buckets and what each call hits
The three buckets and what each call hits
Copy to clipboard
ββββββββββββββββββββ
Search request βββ β Search: 5/sec β βββ
ββββββββββββββββββββ β
ββββ βββββββββββββββββββ
ββββββββββββββββββββ β β Daily: 250kβ1M β
Non-search call βββ β Burst: 190/10s β βββ β (per portal) β
ββββββββββββββββββββ βββββββββββββββββββ
A search call is only metered against the search bucket and the daily bucket. A non-search call (batch read/update, single PATCH, associations, etc.) is only metered against the burst bucket and the daily bucket. The two short-window buckets do not share counters.
What this means practically
What this means practically
Hitting search secondly limit (5/s):
Only further
/search
calls 429. Your batch reads, batch updates, single PATCHes, association calls β all keep working at full burst speed. This is actually useful: if your sync is bottlenecked on Search, you can pivot to using
lastmodifieddate
filters via batch endpoints, or use the IDs you already have to do batch reads, while Search cools off.
Hitting burst limit (190/10s):
Only non-search calls 429. You can still issue Search calls at 5/s. Useful for: continuing to identify deltas for queueing while in-flight updates drain, or refreshing a small set of records via Search even though your write pipeline is paused.
Hitting daily limit:
Everything stops. Search and non-search alike. Doesn't unblock until midnight in your portal's configured timezone β and remember this is shared across every private app in the portal, plus n8n flows, marketing tools, anything else hitting the API with that account.
So can one type of request block the other?
So can one type of request block the other?
Search β Burst:
No.
Saturating Search at 50 calls per 10s leaves your full 190/10s burst untouched.
Burst β Search:
No.
Saturating burst leaves Search's 5/s untouched.
Either β Daily:
Yes
, but only by contributing to the same daily counter. It's volume that kills you here, not the type.
In theory you can sustain ~50 search + ~190 other =
~240 calls per 10 seconds
indefinitely (until daily runs out), because the two buckets bill independently.
Implementation consequence
Implementation consequence
Your rate limiter needs to know which bucket a request hits before it acquires. Cleanest pattern:
Copy to clipboard
php
$limiter
->
acquire
(
'search'
,
$weight
=
1
)
;
// for search endpoints only
$limiter
->
acquire
(
'burst'
,
$weight
=
1
)
;
// for everything else
$limiter
->
acquire
(
'daily'
,
$weight
=
1
)
;
// every call, both kinds
In Redis: three separate keys, three separate Lua acquire scripts (or one script with a bucket parameter). A search call calls
acquire('search')
+
acquire('daily')
. A batch update calls
acquire('burst')
+
acquire('daily')
.
One subtle pitfall: when you backoff on a 429,
inspect
policyName
in the response body
to know which bucket actually fired. If you see
SECONDLY
from a search endpoint, you only need to delay search-bound jobs β burst-bound jobs in the queue can keep running. If you blanket-pause everything on any 429, you waste capacity on the bucket that's still healthy. Two queues (or two throttle keys) make this clean; one global pause is the lazy version.
The other subtlety: the burst response gives you
X-HubSpot-RateLimit-Remaining
to clamp local state against, but search doesn't return those headers. So your search counter is unverified β be slightly more conservative there (e.g., budget 4/s instead of 5) to absorb the unaccounted-for calls.
Copy
Give positive feedback
Give negative feedback
Retry
You said: Ok, so what will happen each time I make a request?
You said: Ok, so what will happen each time I make a request?
Ok, so what will happen each time I make a request? Let's say I have 100,000 requests to make that are instant. Do I need to increment each request based on the type? For example, if there is a search request, I need to increment both the search bucket and also the daily bucket. If it's a burst, then I can go to the daily and burst buckets. If I need to check if it can make a call, do I need to see both the daily and search, or burst, respectively? Isn't that too heavy for the infrastructure, adding additional load to each request?
13:44
Retry
Edit
Copy
Claude responded: Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out.
Claude responded: Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out....
|
Claude
|
Claude
|
NULL
|
4360
|
|
4359
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Share chat
Claude finished the response
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
how to work with multiple jobs
how to work with paginated requests Let's consider a situation when there are 600 opportunities to sync. What would be the flow? How would the rate limit be recognized? How would it be handled? What are the potential issues? [API usage guidelines and limits - HubSpot docs](
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
). Example of such a error Client error:
POST https://api.hubapi.com/crm/v3/objects/contact/search
resulted in a
429 Too Many Requests
response: {"status":"error","message":"You have reached your secondly limit.","errorType":"RATE_LIMIT","correlationId":"019dffc4-4 (truncated...). Think carefully about the implementation and potential issue and bottlenecks.
Show more
10:42
Retry
Edit
Copy
Claude responded: Current HubSpot limits (Apr 2026)
Claude responded: Current HubSpot limits (Apr 2026)
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Current HubSpot limits (Apr 2026)
Current HubSpot limits (Apr 2026)
For privately distributed apps (which is what Jiminny presumably uses with HubSpot), the limits are layered: a per-app burst window of 100/10s on Free/Starter, 190/10s on Pro/Enterprise, or 250/10s with the API Limit Increase add-on
, plus a per-account daily cap of 250k / 625k / 1M depending on tier β shared across all private apps in the account
. The burst window is per app; the daily quota is per portal.
hubspot
hubspot
hubspot
hubspot
The Search API is special: five requests per second per account, capped at 200 records per page, with a hard 10,000-result ceiling per query
. That's the limit the 429 in your example is hitting (
secondly limit
on
/crm/v3/objects/contact/search
). It's a separate bucket from the 190/10s, and critically, search responses do not include the
X-HubSpot-RateLimit-*
headers
β you can't read remaining capacity off the response, you have to track it yourself.
hubspot
hubspot
hubspot
hubspot
Non-search endpoints return
X-HubSpot-RateLimit-Remaining
,
-Max
, and
-Interval-Milliseconds
. The daily headers are not returned for OAuth-authenticated calls
, so for those you check the account-info endpoint or maintain your own counter. There's also a soft rule: errors should stay under 5% of total daily requests
β that's enforced for marketplace listing, but it's also a sane operational target.
hubspot
hubspot
hubspot
hubspot
So you have
four buckets
to track at minimum: app-burst (10s sliding), search-secondly (1s sliding), account-daily (24h fixed, midnight in HubSpot's TZ), and per-app daily share (your own budgeting on top of the account cap).
Where to store it
Where to store it
Redis. It's the only realistic option once you have multiple queue workers β DB-backed counters serialize too much, and in-process state can't coordinate across workers. Laravel already speaks Redis natively, and you get atomic
INCR
/
EXPIRE
plus Lua scripting for true CAS semantics.
Key layout I'd use:
Copy to clipboard
hubspot:rl:burst:{portalId}:{appId} ZSET (sliding 10s)
hubspot:rl:search:{portalId} ZSET (sliding 1s)
hubspot:rl:daily:{portalId} STRING + TTL to midnight TZ
hubspot:rl:meta:{portalId} HASH (last seen headers)
The two short-window buckets are sliding-window-log (Redis ZSET, score =
microtime
, member = unique request id). Lua script removes entries older than the window, counts remaining slots, and only adds the new one if there's room β all atomic. Fixed windows are simpler but allow 2Γ the limit at the boundary, which on a 5/s window is brutal.
The daily bucket is a plain
INCR
with TTL set to seconds-until-midnight in
HubSpot's account timezone
, not yours β Sofia is UTC+2/+3 but your portal might be set to US Eastern. Get this once and cache it.
How to read it
How to read it
Two-phase: optimistic pre-check, authoritative post-update.
Before a call, run the Lua acquire script. If it returns "denied," sleep until a slot frees up (the script can return ms-until-next-slot) or push the job back to the queue with a delay. Don't busy-loop.
After the call, parse
X-HubSpot-RateLimit-Remaining
/
-Max
/
-Interval-Milliseconds
and store them in
hubspot:rl:meta:{portalId}
. This is your reality check β if your local counter says 50 remaining but HubSpot's header says 5, you trust HubSpot and clamp your counter. This handles clock drift, missed accounting (e.g., crashed worker that took a token but never made the request), and other apps in the same account consuming the daily budget invisibly.
For search specifically, since headers don't come back, the local counter
is
the source of truth β meaning if you ever crash mid-flight, you've under-counted. Always release tokens on connection-level failure but
not
on 429 (you really did make that request).
How to work with multiple jobs
How to work with multiple jobs
The queue layer needs to enforce concurrency separately from the rate limiter. Both work together:
Concurrency cap
via
Queue::throttle()
or a Redis semaphore β limits how many sync workers run in parallel against HubSpot. Without this, you can have 50 workers all blocked waiting for tokens, which is wasteful and creates retry storms.
Per-tenant fairness
β if you sync many Jiminny customers into different HubSpot portals, each portal has its own bucket but you still want one slow portal not to starve others. Either separate queues per portal or a fair-share scheduler.
Priority lanes
β webhook-driven updates (user-visible latency) should outrank background batch syncs. Two queues:
hubspot-priority
and
hubspot-bulk
, with priority workers taking 70% of the burst budget and bulk taking 30% (enforce via separate sub-buckets if you really want hard separation, otherwise just pull from priority first).
Backoff on 429
β respect the
Retry-After
header. If absent, exponential with jitter (e.g.,
min(2^attempt * 250ms, 30s) Β± 20%
). The jitter is non-negotiable; without it, simultaneous 429s retry in lockstep and you get thundering-herd 429s on retry.
How to work with paginated requests
How to work with paginated requests
The trap is treating "fetch all" as one logical operation. Each page is its own API call and competes for tokens with everything else.
Two practical rules:
Don't hold the worker idle while paginating.
If page N takes 500ms and page N+1 needs to wait 800ms for a token, you've burned 800ms of worker time doing nothing. Instead, fetch page N, dispatch the
processing
of page N as a separate job, and queue a "fetch page N+1" job with a delay equal to the wait time. Each page becomes its own atomic unit.
Always batch where HubSpot offers it.
POST /crm/v3/objects/{type}/batch/{read|update|create}
accepts up to 100 IDs per call. For your "patching IDs" flow this is the difference between 600 calls and 6.
Walkthrough: 600 opportunities
Walkthrough: 600 opportunities
Naive flow (one PATCH per deal): 600 calls. At 190/10s that's ~32s of API time, well under daily. You'd hit burst easily without throttling. Plus likely 1-3 search calls upfront and N association calls.
Sane flow:
Identify deltas
β if you can avoid Search at all, do. Use
lastmodifieddate
filter on a single search if you must, paginate at limit=200. For 600 deals that's 3 search calls @ 5/s = ~600ms naturally throttled.
Batch read
current state β
POST /crm/v3/objects/deals/batch/read
with 100 IDs per call β 6 calls. Burst weight 6.
Compute diff
in your code (no API).
Batch update
β
POST /crm/v3/objects/deals/batch/update
with 100 per call β 6 calls.
Associations
β
POST /crm/v4/associations/{from}/{to}/batch/create
if needed β another few batch calls.
Total: ~15-20 API calls for 600 deals. Burst budget consumed: 20/190 over ~5s. Daily impact: trivial.
Recognition: pre-check denies if
<weight>
slots aren't free; on 429 the response surfaces
policyName
(DAILY/SECONDLY) β log it, push the job back with
Retry-After
delay, increment a metric so you can alarm on sustained 429 rate.
Pitfalls & bottlenecks worth pre-empting
Pitfalls & bottlenecks worth pre-empting
Daily quota is shared across the whole portal
, including any n8n flows, other private apps, marketing automation calling APIs, etc. Budget for ~70-80% of the documented limit, not 100%. Add an internal per-app daily cap so a runaway sync can't starve other apps.
Search is uniquely fragile
: separate 5/s bucket, no headers to read, 10k-result cap per query. If you ever hit 10k+ deals matching a filter, partition by
hs_object_id
ranges or by
lastmodifieddate
windows.
Retry storms after HubSpot incidents
β always jitter, always cap total retries (e.g., 5 attempts, then dead-letter).
Webhook β sync β webhook loops
β when your update fires a HubSpot webhook that triggers another sync. Tag your own writes (e.g., a custom property
jy_last_sync_id
) and ignore webhooks where it just changed.
Token refresh
β OAuth refresh itself counts against burst. Cache the access token in Redis with TTL =
expires_in - 60s
, single-flight the refresh (only one worker refreshes; others wait on a lock).
Search latency for fresh writes
β newly created/updated objects don't appear in search instantly. Don't write-then-search; use returned IDs directly.
Clock skew
β Redis is authoritative. Don't use
time()
from each worker for window scoring; use
redis.call('TIME')
inside the Lua script.
Dead workers with held tokens
β sliding-window-log handles this naturally because tokens expire by score; token-bucket implementations need explicit release-on-crash logic.
The 5% error rule
counts every 429 toward your error budget, even successfully retried ones. If your pre-check is working well, 429s should be near zero β if they're not, your pre-check is wrong, not just slow.
Phantom contention with Laravel
RateLimited
middleware
: it's per-job-class by default, not per-portal. If your
SyncDealJob
and
UpdateActivityJob
are different classes both calling HubSpot, they don't share a Laravel-level limiter β you need a single
HubspotRateLimiter
service that everything routes through.
If you want, I can sketch the Lua script for the sliding-window acquire and the Laravel service wrapper around it.
Copy
Give positive feedback
Give negative feedback
Retry
You said: What will happen if there are two different types of rate limits?
You said: What will happen if there are two different types of rate limits?
What will happen if there are two different types of rate limits?
Search requests that have 5 requests per second
The other rate limit that has, let's say, 100 requests per 10 seconds How do these work together? Is there some conflict? Can I reach the limit with one request and block either as well, or are these separated? Can I still continue making search requests once I hit the normal requests limits?
13:40
Retry
Edit
Copy
Claude responded: They're independent buckets β with one shared bucket on top.
Claude responded: They're independent buckets β with one shared bucket on top.
Analyzed independent rate limit buckets and their practical interactions
Analyzed independent rate limit buckets and their practical interactions
They're independent buckets β with one shared bucket on top.
The three buckets and what each call hits
The three buckets and what each call hits
Copy to clipboard
ββββββββββββββββββββ
Search request βββ β Search: 5/sec β βββ
ββββββββββββββββββββ β
ββββ βββββββββββββββββββ
ββββββββββββββββββββ β β Daily: 250kβ1M β
Non-search call βββ β Burst: 190/10s β βββ β (per portal) β
ββββββββββββββββββββ βββββββββββββββββββ
A search call is only metered against the search bucket and the daily bucket. A non-search call (batch read/update, single PATCH, associations, etc.) is only metered against the burst bucket and the daily bucket. The two short-window buckets do not share counters.
What this means practically
What this means practically
Hitting search secondly limit (5/s):
Only further
/search
calls 429. Your batch reads, batch updates, single PATCHes, association calls β all keep working at full burst speed. This is actually useful: if your sync is bottlenecked on Search, you can pivot to using
lastmodifieddate
filters via batch endpoints, or use the IDs you already have to do batch reads, while Search cools off.
Hitting burst limit (190/10s):
Only non-search calls 429. You can still issue Search calls at 5/s. Useful for: continuing to identify deltas for queueing while in-flight updates drain, or refreshing a small set of records via Search even though your write pipeline is paused.
Hitting daily limit:
Everything stops. Search and non-search alike. Doesn't unblock until midnight in your portal's configured timezone β and remember this is shared across every private app in the portal, plus n8n flows, marketing tools, anything else hitting the API with that account.
So can one type of request block the other?
So can one type of request block the other?
Search β Burst:
No.
Saturating Search at 50 calls per 10s leaves your full 190/10s burst untouched.
Burst β Search:
No.
Saturating burst leaves Search's 5/s untouched.
Either β Daily:
Yes
, but only by contributing to the same daily counter. It's volume that kills you here, not the type.
In theory you can sustain ~50 search + ~190 other =
~240 calls per 10 seconds
indefinitely (until daily runs out), because the two buckets bill independently.
Implementation consequence
Implementation consequence
Your rate limiter needs to know which bucket a request hits before it acquires. Cleanest pattern:
Copy to clipboard
php
$limiter
->
acquire
(
'search'
,
$weight
=
1
)
;
// for search endpoints only
$limiter
->
acquire
(
'burst'
,
$weight
=
1
)
;
// for everything else
$limiter
->
acquire
(
'daily'
,
$weight
=
1
)
;
// every call, both kinds
In Redis: three separate keys, three separate Lua acquire scripts (or one script with a bucket parameter). A search call calls
acquire('search')
+
acquire('daily')
. A batch update calls
acquire('burst')
+
acquire('daily')
.
One subtle pitfall: when you backoff on a 429,
inspect
policyName
in the response body
to know which bucket actually fired. If you see
SECONDLY
from a search endpoint, you only need to delay search-bound jobs β burst-bound jobs in the queue can keep running. If you blanket-pause everything on any 429, you waste capacity on the bucket that's still healthy. Two queues (or two throttle keys) make this clean; one global pause is the lazy version.
The other subtlety: the burst response gives you
X-HubSpot-RateLimit-Remaining
to clamp local state against, but search doesn't return those headers. So your search counter is unverified β be slightly more conservative there (e.g., budget 4/s instead of 5) to absorb the unaccounted-for calls.
Copy
Give positive feedback
Give negative feedback
Retry
You said: Ok, so what will happen each time I make a request?
You said: Ok, so what will happen each time I make a request?
Ok, so what will happen each time I make a request? Let's say I have 100,000 requests to make that are instant. Do I need to increment each request based on the type? For example, if there is a search request, I need to increment both the search bucket and also the daily bucket. If it's a burst, then I can go to the daily and burst buckets. If I need to check if it can make a call, do I need to see both the daily and search, or burst, respectively? Isn't that too heavy for the infrastructure, adding additional load to each request?
13:44
Retry
Edit
Copy
Claude responded: Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out.
Claude responded: Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out.
Analyzed per-request overhead concerns and quantified Redis performance impact
Analyzed per-request overhead concerns and quantified Redis performance impact
Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out. But the overhead is much smaller than it sounds, and importantly, it's nowhere near your bottleneck.
What "two buckets per request" actually costs
What "two buckets per request" actually costs
Each request makes
one round trip to Redis
β not two β because you fold both bucket checks into a single Lua script that runs atomically server-side:
Copy to clipboard
lua
-- KEYS[1] = burst bucket key (or search)
-- KEYS[2] = daily bucket key
-- ARGV[1] = now (ms) ARGV[2] = window_ms
-- ARGV[3] = bucket_max ARGV[4] = daily_max
-- ARGV[5] = request_id ARGV[6] = daily_ttl
-- Trim sliding window
redis
.
call
(
'ZREMRANGEBYSCORE'
,
KEYS
[
1
]
,
0
,
ARGV
[
1
]
-
ARGV
[
2
]
)
local
burst_used
=
redis
.
call
(
'ZCARD'
,
KEYS
[
1
]
)
local
daily_used
=
tonumber
(
redis
.
call
(
'GET'
,
KEYS
[
2
]...
|
Claude
|
Claude
|
NULL
|
4359
|
|
4358
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Share chat
Claude finished the response
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
how to work with multiple jobs
how to work with paginated requests Let's consider a situation when there are 600 opportunities to sync. What would be the flow? How would the rate limit be recognized? How would it be handled? What are the potential issues? [API usage guidelines and limits - HubSpot docs](
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
). Example of such a error Client error:
POST https://api.hubapi.com/crm/v3/objects/contact/search
resulted in a
429 Too Many Requests
response: {"status":"error","message":"You have reached your secondly limit.","errorType":"RATE_LIMIT","correlationId":"019dffc4-4 (truncated...). Think carefully about the implementation and potential issue and bottlenecks.
Show more
10:42
Retry
Edit
Copy
Claude responded: Current HubSpot limits (Apr 2026)
Claude responded: Current HubSpot limits (Apr 2026)
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Current HubSpot limits (Apr 2026)
Current HubSpot limits (Apr 2026)
For privately distributed apps (which is what Jiminny presumably uses with HubSpot), the limits are layered: a per-app burst window of 100/10s on Free/Starter, 190/10s on Pro/Enterprise, or 250/10s with the API Limit Increase add-on
, plus a per-account daily cap of 250k / 625k / 1M depending on tier β shared across all private apps in the account
. The burst window is per app; the daily quota is per portal.
hubspot
hubspot
hubspot
hubspot
The Search API is special: five requests per second per account, capped at 200 records per page, with a hard 10,000-result ceiling per query
. That's the limit the 429 in your example is hitting (
secondly limit
on
/crm/v3/objects/contact/search
). It's a separate bucket from the 190/10s, and critically, search responses do not include the
X-HubSpot-RateLimit-*
headers
β you can't read remaining capacity off the response, you have to track it yourself.
hubspot
hubspot
hubspot
hubspot
Non-search endpoints return
X-HubSpot-RateLimit-Remaining
,
-Max
, and
-Interval-Milliseconds
. The daily headers are not returned for OAuth-authenticated calls
, so for those you check the account-info endpoint or maintain your own counter. There's also a soft rule: errors should stay under 5% of total daily requests
β that's enforced for marketplace listing, but it's also a sane operational target.
hubspot
hubspot
hubspot
hubspot
So you have
four buckets
to track at minimum: app-burst (10s sliding), search-secondly (1s sliding), account-daily (24h fixed, midnight in HubSpot's TZ), and per-app daily share (your own budgeting on top of the account cap).
Where to store it
Where to store it
Redis. It's the only realistic option once you have multiple queue workers β DB-backed counters serialize too much, and in-process state can't coordinate across workers. Laravel already speaks Redis natively, and you get atomic
INCR
/
EXPIRE
plus Lua scripting for true CAS semantics.
Key layout I'd use:
Copy to clipboard
hubspot:rl:burst:{portalId}:{appId} ZSET (sliding 10s)
hubspot:rl:search:{portalId} ZSET (sliding 1s)
hubspot:rl:daily:{portalId} STRING + TTL to midnight TZ
hubspot:rl:meta:{portalId} HASH (last seen headers)
The two short-window buckets are sliding-window-log (Redis ZSET, score =
microtime
, member = unique request id). Lua script removes entries older than the window, counts remaining slots, and only adds the new one if there's room β all atomic. Fixed windows are simpler but allow 2Γ the limit at the boundary, which on a 5/s window is brutal.
The daily bucket is a plain
INCR
with TTL set to seconds-until-midnight in
HubSpot's account timezone
, not yours β Sofia is UTC+2/+3 but your portal might be set to US Eastern. Get this once and cache it.
How to read it
How to read it
Two-phase: optimistic pre-check, authoritative post-update.
Before a call, run the Lua acquire script. If it returns "denied," sleep until a slot frees up (the script can return ms-until-next-slot) or push the job back to the queue with a delay. Don't busy-loop.
After the call, parse
X-HubSpot-RateLimit-Remaining
/
-Max
/
-Interval-Milliseconds
and store them in
hubspot:rl:meta:{portalId}
. This is your reality check β if your local counter says 50 remaining but HubSpot's header says 5, you trust HubSpot and clamp your counter. This handles clock drift, missed accounting (e.g., crashed worker that took a token but never made the request), and other apps in the same account consuming the daily budget invisibly.
For search specifically, since headers don't come back, the local counter
is
the source of truth β meaning if you ever crash mid-flight, you've under-counted. Always release tokens on connection-level failure but
not
on 429 (you really did make that request).
How to work with multiple jobs
How to work with multiple jobs
The queue layer needs to enforce concurrency separately from the rate limiter. Both work together:
Concurrency cap
via
Queue::throttle()
or a Redis semaphore β limits how many sync workers run in parallel against HubSpot. Without this, you can have 50 workers all blocked waiting for tokens, which is wasteful and creates retry storms.
Per-tenant fairness
β if you sync many Jiminny customers into different HubSpot portals, each portal has its own bucket but you still want one slow portal not to starve others. Either separate queues per portal or a fair-share scheduler.
Priority lanes
β webhook-driven updates (user-visible latency) should outrank background batch syncs. Two queues:
hubspot-priority
and
hubspot-bulk
, with priority workers taking 70% of the burst budget and bulk taking 30% (enforce via separate sub-buckets if you really want hard separation, otherwise just pull from priority first).
Backoff on 429
β respect the
Retry-After
header. If absent, exponential with jitter (e.g.,
min(2^attempt * 250ms, 30s) Β± 20%
). The jitter is non-negotiable; without it, simultaneous 429s retry in lockstep and you get thundering-herd 429s on retry.
How to work with paginated requests
How to work with paginated requests
The trap is treating "fetch all" as one logical operation. Each page is its own API call and competes for tokens with everything else.
Two practical rules:
Don't hold the worker idle while paginating.
If page N takes 500ms and page N+1 needs to wait 800ms for a token, you've burned 800ms of worker time doing nothing. Instead, fetch page N, dispatch the
processing
of page N as a separate job, and queue a "fetch page N+1" job with a delay equal to the wait time. Each page becomes its own atomic unit.
Always batch where HubSpot offers it.
POST /crm/v3/objects/{type}/batch/{read|update|create}
accepts up to 100 IDs per call. For your "patching IDs" flow this is the difference between 600 calls and 6.
Walkthrough: 600 opportunities
Walkthrough: 600 opportunities
Naive flow (one PATCH per deal): 600 calls. At 190/10s that's ~32s of API time, well under daily. You'd hit burst easily without throttling. Plus likely 1-3 search calls upfront and N association calls.
Sane flow:
Identify deltas
β if you can avoid Search at all, do. Use
lastmodifieddate
filter on a single search if you must, paginate at limit=200. For 600 deals that's 3 search calls @ 5/s = ~600ms naturally throttled.
Batch read
current state β
POST /crm/v3/objects/deals/batch/read
with 100 IDs per call β 6 calls. Burst weight 6.
Compute diff
in your code (no API).
Batch update
β
POST /crm/v3/objects/deals/batch/update
with 100 per call β 6 calls.
Associations
β
POST /crm/v4/associations/{from}/{to}/batch/create
if needed β another few batch calls.
Total: ~15-20 API calls for 600 deals. Burst budget consumed: 20/190 over ~5s. Daily impact: trivial.
Recognition: pre-check denies if
<weight>
slots aren't free; on 429 the response surfaces
policyName
(DAILY/SECONDLY) β log it, push the job back with
Retry-After
delay, increment a metric so you can alarm on sustained 429 rate.
Pitfalls & bottlenecks worth pre-empting
Pitfalls & bottlenecks worth pre-empting
Daily quota is shared across the whole portal
, including any n8n flows, other private apps, marketing automation calling APIs, etc. Budget for ~70-80% of the documented limit, not 100%. Add an internal per-app daily cap so a runaway sync can't starve other apps.
Search is uniquely fragile
: separate 5/s bucket, no headers to read, 10k-result cap per query. If you ever hit 10k+ deals matching a filter, partition by
hs_object_id
ranges or by
lastmodifieddate
windows.
Retry storms after HubSpot incidents
β always jitter, always cap total retries (e.g., 5 attempts, then dead-letter).
Webhook β sync β webhook loops
β when your update fires a HubSpot webhook that triggers another sync. Tag your own writes (e.g., a custom property
jy_last_sync_id
) and ignore webhooks where it just changed.
Token refresh
β OAuth refresh itself counts against burst. Cache the access token in Redis with TTL =
expires_in - 60s
, single-flight the refresh (only one worker refreshes; others wait on a lock).
Search latency for fresh writes
β newly created/updated objects don't appear in search instantly. Don't write-then-search; use returned IDs directly.
Clock skew
β Redis is authoritative. Don't use
time()
from each worker for window scoring; use
redis.call('TIME')
inside the Lua script.
Dead workers with held tokens
β sliding-window-log handles this naturally because tokens expire by score; token-bucket implementations need explicit release-on-crash logic.
The 5% error rule
counts every 429 toward your error budget, even successfully retried ones. If your pre-check is working well, 429s should be near zero β if they're not, your pre-check is wrong, not just slow.
Phantom contention with Laravel
RateLimited
middleware
: it's per-job-class by default, not per-portal. If your
SyncDealJob
and
UpdateActivityJob
are different classes both calling HubSpot, they don't share a Laravel-level limiter β you need a single
HubspotRateLimiter
service that everything routes through.
If you want, I can sketch the Lua script for the sliding-window acquire and the Laravel service wrapper around it.
Copy
Give positive feedback
Give negative feedback
Retry
You said: What will happen if there are two different types of rate limits?
You said: What will happen if there are two different types of rate limits?
What will happen if there are two different types of rate limits?
Search requests that have 5 requests per second
The other rate limit that has, let's say, 100 requests per 10 seconds How do these work together? Is there some conflict? Can I reach the limit with one request and block either as well, or are these separated? Can I still continue making search requests once I hit the normal requests limits?
13:40
Retry
Edit
Copy
Claude responded: They're independent buckets β with one shared bucket on top.
Claude responded: They're independent buckets β with one shared bucket on top.
Analyzed independent rate limit buckets and their practical interactions
Analyzed independent rate limit buckets and their practical interactions
They're independent buckets β with one shared bucket on top.
The three buckets and what each call hits
The three buckets and what each call hits
Copy to clipboard
ββββββββββββββββββββ
Search request βββ β Search: 5/sec β βββ
ββββββββββββββββββββ β
ββββ βββββββββββββββββββ
ββββββββββββββββββββ β β Daily: 250kβ1M β
Non-search call βββ β Burst: 190/10s β βββ β (per portal) β
ββββββββββββββββββββ βββββββββββββββββββ
A search call is only metered against the search bucket and the daily bucket. A non-search call (batch read/update, single PATCH, associations, etc.) is only metered against the burst bucket and the daily bucket. The two short-window buckets do not share counters.
What this means practically
What this means practically
Hitting search secondly limit (5/s):
Only further
/search
calls 429. Your batch reads, batch updates, single PATCHes, association calls β all keep working at full burst speed. This is actually useful: if your sync is bottlenecked on Search, you can pivot to using
lastmodifieddate
filters via batch endpoints, or use the IDs you already have to do batch reads, while Search cools off.
Hitting burst limit (190/10s):
Only non-search calls 429. You can still issue Search calls at 5/s. Useful for: continuing to identify deltas for queueing while in-flight updates drain, or refreshing a small set of records via Search even though your write pipeline is paused.
Hitting daily limit:
Everything stops. Search and non-search alike. Doesn't unblock until midnight in your portal's configured timezone β and remember this is shared across every private app in the portal, plus n8n flows, marketing tools, anything else hitting the API with that account.
So can one type of request block the other?
So can one type of request block the other?
Search β Burst:
No.
Saturating Search at 50 calls per 10s leaves your full 190/10s burst untouched.
Burst β Search:
No.
Saturating burst leaves Search's 5/s untouched.
Either β Daily:
Yes
, but only by contributing to the same daily counter. It's volume that kills you here, not the type.
In theory you can sustain ~50 search + ~190 other =
~240 calls per 10 seconds
indefinitely (until daily runs out), because the two buckets bill independently.
Implementation consequence
Implementation consequence
Your rate limiter needs to know which bucket a request hits before it acquires. Cleanest pattern:
Copy to clipboard
php
$limiter
->
acquire
(
'search'
,
$weight
=
1
)
;
// for search endpoints only
$limiter
->
acquire...
|
Claude
|
Claude
|
NULL
|
4358
|
|
4357
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Share chat
Claude finished the response
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
how to work with multiple jobs
how to work with paginated requests Let's consider a situation when there are 600 opportunities to sync. What would be the flow? How would the rate limit be recognized? How would it be handled? What are the potential issues? [API usage guidelines and limits - HubSpot docs](
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
). Example of such a error Client error:
POST https://api.hubapi.com/crm/v3/objects/contact/search
resulted in a
429 Too Many Requests
response: {"status":"error","message":"You have reached your secondly limit.","errorType":"RATE_LIMIT","correlationId":"019dffc4-4 (truncated...). Think carefully about the implementation and potential issue and bottlenecks.
Show more
10:42
Retry
Edit
Copy
Claude responded: Current HubSpot limits (Apr 2026)
Claude responded: Current HubSpot limits (Apr 2026)
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Current HubSpot limits (Apr 2026)
Current HubSpot limits (Apr 2026)
For privately distributed apps (which is what Jiminny presumably uses with HubSpot), the limits are layered: a per-app burst window of 100/10s on Free/Starter, 190/10s on Pro/Enterprise, or 250/10s with the API Limit Increase add-on
, plus a per-account daily cap of 250k / 625k / 1M depending on tier β shared across all private apps in the account
. The burst window is per app; the daily quota is per portal.
hubspot
hubspot
hubspot
hubspot
The Search API is special: five requests per second per account, capped at 200 records per page, with a hard 10,000-result ceiling per query
. That's the limit the 429 in your example is hitting (
secondly limit
on
/crm/v3/objects/contact/search
). It's a separate bucket from the 190/10s, and critically, search responses do not include the
X-HubSpot-RateLimit-*
headers
β you can't read remaining capacity off the response, you have to track it yourself.
hubspot
hubspot
hubspot
hubspot
Non-search endpoints return
X-HubSpot-RateLimit-Remaining
,
-Max
, and
-Interval-Milliseconds
. The daily headers are not returned for OAuth-authenticated calls
, so for those you check the account-info endpoint or maintain your own counter. There's also a soft rule: errors should stay under 5% of total daily requests
β that's enforced for marketplace listing, but it's also a sane operational target.
hubspot
hubspot
hubspot
hubspot
So you have
four buckets
to track at minimum: app-burst (10s sliding), search-secondly (1s sliding), account-daily (24h fixed, midnight in HubSpot's TZ), and per-app daily share (your own budgeting on top of the account cap).
Where to store it
Where to store it
Redis. It's the only realistic option once you have multiple queue workers β DB-backed counters serialize too much, and in-process state can't coordinate across workers. Laravel already speaks Redis natively, and you get atomic
INCR
/
EXPIRE
plus Lua scripting for true CAS semantics.
Key layout I'd use:
Copy to clipboard
hubspot:rl:burst:{portalId}:{appId} ZSET (sliding 10s)
hubspot:rl:search:{portalId} ZSET (sliding 1s)
hubspot:rl:daily:{portalId} STRING + TTL to midnight TZ
hubspot:rl:meta:{portalId} HASH (last seen headers)
The two short-window buckets are sliding-window-log (Redis ZSET, score =
microtime
, member = unique request id). Lua script removes entries older than the window, counts remaining slots, and only adds the new one if there's room β all atomic. Fixed windows are simpler but allow 2Γ the limit at the boundary, which on a 5/s window is brutal.
The daily bucket is a plain
INCR
with TTL set to seconds-until-midnight in
HubSpot's account timezone
, not yours β Sofia is UTC+2/+3 but your portal might be set to US Eastern. Get this once and cache it.
How to read it
How to read it
Two-phase: optimistic pre-check, authoritative post-update.
Before a call, run the Lua acquire script. If it returns "denied," sleep until a slot frees up (the script can return ms-until-next-slot) or push the job back to the queue with a delay. Don't busy-loop.
After the call, parse
X-HubSpot-RateLimit-Remaining
/
-Max
/
-Interval-Milliseconds
and store them in
hubspot:rl:meta:{portalId}
. This is your reality check β if your local counter says 50 remaining but HubSpot's header says 5, you trust HubSpot and clamp your counter. This handles clock drift, missed accounting (e.g., crashed worker that took a token but never made the request), and other apps in the same account consuming the daily budget invisibly.
For search specifically, since headers don't come back, the local counter
is
the source of truth β meaning if you ever crash mid-flight, you've under-counted. Always release tokens on connection-level failure but
not
on 429 (you really did make that request).
How to work with multiple jobs
How to work with multiple jobs
The queue layer needs to enforce concurrency separately from the rate limiter. Both work together:
Concurrency cap
via
Queue::throttle()
or a Redis semaphore β limits how many sync workers run in parallel against HubSpot. Without this, you can have 50 workers all blocked waiting for tokens, which is wasteful and creates retry storms.
Per-tenant fairness
β if you sync many Jiminny customers into different HubSpot portals, each portal has its own bucket but you still want one slow portal not to starve others. Either separate queues per portal or a fair-share scheduler.
Priority lanes
β webhook-driven updates (user-visible latency) should outrank background batch syncs. Two queues:
hubspot-priority
and
hubspot-bulk
, with priority workers taking 70% of the burst budget and bulk taking 30% (enforce via separate sub-buckets if you really want hard separation, otherwise just pull from priority first).
Backoff on 429
β respect the
Retry-After...
|
Claude
|
Claude
|
NULL
|
4357
|
|
4356
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Share chat
Claude finished the response
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
how to work with multiple jobs
how to work with paginated requests Let's consider a situation when there are 600 opportunities to sync. What would be the flow? How would the rate limit be recognized? How would it be handled? What are the potential issues? [API usage guidelines and limits - HubSpot docs](
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
). Example of such a error Client error:
POST https://api.hubapi.com/crm/v3/objects/contact/search
resulted in a
429 Too Many Requests
response: {"status":"error","message":"You have reached your secondly limit.","errorType":"RATE_LIMIT","correlationId":"019dffc4-4 (truncated...). Think carefully about the implementation and potential issue and bottlenecks.
Show more
10:42
Retry
Edit
Copy
Claude responded: Current HubSpot limits (Apr 2026)
Claude responded: Current HubSpot limits (Apr 2026)
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Current HubSpot limits (Apr 2026)
Current HubSpot limits (Apr 2026)
For privately distributed apps (which is what Jiminny presumably uses with HubSpot), the limits are layered: a per-app burst window of 100/10s on Free/Starter, 190/10s on Pro/Enterprise, or 250/10s with the API Limit Increase add-on
, plus a per-account daily cap of 250k / 625k / 1M depending on tier β shared across all private apps in the account
. The burst window is per app; the daily quota is per portal.
hubspot
hubspot
hubspot
hubspot
The Search API is special: five requests per second per account, capped at 200 records per page, with a hard 10,000-result ceiling per query
. That's the limit the 429 in your example is hitting (
secondly limit
on
/crm/v3/objects/contact/search
). It's a separate bucket from the 190/10s, and critically, search responses do not include the
X-HubSpot-RateLimit-*
headers
β you can't read remaining capacity off the response, you have to track it yourself.
hubspot
hubspot
hubspot
hubspot
Non-search endpoints return
X-HubSpot-RateLimit-Remaining
,
-Max
, and
-Interval-Milliseconds
. The daily headers are not returned for OAuth-authenticated calls
, so for those you check the account-info endpoint or maintain your own counter. There's also a soft rule: errors should stay under 5% of total daily requests
β that's enforced for marketplace listing, but it's also a sane operational target.
hubspot
hubspot
hubspot
hubspot
So you have
four buckets
to track at minimum: app-burst (10s sliding), search-secondly (1s sliding), account-daily (24h fixed, midnight in HubSpot's TZ), and per-app daily share (your own budgeting on top of the account cap).
Where to store it
Where to store it
Redis. It's the only realistic option once you have multiple queue workers β DB-backed counters serialize too much, and in-process state can't coordinate across workers. Laravel already speaks Redis natively, and you get atomic
INCR
/
EXPIRE
plus Lua scripting for true CAS semantics.
Key layout I'd use:
Copy to clipboard
hubspot:rl:burst:{portalId}:{appId} ZSET (sliding 10s)
hubspot:rl:search:{portalId} ZSET (sliding 1s)
hubspot:rl:daily:{portalId} STRING + TTL to midnight TZ
hubspot:rl:meta:{portalId} HASH (last seen headers)
The two short-window buckets are sliding-window-log (Redis ZSET, score =
microtime
, member = unique request id). Lua script removes entries older than the window, counts remaining slots, and only adds the new one if there's room β all atomic. Fixed windows are simpler but allow 2Γ the limit at the boundary, which on a 5/s window is brutal.
The daily bucket is a plain
INCR
with TTL set to seconds-until-midnight in
HubSpot's account timezone
, not yours β Sofia is UTC+2/+3 but your portal might be set to US Eastern. Get this once and cache it.
How to read it
How to read it
Two-phase: optimistic pre-check, authoritative post-update.
Before a call, run the Lua acquire script. If it returns "denied," sleep until a slot frees up (the script can return ms-until-next-slot) or push the job back to the queue with a delay. Don't busy-loop.
After the call, parse
X-HubSpot-RateLimit-Remaining
/
-Max
/
-Interval-Milliseconds
and store them in
hubspot:rl:meta:{portalId}
. This is your reality check β if your local counter says 50 remaining but HubSpot's header says 5, you trust HubSpot and clamp your counter. This handles clock drift, missed accounting (e.g., crashed worker that took a token but never made the request), and other apps in the same account consuming the daily budget invisibly.
For search specifically, since headers don't come back, the local counter
is
the source of truth β meaning if you ever crash mid-flight, you've under-counted. Always release tokens on connection-level failure but
not
on 429 (you really did make that request).
How to work with multiple jobs
How to work with multiple jobs
The queue layer needs to enforce concurrency separately from the rate limiter. Both work together:
Concurrency cap
via
Queue::throttle()
or a Redis semaphore β limits how many sync workers run in parallel against HubSpot. Without this, you can have 50 workers all blocked waiting for tokens, which is wasteful and creates retry storms.
Per-tenant fairness
β if you sync many Jiminny customers into different HubSpot portals, each portal has its own bucket but you still want one slow portal not to starve others. Either separate queues per portal or a fair-share scheduler.
Priority lanes
β webhook-driven updates (user-visible latency) should outrank background batch syncs. Two queues:
hubspot-priority
and
hubspot-bulk
, with priority workers taking 70% of the burst budget and bulk taking 30% (enforce via separate sub-buckets if you really want hard separation, otherwise just pull from priority first).
Backoff on 429
β respect the
Retry-After
header. If absent, exponential with jitter (e.g.,
min(2^attempt * 250ms, 30s) Β± 20%
). The jitter is non-negotiable; without it, simultaneous 429s retry in lockstep and you get thundering-herd 429s on retry.
How to work with paginated requests
How to work with paginated requests
The trap is treating "fetch all" as one logical operation. Each page is its own API call and competes for tokens with everything else.
Two practical rules:
Don't hold the worker idle while paginating.
If page N takes 500ms and page N+1 needs to wait 800ms for a token, you've burned 800ms of worker time doing nothing. Instead, fetch page N, dispatch the
processing
of page N as a separate job, and queue a "fetch page N+1" job with a delay equal to the wait time. Each page becomes its own atomic unit.
Always batch where HubSpot offers it.
POST /crm/v3/objects/{type}/batch/{read|update|create}
accepts up to 100 IDs per call. For your "patching IDs" flow this is the difference between 600 calls and 6.
Walkthrough: 600 opportunities
Walkthrough: 600 opportunities
Naive flow (one PATCH per deal): 600 calls. At 190/10s that's ~32s of API time, well under daily. You'd hit burst easily without throttling. Plus likely 1-3 search calls upfront and N association calls.
Sane flow:
Identify deltas
β if you can avoid Search at all, do. Use
lastmodifieddate
filter on a single search if you must, paginate at limit=200. For 600 deals that's 3 search calls @ 5/s = ~600ms naturally throttled.
Batch read
current state β
POST /crm/v3/objects/deals/batch/read
with 100 IDs per call β 6 calls. Burst weight 6.
Compute diff
in your code (no API).
Batch update
β
POST /crm/v3/objects/deals/batch/update
with 100 per call β 6 calls.
Associations
β
POST /crm/v4/associations/{from}/{to}/batch/create
if needed β another few batch calls.
Total: ~15-20 API calls for 600 deals. Burst budget consumed: 20/190 over ~5s. Daily impact: trivial.
Recognition: pre-check denies if
<weight>
slots aren't free; on 429 the response surfaces
policyName
(DAILY/SECONDLY) β log it, push the job back with
Retry-After
delay, increment a metric so you can alarm on sustained 429 rate.
Pitfalls & bottlenecks worth pre-empting
Pitfalls & bottlenecks worth pre-empting
Daily quota is shared across the whole portal
, including any n8n flows, other private apps, marketing automation calling APIs, etc. Budget for ~70-80% of the documented limit, not 100%. Add an internal per-app daily cap so a runaway sync can't starve other apps.
Search is uniquely fragile
: separate 5/s bucket, no headers to read, 10k-result cap per query. If you ever hit 10k+ deals matching a filter, partition by
hs_object_id
ranges or by
lastmodifieddate
windows.
Retry storms after HubSpot incidents
β always jitter, always cap total retries (e.g., 5 attempts, then dead-letter).
Webhook β sync β webhook loops
β when your update fires a HubSpot webhook that triggers another sync. Tag your own writes (e.g., a custom property
jy_last_sync_id
) and ignore webhooks where it just changed.
Token refresh
β OAuth refresh itself counts against burst. Cache the access token in Redis with TTL =
expires_in - 60s
, single-flight the refresh (only one worker refreshes; others wait on a lock).
Search latency for fresh writes
β newly created/updated objects don't appear in search instantly. Don't write-then-search; use returned IDs directly.
Clock skew
β Redis is authoritative. Don't use
time()
from each worker for window scoring; use
redis.call('TIME')
inside the Lua script.
Dead workers with held tokens
β sliding-window-log handles this naturally because tokens expire by score; token-bucket implementations need explicit release-on-crash logic.
The 5% error rule
counts every 429 toward your error budget, even successfully retried ones. If your pre-check is working well, 429s should be near zero β if they're not, your pre-check is wrong, not just slow.
Phantom contention with Laravel
RateLimited
middleware
: it's per-job-class by default, not per-portal. If your
SyncDealJob
and
UpdateActivityJob
are different classes both calling HubSpot, they don't share a Laravel-level limiter β you need a single
HubspotRateLimiter
service that everything routes through.
If you want, I can sketch the Lua script for the sliding-window acquire and the Laravel service wrapper around it.
Copy
Give positive feedback
Give negative feedback
Retry
You said: What will happen if there are two different types of rate limits?
You said: What will happen if there are two different types of rate limits?
What will happen if there are two different types of rate limits?
Search requests that have 5 requests per second
The other rate limit that has, let's say, 100 requests per 10 seconds How do these work together? Is there some conflict? Can I reach the limit with one request and block either as well, or are these separated? Can I still continue making search requests once I hit the normal requests limits?
13:40
Retry
Edit
Copy
Claude responded: They're independent buckets β with one shared bucket on top.
Claude responded: They're independent buckets β with one shared bucket on top.
Analyzed independent rate limit buckets and their practical interactions
Analyzed independent rate limit buckets and their practical interactions
They're independent buckets β with one shared bucket on top.
The three buckets and what each call hits
The three buckets and what each call hits
Copy to clipboard
ββββββββββββββββββββ
Search request βββ β Search: 5/sec β βββ
ββββββββββββββββββββ β
ββββ βββββββββββββββββββ
ββββββββββββββββββββ β β Daily: 250kβ1M β
Non-search call βββ β Burst: 190/10s β βββ β (per portal) β
ββββββββββββββββββββ βββββββββββββββββββ
A search call is only metered against the search bucket and the daily bucket. A non-search call (batch read/update, single PATCH, associations, etc.) is only metered against the burst bucket and the daily bucket. The two short-window buckets do not share counters.
What this means practically
What this means practically
Hitting search secondly limit (5/s):
Only further
/search
calls 429. Your batch reads, batch updates, single PATCHes, association calls β all keep working at full burst speed. This is actually useful: if your sync is bottlenecked on Search, you can pivot to using
lastmodifieddate
filters via batch endpoints, or use the IDs you already have to do batch reads, while Search cools off.
Hitting burst limit (190/10s):
Only non-search calls 429. You can still issue Search calls at 5/s. Useful for: continuing to identify deltas for queueing while in-flight updates drain, or refreshing a small set of records via Search even though your write pipeline is paused.
Hitting daily limit:
Everything stops. Search and non-search alike. Doesn't unblock until midnight in your portal's configured timezone β and remember this is shared across every private app in the portal, plus n8n flows, marketing tools, anything else hitting the API with that account.
So can one type of request block the other?
So can one type of request block the other?
Search β Burst:
No.
Saturating Search at 50 calls per 10s leaves your full 190/10s burst untouched.
Burst β Search:
No.
Saturating burst leaves Search's 5/s untouched.
Either β Daily:
Yes
, but only by contributing to the same daily counter. It's volume that kills you here, not the type.
In theory you can sustain ~50 search + ~190 other =
~240 calls per 10 seconds
indefinitely (until daily runs out), because the two buckets bill independently.
Implementation consequence
Implementation consequence
Your rate limiter needs to know which bucket a request hits before it acquires. Cleanest pattern:
Copy to clipboard
php
$limiter
->
acquire
(
'search'
,
$weight
=
1
)
;
// for search endpoints only
$limiter
->
acquire
(
'burst'
,
$weight
=
1
)
;
// for everything else
$limiter
->
acquire
(
'daily'
,
$weight
=
1
)
;
// every call, both kinds
In Redis: three separate keys, three separate Lua acquire scripts (or one script with a bucket parameter). A search call calls
acquire('search')
+
acquire('daily')
. A batch update calls
acquire('burst')
+
acquire('daily')
.
One subtle pitfall: when you backoff on a 429,
inspect
policyName
in the response body
to know which bucket actually fired. If you see
SECONDLY
from a search endpoint, you only need to delay search-bound jobs β burst-bound jobs in the queue can keep running. If you blanket-pause everything on any 429, you waste capacity on the bucket that's still healthy. Two queues (or two throttle keys) make this clean; one global pause is the lazy version.
The other subtlety: the burst response gives you
X-HubSpot-RateLimit-Remaining
to clamp local state against, but search doesn't return those headers. So your search counter is unverified β be slightly more conservative there (e.g., budget 4/s instead of 5) to absorb the unaccounted-for calls.
Copy
Give positive feedback
Give negative feedback
Retry
You said: Ok, so what will happen each time I make a request?
You said: Ok, so what will happen each time I make a request?
Ok, so what will happen each time I make a request? Let's say I have 100,000 requests to make that are instant. Do I need to increment each request based on the type? For example, if there is a search request, I need to increment both the search bucket and also the daily bucket. If it's a burst, then I can go to the daily and burst buckets. If I need to check if it can make a call, do I need to see both the daily and search, or burst, respectively? Isn't that too heavy for the infrastructure, adding additional load to each request?
13:44
Retry
Edit
Copy
Claude responded: Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out.
Claude responded: Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out.
Analyzed per-request overhead concerns and quantified Redis performance impact
Analyzed per-request overhead concerns and quantified Redis performance impact
Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out. But the overhead is much smaller than it sounds, and importantly, it's nowhere near your bottleneck.
What "two buckets per request" actually costs
What "two buckets per request" actually costs
Each request makes
one round trip to Redis
β not two β because you fold both bucket checks into a single Lua script that runs atomically server-side:
Copy to clipboard
lua
-- KEYS[1] = burst bucket key (or search)
-- KEYS[2] = daily bucket key
-- ARGV[1] = now (ms) ARGV[2] = window_ms
-- ARGV[3] = bucket_max ARGV[4] = daily_max
-- ARGV[5] = request_id ARGV[6] = daily_ttl
-- Trim sliding window
redis
.
call
(
'ZREMRANGEBYSCORE'
,
KEYS
[
1
]
,
0
,
ARGV
[
1
]
-
ARGV
[
2
]
)
local
burst_used
=
redis
.
call
(
'ZCARD'
,
KEYS
[
1
]
)
local
daily_used
=
tonumber
(
redis
.
call
(
'GET'
,
KEYS
[
2
]
)
or
'0'
)
if
burst_used
>=
tonumber
(
ARGV
[
3
]
)
then
-- Tell caller how long to sleep until oldest entry expires
local
oldest
=
redis
.
call
(
'ZRANGE'
,
KEYS
[
1
]
,
0
,
0
,
'WITHSCORES'
)
return
{
0
,
'BURST'
,
(
oldest
[
2
]
+
ARGV
[
2
]
)
-
ARGV
[
1
]
}
end
if
daily_used
>=
tonumber
(
ARGV
[
4
]
)
then
return
{
0
,
'DAILY'
,
-
1
}
end
redis
.
call
(
'ZADD'
,
KEYS
[
1
]
,
ARGV
[
1
]
,
ARGV
[
5
]
)
redis
.
call
(
'PEXPIRE'
,
KEYS
[
1
]
,
ARGV
[
2
]
+
1000
)...
|
Claude
|
Claude
|
NULL
|
4356
|
|
4355
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Share chat
Claude finished the response
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
how to work with multiple jobs
how to work with paginated requests Let's consider a situation when there are 600 opportunities to sync. What would be the flow? How would the rate limit be recognized? How would it be handled? What are the potential issues? [API usage guidelines and limits - HubSpot docs](
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
). Example of such a error Client error:
POST https://api.hubapi.com/crm/v3/objects/contact/search
resulted in a
429 Too Many Requests
response: {"status":"error","message":"You have reached your secondly limit.","errorType":"RATE_LIMIT","correlationId":"019dffc4-4 (truncated...). Think carefully about the implementation and potential issue and bottlenecks.
Show more
10:42
Retry
Edit
Copy
Claude responded: Current HubSpot limits (Apr 2026)
Claude responded: Current HubSpot limits (Apr 2026)
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Current HubSpot limits (Apr 2026)
Current HubSpot limits (Apr 2026)
For privately distributed apps (which is what Jiminny presumably uses with HubSpot), the limits are layered: a per-app burst window of 100/10s on Free/Starter, 190/10s on Pro/Enterprise, or 250/10s with the API Limit Increase add-on
, plus a per-account daily cap of 250k / 625k / 1M depending on tier β shared across all private apps in the account
. The burst window is per app; the daily quota is per portal.
hubspot
hubspot
hubspot
hubspot
The Search API is special: five requests per second per account, capped at 200 records per page, with a hard 10,000-result ceiling per query
. That's the limit the 429 in your example is hitting (
secondly limit
on
/crm/v3/objects/contact/search
). It's a separate bucket from the 190/10s, and critically, search responses do not include the
X-HubSpot-RateLimit-*
headers
β you can't read remaining capacity off the response, you have to track it yourself.
hubspot
hubspot
hubspot
hubspot
Non-search endpoints return
X-HubSpot-RateLimit-Remaining
,
-Max
, and
-Interval-Milliseconds
. The daily headers are not returned for OAuth-authenticated calls
, so for those you check the account-info endpoint or maintain your own counter. There's also a soft rule: errors should stay under 5% of total daily requests
β that's enforced for marketplace listing, but it's also a sane operational target.
hubspot
hubspot
hubspot
hubspot
So you have
four buckets
to track at minimum: app-burst (10s sliding), search-secondly (1s sliding), account-daily (24h fixed, midnight in HubSpot's TZ), and per-app daily share (your own budgeting on top of the account cap).
Where to store it
Where to store it
Redis. It's the only realistic option once you have multiple queue workers β DB-backed counters serialize too much, and in-process state can't coordinate across workers. Laravel already speaks Redis natively, and you get atomic
INCR
/
EXPIRE
plus Lua scripting for true CAS semantics.
Key layout I'd use:
Copy to clipboard
hubspot:rl:burst:{portalId}:{appId} ZSET (sliding 10s)
hubspot:rl:search:{portalId} ZSET (sliding 1s)
hubspot:rl:daily:{portalId} STRING + TTL to midnight TZ
hubspot:rl:meta:{portalId} HASH (last seen headers)
The two short-window buckets are sliding-window-log (Redis ZSET, score =
microtime
, member = unique request id). Lua script removes entries older than the window, counts remaining slots, and only adds the new one if there's room β all atomic. Fixed windows are simpler but allow 2Γ the limit at the boundary, which on a 5/s window is brutal.
The daily bucket is a plain
INCR
with TTL set to seconds-until-midnight in
HubSpot's account timezone
, not yours β Sofia is UTC+2/+3 but your portal might be set to US Eastern. Get this once and cache it.
How to read it
How to read it
Two-phase: optimistic pre-check, authoritative post-update.
Before a call, run the Lua acquire script. If it returns "denied," sleep until a slot frees up (the script can return ms-until-next-slot) or push the job back to the queue with a delay. Don't busy-loop.
After the call, parse
X-HubSpot-RateLimit-Remaining
/
-Max
/
-Interval-Milliseconds
and store them in
hubspot:rl:meta:{portalId}
. This is your reality check β if your local counter says 50 remaining but HubSpot's header says 5, you trust HubSpot and clamp your counter. This handles clock drift, missed accounting (e.g., crashed worker that took a token but never made the request), and other apps in the same account consuming the daily budget invisibly.
For search specifically, since headers don't come back, the local counter
is
the source of truth β meaning if you ever crash mid-flight, you've under-counted. Always release tokens on connection-level failure but
not
on 429 (you really did make that request).
How to work with multiple jobs
How to work with multiple jobs
The queue layer needs to enforce concurrency separately from the rate limiter. Both work together:
Concurrency cap
via
Queue::throttle()
or a Redis semaphore β limits how many sync workers run in parallel against HubSpot. Without this, you can have 50 workers all blocked waiting for tokens, which is wasteful and creates retry storms.
Per-tenant fairness
β if you sync many Jiminny customers into different HubSpot portals, each portal has its own bucket but you still want one slow portal not to starve others. Either separate queues per portal or a fair-share scheduler.
Priority lanes
β webhook-driven updates (user-visible latency) should outrank background batch syncs. Two queues:
hubspot-priority
and
hubspot-bulk
, with priority workers taking 70% of the burst budget and bulk taking 30% (enforce via separate sub-buckets if you really want hard separation, otherwise just pull from priority first).
Backoff on 429
β respect the
Retry-After
header. If absent, exponential with jitter (e.g.,
min(2^attempt * 250ms, 30s) Β± 20%
). The jitter is non-negotiable; without it, simultaneous 429s retry in lockstep and you get thundering-herd 429s on retry.
How to work with paginated requests
How to work with paginated requests
The trap is treating "fetch all" as one logical operation. Each page is its own API call and competes for tokens with everything else.
Two practical rules:
Don't hold the worker idle while paginating.
If page N takes 500ms and page N+1 needs to wait 800ms for a token, you've burned 800ms of worker time doing nothing. Instead, fetch page N, dispatch the
processing
of page N as a separate job, and queue a "fetch page N+1" job with a delay equal to the wait time. Each page becomes its own atomic unit.
Always batch where HubSpot offers it.
POST /crm/v3/objects/{type}/batch/{read|update|create}
accepts up to 100 IDs per call. For your "patching IDs" flow this is the difference between 600 calls and 6.
Walkthrough: 600 opportunities
Walkthrough: 600 opportunities
Naive flow (one PATCH per deal): 600 calls. At 190/10s that's ~32s of API time, well under daily. You'd hit burst easily without throttling. Plus likely 1-3 search calls upfront and N association calls.
Sane flow:
Identify deltas
β if you can avoid Search at all, do. Use
lastmodifieddate
filter on a single search if you must, paginate at limit=200. For 600 deals that's 3 search calls @ 5/s = ~600ms naturally throttled.
Batch read
current state β
POST /crm/v3/objects/deals/batch/read
with 100 IDs per call β 6 calls. Burst weight 6.
Compute diff
in your code (no API).
Batch update
β
POST /crm/v3/objects/deals/batch/update
with 100 per call β 6 calls.
Associations
β
POST /crm/v4/associations/{from}/{to}/batch/create
if needed β another few batch calls.
Total: ~15-20 API calls for 600 deals. Burst budget consumed: 20/190 over ~5s. Daily impact: trivial.
Recognition: pre-check denies if
<weight>
slots aren't free; on 429 the response surfaces
policyName
(DAILY/SECONDLY) β log it, push the job back with
Retry-After
delay, increment a metric so you can alarm on sustained 429 rate.
Pitfalls & bottlenecks worth pre-empting
Pitfalls & bottlenecks worth pre-empting
Daily quota is shared across the whole portal
, including any n8n flows, other private apps, marketing automation calling APIs, etc. Budget for ~70-80% of the documented limit, not 100%. Add an internal per-app daily cap so a runaway sync can't starve other apps.
Search is uniquely fragile
: separate 5/s bucket, no headers to read, 10k-result cap per query. If you ever hit 10k+ deals matching a filter, partition by
hs_object_id
ranges or by
lastmodifieddate
windows.
Retry storms after HubSpot incidents
β always jitter, always cap total retries (e.g., 5 attempts, then dead-letter).
Webhook β sync β webhook loops
β when your update fires a HubSpot webhook that triggers another sync. Tag your own writes (e.g., a custom property
jy_last_sync_id
) and ignore webhooks where it just changed.
Token refresh
β OAuth refresh itself counts against burst. Cache the access token in Redis with TTL =
expires_in - 60s
, single-flight the refresh (only one worker refreshes; others wait on a lock).
Search latency for fresh writes
β newly created/updated objects don't appear in search instantly. Don't write-then-search; use returned IDs directly.
Clock skew
β Redis is authoritative. Don't use
time()
from each worker for window scoring; use
redis.call('TIME')
inside the Lua script.
Dead workers with held tokens
β sliding-window-log handles this naturally because tokens expire by score; token-bucket implementations need explicit release-on-crash logic.
The 5% error rule
counts every 429 toward your error budget, even successfully retried ones. If your pre-check is working well, 429s should be near zero β if they're not, your pre-check is wrong, not just slow.
Phantom contention with Laravel
RateLimited
middleware
: it's per-job-class by default, not per-portal. If your
SyncDealJob
and
UpdateActivityJob
are different classes both calling HubSpot, they don't share a Laravel-level limiter β you need a single
HubspotRateLimiter
service that everything routes through.
If you want, I can sketch the Lua script for the sliding-window acquire and the Laravel service wrapper around it.
Copy
Give positive feedback
Give negative feedback
Retry
You said: What will happen if there are two different types of rate limits?
You said: What will happen if there are two different types of rate limits?
What will happen if there are two different types of rate limits?
Search requests that have 5 requests per second
The other rate limit that has, let's say, 100 requests per 10 seconds How do these work together? Is there some conflict? Can I reach the limit with one request and block either as well, or are these separated? Can I still continue making search requests once I hit the normal requests limits?
13:40
Retry
Edit
Copy
Claude responded: They're independent buckets β with one shared bucket on top.
Claude responded: They're independent buckets β with one shared bucket on top.
Analyzed independent rate limit buckets and their practical interactions
Analyzed independent rate limit buckets and their practical interactions
They're independent buckets β with one shared bucket on top.
The three buckets and what each call hits
The three buckets and what each call hits
Copy to clipboard
ββββββββββββββββββββ
Search request βββ β Search: 5/sec β βββ
ββββββββββββββββββββ β
ββββ βββββββββββββββββββ
ββββββββββββββββββββ β β Daily: 250kβ1M β
Non-search call βββ β Burst: 190/10s β βββ β (per portal) β
ββββββββββββββββββββ βββββββββββββββββββ
A search call is only metered against the search bucket and the daily bucket. A non-search call (batch read/update, single PATCH, associations, etc.) is only metered against the burst bucket and the daily bucket. The two short-window buckets do not share counters.
What this means practically
What this means practically
Hitting search secondly limit (5/s):
Only further
/search
calls 429. Your batch reads, batch updates, single PATCHes, association calls β all keep working at full burst speed. This is actually useful: if your sync is bottlenecked on Search, you can pivot to using
lastmodifieddate
filters via batch endpoints, or use the IDs you already have to do batch reads, while Search cools off.
Hitting burst limit (190/10s):
Only non-search calls 429. You can still issue Search calls at 5/s. Useful for: continuing to identify deltas for queueing while in-flight updates drain, or refreshing a small set of records via Search even though your write pipeline is paused.
Hitting daily limit:
Everything stops. Search and non-search alike. Doesn't unblock until midnight in your portal's configured timezone β and remember this is shared across every private app in the portal, plus n8n flows, marketing tools, anything else hitting the API with that account.
So can one type of request block the other?
So can one type of request block the other?
Search β Burst:
No.
Saturating Search at 50 calls per 10s leaves your full 190/10s burst untouched.
Burst β Search:
No.
Saturating burst leaves Search's 5/s untouched.
Either β Daily:
Yes
, but only by contributing to the same daily counter. It's volume that kills you here, not the type.
In theory you can sustain ~50 search + ~190 other =
~240 calls per 10 seconds
indefinitely (until daily runs out), because the two buckets bill independently.
Implementation consequence
Implementation consequence
Your rate limiter needs to know which bucket a request hits before it acquires. Cleanest pattern:
Copy to clipboard
php
$limiter
->
acquire
(
'search'
,
$weight
=
1
)
;
// for search endpoints only
$limiter
->
acquire
(
'burst'
,
$weight
=
1
)
;
// for everything else
$limiter
->
acquire
(
'daily'
,
$weight
=
1
)
;
// every call, both kinds
In Redis: three separate keys, three separate Lua acquire scripts (or one script with a bucket parameter). A search call calls
acquire('search')
+
acquire('daily')
. A batch update calls
acquire('burst')
+
acquire('daily')
.
One subtle pitfall: when you backoff on a 429,
inspect
policyName
in the response body
to know which bucket actually fired. If you see
SECONDLY
from a search endpoint, you only need to delay search-bound jobs β burst-bound jobs in the queue can keep running. If you blanket-pause everything on any 429, you waste capacity on the bucket that's still healthy. Two queues (or two throttle keys) make this clean; one global pause is the lazy version.
The other subtlety: the burst response gives you
X-HubSpot-RateLimit-Remaining
to clamp local state against, but search doesn't return those headers. So your search counter is unverified β be slightly more conservative there (e.g., budget 4/s instead of 5) to absorb the unaccounted-for calls.
Copy
Give positive feedback
Give negative feedback
Retry
You said: Ok, so what will happen each time I make a request?
You said: Ok, so what will happen each time I make a request?
Ok, so what will happen each time I make a request? Let's say I have 100,000 requests to make that are instant. Do I need to increment each request based on the type? For example, if there is a search request, I need to increment both the search bucket and also the daily bucket. If it's a burst, then I can go to the daily and burst buckets. If I need to check if it can make a call, do I need to see both the daily and search, or burst, respectively? Isn't that too heavy for the infrastructure, adding additional load to each request?
13:44
Retry
Edit
Copy
Claude responded: Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out.
Claude responded: Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out.
Analyzed per-request overhead concerns and quantified Redis performance impact
Analyzed per-request overhead concerns and quantified Redis performance impact
Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out. But the overhead is much smaller than it sounds, and importantly, it's nowhere near your bottleneck.
What "two buckets per request" actually costs
What "two buckets per request" actually costs
Each request makes
one round trip to Redis
β not two β because you fold both bucket checks into a single Lua script that runs atomically server-side:
Copy to clipboard
lua
-- KEYS[1] = burst bucket key (or search)
-- KEYS[2] = daily bucket key
-- ARGV[1] = now (ms) ARGV[2] = window_ms
-- ARGV[3] = bucket_max ARGV[4] = daily_max
-- ARGV[5] = request_id ARGV[6] = daily_ttl
-- Trim sliding window
redis
.
call
(
'ZREMRANGEBYSCORE'
,
KEYS
[
1
]
,
0
,
ARGV
[
1
]
-
ARGV
[
2
]
)
local
burst_used
=
redis...
|
Claude
|
Claude
|
NULL
|
4355
|
|
4354
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Share chat
Claude finished the response
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
how to work with multiple jobs
how to work with paginated requests Let's consider a situation when there are 600 opportunities to sync. What would be the flow? How would the rate limit be recognized? How would it be handled? What are the potential issues? [API usage guidelines and limits - HubSpot docs](
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
). Example of such a error Client error:
POST https://api.hubapi.com/crm/v3/objects/contact/search
resulted in a
429 Too Many Requests
response: {"status":"error","message":"You have reached your secondly limit.","errorType":"RATE_LIMIT","correlationId":"019dffc4-4 (truncated...). Think carefully about the implementation and potential issue and bottlenecks.
Show more
10:42
Retry
Edit
Copy
Claude responded: Current HubSpot limits (Apr 2026)
Claude responded: Current HubSpot limits (Apr 2026)
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Current HubSpot limits (Apr 2026)
Current HubSpot limits (Apr 2026)
For privately distributed apps (which is what Jiminny presumably uses with HubSpot), the limits are layered: a per-app burst window of 100/10s on Free/Starter, 190/10s on Pro/Enterprise, or 250/10s with the API Limit Increase add-on
, plus a per-account daily cap of 250k / 625k / 1M depending on tier β shared across all private apps in the account
. The burst window is per app; the daily quota is per portal.
hubspot
hubspot
hubspot
hubspot
The Search API is special: five requests per second per account, capped at 200 records per page, with a hard 10,000-result ceiling per query
. That's the limit the 429 in your example is hitting (
secondly limit
on
/crm/v3/objects/contact/search
). It's a separate bucket from the 190/10s, and critically, search responses do not include the
X-HubSpot-RateLimit-*
headers
β you can't read remaining capacity off the response, you have to track it yourself.
hubspot
hubspot
hubspot
hubspot
Non-search endpoints return
X-HubSpot-RateLimit-Remaining
,
-Max
, and
-Interval-Milliseconds
. The daily headers are not returned for OAuth-authenticated calls
, so for those you check the account-info endpoint or maintain your own counter. There's also a soft rule: errors should stay under 5% of total daily requests
β that's enforced for marketplace listing, but it's also a sane operational target.
hubspot
hubspot
hubspot
hubspot
So you have
four buckets
to track at minimum: app-burst (10s sliding), search-secondly (1s sliding), account-daily (24h fixed, midnight in HubSpot's TZ), and per-app daily share (your own budgeting on top of the account cap).
Where to store it
Where to store it
Redis. It's the only realistic option once you have multiple queue workers β DB-backed counters serialize too much, and in-process state can't coordinate across workers. Laravel already speaks Redis natively, and you get atomic
INCR
/
EXPIRE
plus Lua scripting for true CAS semantics.
Key layout I'd use:
Copy to clipboard
hubspot:rl:burst:{portalId}:{appId} ZSET (sliding 10s)
hubspot:rl:search:{portalId} ZSET (sliding 1s)
hubspot:rl:daily:{portalId} STRING + TTL to midnight TZ
hubspot:rl:meta:{portalId} HASH (last seen headers)
The two short-window buckets are sliding-window-log (Redis ZSET, score =
microtime
, member = unique request id). Lua script removes entries older than the window, counts remaining slots, and only adds the new one if there's room β all atomic. Fixed windows are simpler but allow 2Γ the limit at the boundary, which on a 5/s window is brutal.
The daily bucket is a plain
INCR
with TTL set to seconds-until-midnight in
HubSpot's account timezone
, not yours β Sofia is UTC+2/+3 but your portal might be set to US Eastern. Get this once and cache it.
How to read it
How to read it
Two-phase: optimistic pre-check, authoritative post-update.
Before a call, run the Lua acquire script. If it returns "denied," sleep until a slot frees up (the script can return ms-until-next-slot) or push the job back to the queue with a delay. Don't busy-loop.
After the call, parse
X-HubSpot-RateLimit-Remaining
/
-Max
/
-Interval-Milliseconds
and store them in
hubspot:rl:meta:{portalId}
. This is your reality check β if your local counter says 50 remaining but HubSpot's header says 5, you trust HubSpot and clamp your counter. This handles clock drift, missed accounting (e.g., crashed worker that took a token but never made the request), and other apps in the same account consuming the daily budget invisibly.
For search specifically, since headers don't come back, the local counter
is
the source of truth β meaning if you ever crash mid-flight, you've under-counted. Always release tokens on connection-level failure but
not
on 429 (you really did make that request).
How to work with multiple jobs
How to work with multiple jobs
The queue layer needs to enforce concurrency separately from the rate limiter. Both work together:
Concurrency cap
via
Queue::throttle()
or a Redis semaphore β limits how many sync workers run in parallel against HubSpot. Without this, you can have 50 workers all blocked waiting for tokens, which is wasteful and creates retry storms.
Per-tenant fairness
β if you sync many Jiminny customers into different HubSpot portals, each portal has its own bucket but you still want one slow portal not to starve others. Either separate queues per portal or a fair-share scheduler.
Priority lanes
β webhook-driven updates (user-visible latency) should outrank background batch syncs. Two queues:
hubspot-priority
and
hubspot-bulk
, with priority workers taking 70% of the burst budget and bulk taking 30% (enforce via separate sub-buckets if you really want hard separation, otherwise just pull from priority first).
Backoff on 429
β respect the
Retry-After
header. If absent, exponential with jitter (e.g.,
min(2^attempt * 250ms, 30s) Β± 20%
). The jitter is non-negotiable; without it, simultaneous 429s retry in lockstep and you get thundering-herd 429s on retry.
How to work with paginated requests
How to work with paginated requests
The trap is treating "fetch all" as one logical operation. Each page is its own API call and competes for tokens with everything else.
Two practical rules:
Don't hold the worker idle while paginating.
If page N takes 500ms and page N+1 needs to wait 800ms for a token, you've burned 800ms of worker time doing nothing. Instead, fetch page N, dispatch the
processing
of page N as a separate job, and queue a "fetch page N+1" job with a delay equal to the wait time. Each page becomes its own atomic unit.
Always batch where HubSpot offers it.
POST /crm/v3/objects/{type}/batch/{read|update|create}
accepts up to 100 IDs per call. For your "patching IDs" flow this is the difference between 600 calls and 6.
Walkthrough: 600 opportunities
Walkthrough: 600 opportunities
Naive flow (one PATCH per deal): 600 calls. At 190/10s that's ~32s of API time, well under daily. You'd hit burst easily without throttling. Plus likely 1-3 search calls upfront and N association calls.
Sane flow:
Identify deltas
β if you can avoid Search at all, do. Use
lastmodifieddate
filter on a single search if you must, paginate at limit=200. For 600 deals that's 3 search calls @ 5/s = ~600ms naturally throttled.
Batch read
current state β
POST /crm/v3/objects/deals/batch/read
with 100 IDs per call β 6 calls. Burst weight 6.
Compute diff
in your code (no API).
Batch update
β
POST /crm/v3/objects/deals/batch/update
with 100 per call β 6 calls.
Associations
β
POST /crm/v4/associations/{from}/{to}/batch/create
if needed β another few batch calls.
Total: ~15-20 API calls for 600 deals. Burst budget consumed: 20/190 over ~5s. Daily impact: trivial.
Recognition: pre-check denies if
<weight>
slots aren't free; on 429 the response surfaces
policyName
(DAILY/SECONDLY) β log it, push the job back with
Retry-After
delay, increment a metric so you can alarm on sustained 429 rate.
Pitfalls & bottlenecks worth pre-empting
Pitfalls & bottlenecks worth pre-empting
Daily quota is shared across the whole portal
, including any n8n flows, other private apps, marketing automation calling APIs, etc. Budget for ~70-80% of the documented limit, not 100%. Add an internal per-app daily cap so a runaway sync can't starve other apps.
Search is uniquely fragile
: separate 5/s bucket, no headers to read, 10k-result cap per query. If you ever hit 10k+ deals matching a filter, partition by
hs_object_id
ranges or by
lastmodifieddate
windows.
Retry storms after HubSpot incidents
β always jitter, always cap total retries (e.g., 5 attempts, then dead-letter).
Webhook β sync β webhook loops
β when your update fires a HubSpot webhook that triggers another sync. Tag your own writes (e.g., a custom property
jy_last_sync_id
) and ignore webhooks where it just changed.
Token refresh
β OAuth refresh itself counts against burst. Cache the access token in Redis with TTL =
expires_in - 60s
, single-flight the refresh (only one worker refreshes; others wait on a lock).
Search latency for fresh writes
β newly created/updated objects don't appear in search instantly. Don't write-then-search; use returned IDs directly.
Clock skew
β Redis is authoritative. Don't use
time()
from each worker for window scoring; use
redis.call('TIME')
inside the Lua script.
Dead workers with held tokens
β sliding-window-log handles this naturally because tokens expire by score; token-bucket implementations need explicit release-on-crash logic.
The 5% error rule
counts every 429 toward your error budget, even successfully retried ones. If your pre-check is working well, 429s should be near zero β if they're not, your pre-check is wrong, not just slow.
Phantom contention with Laravel
RateLimited
middleware
: it's per-job-class by default, not per-portal. If your
SyncDealJob
and
UpdateActivityJob
are different classes both calling HubSpot, they don't share a Laravel-level limiter β you need a single
HubspotRateLimiter
service that everything routes through.
If you want, I can sketch the Lua script for the sliding-window acquire and the Laravel service wrapper around it.
Copy
Give positive feedback
Give negative feedback
Retry
You said: What will happen if there are two different types of rate limits?
You said: What will happen if there are two different types of rate limits?
What will happen if there are two different types of rate limits?
Search requests that have 5 requests per second
The other rate limit that has, let's say, 100 requests per 10 seconds How do these work together? Is there some conflict? Can I reach the limit with one request and block either as well, or are these separated? Can I still continue making search requests once I hit the normal requests limits?
13:40
Retry
Edit
Copy
Claude responded: They're independent buckets β with one shared bucket on top.
Claude responded: They're independent buckets β with one shared bucket on top.
Analyzed independent rate limit buckets and their practical interactions
Analyzed independent rate limit buckets and their practical interactions
They're independent buckets β with one shared bucket on top.
The three buckets and what each call hits
The three buckets and what each call hits
Copy to clipboard
ββββββββββββββββββββ
Search request βββ β Search: 5/sec β βββ
ββββββββββββββββββββ β
ββββ βββββββββββββββββββ
ββββββββββββββββββββ β β Daily: 250kβ1M β
Non-search call βββ β Burst: 190/10s β βββ β (per portal) β
ββββββββββββββββββββ βββββββββββββββββββ
A search call is only metered against the search bucket and the daily bucket. A non-search call (batch read/update, single PATCH, associations, etc.) is only metered against the burst bucket and the daily bucket. The two short-window buckets do not share counters.
What this means practically
What this means practically
Hitting search secondly limit (5/s):
Only further
/search
calls 429. Your batch reads, batch updates, single PATCHes, association calls β all keep working at full burst speed. This is actually useful: if your sync is bottlenecked on Search, you can pivot to using
lastmodifieddate
filters via batch endpoints, or use the IDs you already have to do batch reads, while Search cools off.
Hitting burst limit (190/10s):
Only non-search calls 429. You can still issue Search calls at 5/s. Useful for: continuing to identify deltas for queueing while in-flight updates drain, or refreshing a small set of records via Search even though your write pipeline is paused.
Hitting daily limit:
Everything stops. Search and non-search alike. Doesn't unblock until midnight in your portal's configured timezone β and remember this is shared across every private app in the portal, plus n8n flows, marketing tools, anything else hitting the API with that account.
So can one type of request block the other?
So can one type of request block the other?
Search β Burst:
No.
Saturating Search at 50 calls per 10s leaves your full 190/10s burst untouched.
Burst β Search:
No.
Saturating burst leaves Search's 5/s untouched.
Either β Daily:
Yes
, but only by contributing to the same daily counter. It's volume that kills you here, not the type.
In theory you can sustain ~50 search + ~190 other =
~240 calls per 10 seconds
indefinitely (until daily runs out), because the two buckets bill independently.
Implementation consequence
Implementation consequence
Your rate limiter needs to know which bucket a request hits before it acquires. Cleanest pattern:
Copy to clipboard
php
$limiter
->
acquire
(
'search'
,
$weight
=
1
)
;
// for search endpoints only
$limiter
->
acquire
(
'burst'
,
$weight
=
1
)
;
// for everything else
$limiter
->
acquire
(
'daily'
,
$weight
=
1
)
;
// every call, both kinds
In Redis: three separate keys, three separate Lua acquire scripts (or one script with a bucket parameter). A search call calls
acquire('search')
+
acquire('daily')
. A batch update calls
acquire('burst')
+
acquire('daily')
.
One subtle pitfall: when you backoff on a 429,
inspect
policyName
in the response body
to know which bucket actually fired. If you see
SECONDLY
from a search endpoint, you only need to delay search-bound jobs β burst-bound jobs in the queue can keep running. If you blanket-pause everything on any 429, you waste capacity on the bucket that's still healthy. Two queues (or two throttle keys) make this clean; one global pause is the lazy version.
The other subtlety: the burst response gives you
X-HubSpot-RateLimit-Remaining
to clamp local state against, but search doesn't return those headers. So your search counter is unverified β be slightly more conservative there (e.g., budget 4/s instead of 5) to absorb the unaccounted-for calls.
Copy
Give positive feedback
Give negative feedback
Retry
You said: Ok, so what will happen each time I make a request?
You said: Ok, so what will happen each time I make a request?
Ok, so what will happen each time I make a request? Let's say I have 100,000 requests to make that are instant. Do I need to increment each request based on the type? For example, if there is a search request, I need to increment both the search bucket and also the daily bucket. If it's a burst, then I can go to the daily and burst buckets. If I need to check if it can make a call, do I need to see both the daily and search, or burst, respectively? Isn't that too heavy for the infrastructure, adding additional load to each request?
13:44
Retry
Edit
Copy
Claude responded: Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out.
Claude responded: Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out.
Analyzed per-request overhead concerns and quantified Redis performance impact
Analyzed per-request overhead concerns and quantified Redis performance impact
Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out. But the overhead is much smaller than it sounds, and importantly, it's nowhere near your bottleneck.
What "two buckets per request" actually costs
What "two buckets per request" actually costs
Each request makes
one round trip to Redis
β not two β because you fold both bucket checks into a single Lua script that runs atomically server-side:
Copy to clipboard
lua
-- KEYS[1] = burst bucket key (or search)
-- KEYS[2] = daily bucket key
-- ARGV[1] = now (ms) ARGV[2] = window_ms
-- ARGV[3] = bucket_max ARGV[4] = daily_max
-- ARGV[5] = request_id ARGV[6] = daily_ttl
-- Trim sliding window
redis
.
call
(
'ZREMRANGEBYSCORE'
,
KEYS
[
1
]
,
0
,
ARGV
[
1
]
-
ARGV
[
2
]
)
local
burst_used
=
redis
.
call
(
'ZCARD'
,
KEYS
[
1
]
)
local
daily_used
=
tonumber...
|
Claude
|
Claude
|
NULL
|
4354
|
|
4353
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Share chat
Claude finished the response
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
how to work with multiple jobs
how to work with paginated requests Let's consider a situation when there are 600 opportunities to sync. What would be the flow? How would the rate limit be recognized? How would it be handled? What are the potential issues? [API usage guidelines and limits - HubSpot docs](
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
). Example of such a error Client error:
POST https://api.hubapi.com/crm/v3/objects/contact/search
resulted in a
429 Too Many Requests
response: {"status":"error","message":"You have reached your secondly limit.","errorType":"RATE_LIMIT","correlationId":"019dffc4-4 (truncated...). Think carefully about the implementation and potential issue and bottlenecks.
Show more
10:42
Retry
Edit
Copy
Claude responded: Current HubSpot limits (Apr 2026)
Claude responded: Current HubSpot limits (Apr 2026)
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Current HubSpot limits (Apr 2026)
Current HubSpot limits (Apr 2026)
For privately distributed apps (which is what Jiminny presumably uses with HubSpot), the limits are layered: a per-app burst window of 100/10s on Free/Starter, 190/10s on Pro/Enterprise, or 250/10s with the API Limit Increase add-on
, plus a per-account daily cap of 250k / 625k / 1M depending on tier β shared across all private apps in the account
. The burst window is per app; the daily quota is per portal.
hubspot
hubspot
hubspot
hubspot
The Search API is special: five requests per second per account, capped at 200 records per page, with a hard 10,000-result ceiling per query
. That's the limit the 429 in your example is hitting (
secondly limit
on
/crm/v3/objects/contact/search
). It's a separate bucket from the 190/10s, and critically, search responses do not include the
X-HubSpot-RateLimit-*
headers
β you can't read remaining capacity off the response, you have to track it yourself.
hubspot
hubspot
hubspot
hubspot
Non-search endpoints return
X-HubSpot-RateLimit-Remaining
,
-Max
, and
-Interval-Milliseconds
. The daily headers are not returned for OAuth-authenticated calls
, so for those you check the account-info endpoint or maintain your own counter. There's also a soft rule: errors should stay under 5% of total daily requests
β that's enforced for marketplace listing, but it's also a sane operational target.
hubspot
hubspot
hubspot
hubspot
So you have
four buckets
to track at minimum: app-burst (10s sliding), search-secondly (1s sliding), account-daily (24h fixed, midnight in HubSpot's TZ), and per-app daily share (your own budgeting on top of the account cap).
Where to store it
Where to store it
Redis. It's the only realistic option once you have multiple queue workers β DB-backed counters serialize too much, and in-process state can't coordinate across workers. Laravel already speaks Redis natively, and you get atomic
INCR
/
EXPIRE
plus Lua scripting for true CAS semantics.
Key layout I'd use:
Copy to clipboard
hubspot:rl:burst:{portalId}:{appId} ZSET (sliding 10s)
hubspot:rl:search:{portalId} ZSET (sliding 1s)
hubspot:rl:daily:{portalId} STRING + TTL to midnight TZ
hubspot:rl:meta:{portalId} HASH (last seen headers)
The two short-window buckets are sliding-window-log (Redis ZSET, score =
microtime
, member = unique request id). Lua script removes entries older than the window, counts remaining slots, and only adds the new one if there's room β all atomic. Fixed windows are simpler but allow 2Γ the limit at the boundary, which on a 5/s window is brutal.
The daily bucket is a plain
INCR
with TTL set to seconds-until-midnight in
HubSpot's account timezone
, not yours β Sofia is UTC+2/+3 but your portal might be set to US Eastern. Get this once and cache it.
How to read it
How to read it
Two-phase: optimistic pre-check, authoritative post-update.
Before a call, run the Lua acquire script. If it returns "denied," sleep until a slot frees up (the script can return ms-until-next-slot) or push the job back to the queue with a delay. Don't busy-loop.
After the call, parse
X-HubSpot-RateLimit-Remaining
/
-Max
/
-Interval-Milliseconds
and store them in
hubspot:rl:meta:{portalId}
. This is your reality check β if your local counter says 50 remaining but HubSpot's header says 5, you trust HubSpot and clamp your counter. This handles clock drift, missed accounting (e.g., crashed worker that took a token but never made the request), and other apps in the same account consuming the daily budget invisibly.
For search specifically, since headers don't come back, the local counter
is
the source of truth β meaning if you ever crash mid-flight, you've under-counted. Always release tokens on connection-level failure but
not
on 429 (you really did make that request).
How to work with multiple jobs
How to work with multiple jobs
The queue layer needs to enforce concurrency separately from the rate limiter. Both work together:
Concurrency cap
via
Queue::throttle()
or a Redis semaphore β limits how many sync workers run in parallel against HubSpot. Without this, you can have 50 workers all blocked waiting for tokens, which is wasteful and creates retry storms.
Per-tenant fairness
β if you sync many Jiminny customers into different HubSpot portals, each portal has its own bucket but you still want one slow portal not to starve others. Either separate queues per portal or a fair-share scheduler.
Priority lanes
β webhook-driven updates (user-visible latency) should outrank background batch syncs. Two queues:
hubspot-priority
and
hubspot-bulk
, with priority workers taking 70% of the burst budget and bulk taking 30% (enforce via separate sub-buckets if you really want hard separation, otherwise just pull from priority first).
Backoff on 429
β respect the
Retry-After
header. If absent, exponential with jitter (e.g.,
min(2^attempt * 250ms, 30s) Β± 20%
). The jitter is non-negotiable; without it, simultaneous 429s retry in lockstep and you get thundering-herd 429s on retry.
How to work with paginated requests
How to work with paginated requests
The trap is treating "fetch all" as one logical operation. Each page is its own API call and competes for tokens with everything else.
Two practical rules:
Don't hold the worker idle while paginating.
If page N takes 500ms and page N+1 needs to wait 800ms for a token, you've burned 800ms of worker time doing nothing. Instead, fetch page N, dispatch the
processing
of page N as a separate job, and queue a "fetch page N+1" job with a delay equal to the wait time. Each page becomes its own atomic unit.
Always batch where HubSpot offers it.
POST /crm/v3/objects/{type}/batch/{read|update|create}
accepts up to 100 IDs per call. For your "patching IDs" flow this is the difference between 600 calls and 6.
Walkthrough: 600 opportunities
Walkthrough: 600 opportunities
Naive flow (one PATCH per deal): 600 calls. At 190/10s that's ~32s of API time, well under daily. You'd hit burst easily without throttling. Plus likely 1-3 search calls upfront and N association calls.
Sane flow:
Identify deltas
β if you can avoid Search at all, do. Use
lastmodifieddate
filter on a single search if you must, paginate at limit=200. For 600 deals that's 3 search calls @ 5/s = ~600ms naturally throttled.
Batch read
current state β
POST /crm/v3/objects/deals/batch/read
with 100 IDs per call β 6 calls. Burst weight 6.
Compute diff
in your code (no API).
Batch update
β
POST /crm/v3/objects/deals/batch/update
with 100 per call β 6 calls.
Associations
β
POST /crm/v4/associations/{from}/{to}/batch/create
if needed β another few batch calls.
Total: ~15-20 API calls for 600 deals. Burst budget consumed: 20/190 over ~5s. Daily impact: trivial.
Recognition: pre-check denies if
<weight>
slots aren't free; on 429 the response surfaces
policyName
(DAILY/SECONDLY) β log it, push the job back with
Retry-After
delay, increment a metric so you can alarm on sustained 429 rate.
Pitfalls & bottlenecks worth pre-empting
Pitfalls & bottlenecks worth pre-empting
Daily quota is shared across the whole portal
, including any n8n flows, other private apps, marketing automation calling APIs, etc. Budget for ~70-80% of the documented limit, not 100%. Add an internal per-app daily cap so a runaway sync can't starve other apps.
Search is uniquely fragile
: separate 5/s bucket, no headers to read, 10k-result cap per query. If you ever hit 10k+ deals matching a filter, partition by
hs_object_id
ranges or by
lastmodifieddate
windows.
Retry storms after HubSpot incidents
β always jitter, always cap total retries (e.g., 5 attempts, then dead-letter).
Webhook β sync β webhook loops
β when your update fires a HubSpot webhook that triggers another sync. Tag your own writes (e.g., a custom property
jy_last_sync_id
) and ignore webhooks where it just changed.
Token refresh
β OAuth refresh itself counts against burst. Cache the access token in Redis with TTL =
expires_in - 60s
, single-flight the refresh (only one worker refreshes; others wait on a lock).
Search latency for fresh writes
β newly created/updated objects don't appear in search instantly. Don't write-then-search; use returned IDs directly.
Clock skew
β Redis is authoritative. Don't use
time()
from each worker for window scoring; use
redis.call('TIME')
inside the Lua script.
Dead workers with held tokens
β sliding-window-log handles this naturally because tokens expire by score; token-bucket implementations need explicit release-on-crash logic.
The 5% error rule
counts every 429 toward your error budget, even successfully retried ones. If your pre-check is working well, 429s should be near zero β if they're not, your pre-check is wrong, not just slow.
Phantom contention with Laravel
RateLimited
middleware
: it's per-job-class by default, not per-portal. If your
SyncDealJob
and
UpdateActivityJob
are different classes both calling HubSpot, they don't share a Laravel-level limiter β you need a single
HubspotRateLimiter
service that everything routes through.
If you want, I can sketch the Lua script for the sliding-window acquire and the Laravel service wrapper around it.
Copy
Give positive feedback
Give negative feedback
Retry
You said: What will happen if there are two different types of rate limits?
You said: What will happen if there are two different types of rate limits?
What will happen if there are two different types of rate limits?
Search requests that have 5 requests per second
The other rate limit that has, let's say, 100 requests per 10 seconds How do these work together? Is there some conflict? Can I reach the limit with one request and block either as well, or are these separated? Can I still continue making search requests once I hit the normal requests limits?
13:40
Retry
Edit
Copy
Claude responded: They're independent buckets β with one shared bucket on top.
Claude responded: They're independent buckets β with one shared bucket on top.
Analyzed independent rate limit buckets and their practical interactions
Analyzed independent rate limit buckets and their practical interactions
They're independent buckets β with one shared bucket on top.
The three buckets and what each call hits
The three buckets and what each call hits
Copy to clipboard
ββββββββββββββββββββ
Search request βββ β Search: 5/sec β βββ
ββββββββββββββββββββ β
ββββ βββββββββββββββββββ
ββββββββββββββββββββ β β Daily: 250kβ1M β
Non-search call βββ β Burst: 190/10s β βββ β (per portal) β
ββββββββββββββββββββ βββββββββββββββββββ
A search call is only metered against the search bucket and the daily bucket. A non-search call (batch read/update, single PATCH, associations, etc.) is only metered against the burst bucket and the daily bucket. The two short-window buckets do not share counters.
What this means practically
What this means practically
Hitting search secondly limit (5/s):
Only further
/search
calls 429. Your batch reads, batch updates, single PATCHes, association calls β all keep working at full burst speed. This is actually useful: if your sync is bottlenecked on Search, you can pivot to using
lastmodifieddate
filters via batch endpoints, or use the IDs you already have to do batch reads, while Search cools off.
Hitting burst limit (190/10s):
Only non-search calls 429. You can still issue Search calls at 5/s. Useful for: continuing to identify deltas for queueing while in-flight updates drain, or refreshing a small set of records via Search even though your write pipeline is paused.
Hitting daily limit:
Everything stops. Search and non-search alike. Doesn't unblock until midnight in your portal's configured timezone β and remember this is shared across every private app in the portal, plus n8n flows, marketing tools, anything else hitting the API with that account.
So can one type of request block the other?
So can one type of request block the other?
Search β Burst:
No.
Saturating Search at 50 calls per 10s leaves your full 190/10s burst untouched.
Burst β Search:
No.
Saturating burst leaves Search's 5/s untouched.
Either β Daily:
Yes
, but only by contributing to the same daily counter. It's volume that kills you here, not the type.
In theory you can sustain ~50 search + ~190 other =
~240 calls per 10 seconds
indefinitely (until daily runs out), because the two buckets bill independently.
Implementation consequence
Implementation consequence
Your rate limiter needs to know which bucket a request hits before it acquires. Cleanest pattern:
Copy to clipboard
php
$limiter
->
acquire
(
'search'
,
$weight
=
1
)
;
// for search endpoints only
$limiter
->
acquire
(
'burst'
,
$weight
=
1
)
;
// for everything else
$limiter
->
acquire
(
'daily'
,
$weight
=
1
)
;
// every call, both kinds
In Redis: three separate keys, three separate Lua acquire scripts (or one script with a bucket parameter). A search call calls
acquire('search')
+
acquire('daily')...
|
Claude
|
Claude
|
NULL
|
4353
|
|
4352
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Share chat
Claude finished the response
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
how to work with multiple jobs
how to work with paginated requests Let's consider a situation when there are 600 opportunities to sync. What would be the flow? How would the rate limit be recognized? How would it be handled? What are the potential issues? [API usage guidelines and limits - HubSpot docs](
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
). Example of such a error Client error:
POST https://api.hubapi.com/crm/v3/objects/contact/search
resulted in a
429 Too Many Requests
response: {"status":"error","message":"You have reached your secondly limit.","errorType":"RATE_LIMIT","correlationId":"019dffc4-4 (truncated...). Think carefully about the implementation and potential issue and bottlenecks.
Show more
10:42
Retry
Edit
Copy
Claude responded: Current HubSpot limits (Apr 2026)
Claude responded: Current HubSpot limits (Apr 2026)
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Current HubSpot limits (Apr 2026)
Current HubSpot limits (Apr 2026)
For privately distributed apps (which is what Jiminny presumably uses with HubSpot), the limits are layered: a per-app burst window of 100/10s on Free/Starter, 190/10s on Pro/Enterprise, or 250/10s with the API Limit Increase add-on
, plus a per-account daily cap of 250k / 625k / 1M depending on tier β shared across all private apps in the account
. The burst window is per app; the daily quota is per portal.
hubspot
hubspot
hubspot
hubspot
The Search API is special: five requests per second per account, capped at 200 records per page, with a hard 10,000-result ceiling per query
. That's the limit the 429 in your example is hitting (
secondly limit
on
/crm/v3/objects/contact/search
). It's a separate bucket from the 190/10s, and critically, search responses do not include the
X-HubSpot-RateLimit-*
headers
β you can't read remaining capacity off the response, you have to track it yourself.
hubspot
hubspot
hubspot
hubspot
Non-search endpoints return
X-HubSpot-RateLimit-Remaining
,
-Max
, and
-Interval-Milliseconds
. The daily headers are not returned for OAuth-authenticated calls
, so for those you check the account-info endpoint or maintain your own counter. There's also a soft rule: errors should stay under 5% of total daily requests
β that's enforced for marketplace listing, but it's also a sane operational target.
hubspot
hubspot
hubspot
hubspot
So you have
four buckets
to track at minimum: app-burst (10s sliding), search-secondly (1s sliding), account-daily (24h fixed, midnight in HubSpot's TZ), and per-app daily share (your own budgeting on top of the account cap).
Where to store it
Where to store it
Redis. It's the only realistic option once you have multiple queue workers β DB-backed counters serialize too much, and in-process state can't coordinate across workers. Laravel already speaks Redis natively, and you get atomic
INCR
/
EXPIRE
plus Lua scripting for true CAS semantics.
Key layout I'd use:
Copy to clipboard
hubspot:rl:burst:{portalId}:{appId} ZSET (sliding 10s)
hubspot:rl:search:{portalId} ZSET (sliding 1s)
hubspot:rl:daily:{portalId} STRING + TTL to midnight TZ
hubspot:rl:meta:{portalId} HASH (last seen headers)
The two short-window buckets are sliding-window-log (Redis ZSET, score =
microtime
, member = unique request id). Lua script removes entries older than the window, counts remaining slots, and only adds the new one if there's room β all atomic. Fixed windows are simpler but allow 2Γ the limit at the boundary, which on a 5/s window is brutal.
The daily bucket is a plain
INCR
with TTL set to seconds-until-midnight in
HubSpot's account timezone
, not yours β Sofia is UTC+2/+3 but your portal might be set to US Eastern. Get this once and cache it.
How to read it
How to read it
Two-phase: optimistic pre-check, authoritative post-update.
Before a call, run the Lua acquire script. If it returns "denied," sleep until a slot frees up (the script can return ms-until-next-slot) or push the job back to the queue with a delay. Don't busy-loop.
After the call, parse
X-HubSpot-RateLimit-Remaining
/
-Max
/
-Interval-Milliseconds
and store them in
hubspot:rl:meta:{portalId}
. This is your reality check β if your local counter says 50 remaining but HubSpot's header says 5, you trust HubSpot and clamp your counter. This handles clock drift, missed accounting (e.g., crashed worker that took a token but never made the request), and other apps in the same account consuming the daily budget invisibly.
For search specifically, since headers don't come back, the local counter
is
the source of truth β meaning if you ever crash mid-flight, you've under-counted. Always release tokens on connection-level failure but
not
on 429 (you really did make that request).
How to work with multiple jobs
How to work with multiple jobs
The queue layer needs to enforce concurrency separately from the rate limiter. Both work together:
Concurrency cap
via
Queue::throttle()
or a Redis semaphore β limits how many sync workers run in parallel against HubSpot. Without this, you can have 50 workers all blocked waiting for tokens, which is wasteful and creates retry storms.
Per-tenant fairness
β if you sync many Jiminny customers into different HubSpot portals, each portal has its own bucket but you still want one slow portal not to starve others. Either separate queues per portal or a fair-share scheduler.
Priority lanes
β webhook-driven updates (user-visible latency) should outrank background batch syncs. Two queues:
hubspot-priority
and
hubspot-bulk
, with priority workers taking 70% of the burst budget and bulk taking 30% (enforce via separate sub-buckets if you really want hard separation, otherwise just pull from priority first).
Backoff on 429
β respect the
Retry-After
header. If absent, exponential with jitter (e.g.,
min(2^attempt * 250ms, 30s) Β± 20%
). The jitter is non-negotiable; without it, simultaneous 429s retry in lockstep and you get thundering-herd 429s on retry.
How to work with paginated requests
How to work with paginated requests
The trap is treating "fetch all" as one logical operation. Each page is its own API call and competes for tokens with everything else.
Two practical rules:
Don't hold the worker idle while paginating.
If page N takes 500ms and page N+1 needs to wait 800ms for a token, you've burned 800ms of worker time doing nothing. Instead, fetch page N, dispatch the
processing
of page N as a separate job, and queue a "fetch page N+1" job with a delay equal to the wait time. Each page becomes its own atomic unit.
Always batch where HubSpot offers it.
POST /crm/v3/objects/{type}/batch/{read|update|create}
accepts up to 100 IDs per call. For your "patching IDs" flow this is the difference between 600 calls and 6.
Walkthrough: 600 opportunities
Walkthrough: 600 opportunities
Naive flow (one PATCH per deal): 600 calls. At 190/10s that's ~32s of API time, well under daily. You'd hit burst easily without throttling. Plus likely 1-3 search calls upfront and N association calls.
Sane flow:
Identify deltas
β if you can avoid Search at all, do. Use
lastmodifieddate
filter on a single search if you must, paginate at limit=200. For 600 deals that's 3 search calls @ 5/s = ~600ms naturally throttled.
Batch read
current state β
POST /crm/v3/objects/deals/batch/read
with 100 IDs per call β 6 calls. Burst weight 6.
Compute diff
in your code (no API).
Batch update
β
POST /crm/v3/objects/deals/batch/update
with 100 per call β 6 calls.
Associations
β
POST /crm/v4/associations/{from}/{to}/batch/create
if needed β another few batch calls.
Total: ~15-20 API calls for 600 deals. Burst budget consumed: 20/190 over ~5s. Daily impact: trivial.
Recognition: pre-check denies if
<weight>
slots aren't free; on 429 the response surfaces
policyName
(DAILY/SECONDLY) β log it, push the job back with
Retry-After
delay, increment a metric so you can alarm on sustained 429 rate.
Pitfalls & bottlenecks worth pre-empting
Pitfalls & bottlenecks worth pre-empting
Daily quota is shared across the whole portal
, including any n8n flows, other private apps, marketing automation calling APIs, etc. Budget for ~70-80% of the documented limit, not 100%. Add an internal per-app daily cap so a runaway sync can't starve other apps.
Search is uniquely fragile
: separate 5/s bucket, no headers to read, 10k-result cap per query. If you ever hit 10k+ deals matching a filter, partition by
hs_object_id
ranges or by
lastmodifieddate
windows.
Retry storms after HubSpot incidents
β always jitter, always cap total retries (e.g., 5 attempts, then dead-letter).
Webhook β sync β webhook loops
β when your update fires a HubSpot webhook that triggers another sync. Tag your own writes (e.g., a custom property
jy_last_sync_id
) and ignore webhooks where it just changed.
Token refresh
β OAuth refresh itself counts against burst. Cache the access token in Redis with TTL =
expires_in - 60s
, single-flight the refresh (only one worker refreshes; others wait on a lock).
Search latency for fresh writes
β newly created/updated objects don't appear in search instantly. Don't write-then-search; use returned IDs directly.
Clock skew
β Redis is authoritative. Don't use
time()
from each worker for window scoring; use
redis.call('TIME')
inside the Lua script.
Dead workers with held tokens
β sliding-window-log handles this naturally because tokens expire by score; token-bucket implementations need explicit release-on-crash logic.
The 5% error rule
counts every 429 toward your error budget, even successfully retried ones. If your pre-check is working well, 429s should be near zero β if they're not, your pre-check is wrong, not just slow.
Phantom contention with Laravel
RateLimited
middleware
: it's per-job-class by default, not per-portal. If your
SyncDealJob
and
UpdateActivityJob
are different classes both calling HubSpot, they don't share a Laravel-level limiter β you need a single
HubspotRateLimiter
service that everything routes through.
If you want, I can sketch the Lua script for the sliding-window acquire and the Laravel service wrapper around it.
Copy
Give positive feedback
Give negative feedback
Retry
You said: What will happen if there are two different types of rate limits?
You said: What will happen if there are two different types of rate limits?
What will happen if there are two different types of rate limits?
Search requests that have 5 requests per second
The other rate limit that has, let's say, 100 requests per 10 seconds How do these work together? Is there some conflict? Can I reach the limit with one request and block either as well, or are these separated? Can I still continue making search requests once I hit the normal requests limits?
13:40
Retry
Edit
Copy
Claude responded: They're independent buckets β with one shared bucket on top.
Claude responded: They're independent buckets β with one shared bucket on top.
Analyzed independent rate limit buckets and their practical interactions
Analyzed independent rate limit buckets and their practical interactions
They're independent buckets β with one shared bucket on top.
The three buckets and what each call hits
The three buckets and what each call hits
Copy to clipboard
ββββββββββββββββββββ
Search request βββ β Search: 5/sec β βββ
ββββββββββββββββββββ β
ββββ βββββββββββββββββββ
ββββββββββββββββββββ β β Daily: 250kβ1M β
Non-search call βββ β Burst: 190/10s β βββ β (per portal) β
ββββββββββββββββββββ βββββββββββββββββββ
A search call is only metered against the search bucket and the daily bucket. A non-search call (batch read/update, single PATCH, associations, etc.) is only metered against the burst bucket and the daily bucket. The two short-window buckets do not share counters.
What this means practically
What this means practically
Hitting search secondly limit (5/s):
Only further
/search
calls 429. Your batch reads, batch updates, single PATCHes, association calls β all keep working at full burst speed. This is actually useful: if your sync is bottlenecked on Search, you can pivot to using
lastmodifieddate
filters via batch endpoints, or use the IDs you already have to do batch reads, while Search cools off.
Hitting burst limit (190/10s):
Only non-search calls 429. You can still issue Search calls at 5/s. Useful for: continuing to identify deltas for queueing while in-flight updates drain, or refreshing a small set of records via Search even though your write pipeline is paused.
Hitting daily limit:
Everything stops. Search and non-search alike. Doesn't unblock until midnight in your portal's configured timezone β and remember this is shared across every private app in the portal, plus n8n flows, marketing tools, anything else hitting the API with that account.
So can one type of request block the other?
So can one type of request block the other?
Search β Burst:
No.
Saturating Search at 50 calls per 10s leaves your full 190/10s burst untouched.
Burst β Search:
No.
Saturating burst leaves Search's 5/s untouched.
Either β Daily:
Yes
, but only by contributing to the same daily counter. It's volume that kills you here, not the type.
In theory you can sustain ~50 search + ~190 other =
~240 calls per 10 seconds
indefinitely (until daily runs out), because the two buckets bill independently.
Implementation consequence
Implementation consequence
Your rate limiter needs to know which bucket a request hits before it acquires. Cleanest pattern:
Copy to clipboard
php
$limiter
->
acquire
(
'search'
,
$weight
=
1
)
;
// for search endpoints only
$limiter
->
acquire
(
'burst'
,
$weight
=
1
)
;
// for everything else
$limiter
->
acquire
(
'daily'
,
$weight
=
1
)
;
// every call, both kinds
In Redis: three separate keys, three separate Lua acquire scripts (or one script with a bucket parameter). A search call calls
acquire('search')
+...
|
Claude
|
Claude
|
NULL
|
4352
|
|
4351
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Share chat
Claude finished the response
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
how to work with multiple jobs
how to work with paginated requests Let's consider a situation when there are 600 opportunities to sync. What would be the flow? How would the rate limit be recognized? How would it be handled? What are the potential issues? [API usage guidelines and limits - HubSpot docs](
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
). Example of such a error Client error:
POST https://api.hubapi.com/crm/v3/objects/contact/search
resulted in a
429 Too Many Requests
response: {"status":"error","message":"You have reached your secondly limit.","errorType":"RATE_LIMIT","correlationId":"019dffc4-4 (truncated...). Think carefully about the implementation and potential issue and bottlenecks.
Show more
10:42
Retry
Edit
Copy
Claude responded: Current HubSpot limits (Apr 2026)
Claude responded: Current HubSpot limits (Apr 2026)
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Current HubSpot limits (Apr 2026)
Current HubSpot limits (Apr 2026)
For privately distributed apps (which is what Jiminny presumably uses with HubSpot), the limits are layered: a per-app burst window of 100/10s on Free/Starter, 190/10s on Pro/Enterprise, or 250/10s with the API Limit Increase add-on
, plus a per-account daily cap of 250k / 625k / 1M depending on tier β shared across all private apps in the account
. The burst window is per app; the daily quota is per portal.
hubspot
hubspot
hubspot
hubspot
The Search API is special: five requests per second per account, capped at 200 records per page, with a hard 10,000-result ceiling per query
. That's the limit the 429 in your example is hitting (
secondly limit
on
/crm/v3/objects/contact/search
). It's a separate bucket from the 190/10s, and critically, search responses do not include the
X-HubSpot-RateLimit-*
headers
β you can't read remaining capacity off the response, you have to track it yourself.
hubspot
hubspot
hubspot
hubspot
Non-search endpoints return
X-HubSpot-RateLimit-Remaining
,
-Max
, and
-Interval-Milliseconds
. The daily headers are not returned for OAuth-authenticated calls
, so for those you check the account-info endpoint or maintain your own counter. There's also a soft rule: errors should stay under 5% of total daily requests
β that's enforced for marketplace listing, but it's also a sane operational target.
hubspot
hubspot
hubspot
hubspot
So you have
four buckets
to track at minimum: app-burst (10s sliding), search-secondly (1s sliding), account-daily (24h fixed, midnight in HubSpot's TZ), and per-app daily share (your own budgeting on top of the account cap).
Where to store it
Where to store it
Redis. It's the only realistic option once you have multiple queue workers β DB-backed counters serialize too much, and in-process state can't coordinate across workers. Laravel already speaks Redis natively, and you get atomic
INCR
/
EXPIRE
plus Lua scripting for true CAS semantics.
Key layout I'd use:
Copy to clipboard
hubspot:rl:burst:{portalId}:{appId} ZSET (sliding 10s)
hubspot:rl:search:{portalId} ZSET (sliding 1s)
hubspot:rl:daily:{portalId} STRING + TTL to midnight TZ
hubspot:rl:meta:{portalId} HASH (last seen headers)
The two short-window buckets are sliding-window-log (Redis ZSET, score =
microtime
, member = unique request id). Lua script removes entries older than the window, counts remaining slots, and only adds the new one if there's room β all atomic. Fixed windows are simpler but allow 2Γ the limit at the boundary, which on a 5/s window is brutal.
The daily bucket is a plain
INCR
with TTL set to seconds-until-midnight in
HubSpot's account timezone
, not yours β Sofia is UTC+2/+3 but your portal might be set to US Eastern. Get this once and cache it.
How to read it
How to read it
Two-phase: optimistic pre-check, authoritative post-update.
Before a call, run the Lua acquire script. If it returns "denied," sleep until a slot frees up (the script can return ms-until-next-slot) or push the job back to the queue with a delay. Don't busy-loop.
After the call, parse
X-HubSpot-RateLimit-Remaining
/
-Max
/
-Interval-Milliseconds
and store them in
hubspot:rl:meta:{portalId}
. This is your reality check β if your local counter says 50 remaining but HubSpot's header says 5, you trust HubSpot and clamp your counter. This handles clock drift, missed accounting (e.g., crashed worker that took a token but never made the request), and other apps in the same account consuming the daily budget invisibly.
For search specifically, since headers don't come back, the local counter
is
the source of truth β meaning if you ever crash mid-flight, you've under-counted. Always release tokens on connection-level failure but
not
on 429 (you really did make that request).
How to work with multiple jobs
How to work with multiple jobs
The queue layer needs to enforce concurrency separately from the rate limiter. Both work together:
Concurrency cap
via
Queue::throttle()
or a Redis semaphore β limits how many sync workers run in parallel against HubSpot. Without this, you can have 50 workers all blocked waiting for tokens, which is wasteful and creates retry storms.
Per-tenant fairness
β if you sync many Jiminny customers into different HubSpot portals, each portal has its own bucket but you still want one slow portal not to starve others. Either separate queues per portal or a fair-share scheduler.
Priority lanes
β webhook-driven updates (user-visible latency) should outrank background batch syncs. Two queues:
hubspot-priority
and
hubspot-bulk
, with priority workers taking 70% of the burst budget and bulk taking 30% (enforce via separate sub-buckets if you really want hard separation, otherwise just pull from priority first).
Backoff on 429
β respect the
Retry-After
header. If absent, exponential with jitter (e.g.,
min(2^attempt * 250ms, 30s) Β± 20%
). The jitter is non-negotiable; without it, simultaneous 429s retry in lockstep and you get thundering-herd 429s on retry.
How to work with paginated requests
How to work with paginated requests
The trap is treating "fetch all" as one logical operation. Each page is its own API call and competes for tokens with everything else.
Two practical rules:
Don't hold the worker idle while paginating.
If page N takes 500ms and page N+1 needs to wait 800ms for a token, you've burned 800ms of worker time doing nothing. Instead, fetch page N, dispatch the
processing
of page N as a separate job, and queue a "fetch page N+1" job with a delay equal to the wait time. Each page becomes its own atomic unit.
Always batch where HubSpot offers it.
POST /crm/v3/objects/{type}/batch/{read|update|create}
accepts up to 100 IDs per call. For your "patching IDs" flow this is the difference between 600 calls and 6.
Walkthrough: 600 opportunities
Walkthrough: 600 opportunities
Naive flow (one PATCH per deal): 600 calls. At 190/10s that's ~32s of API time, well under daily. You'd hit burst easily without throttling. Plus likely 1-3 search calls upfront and N association calls.
Sane flow:
Identify deltas
β if you can avoid Search at all, do. Use
lastmodifieddate
filter on a single search if you must, paginate at limit=200. For 600 deals that's 3 search calls @ 5/s = ~600ms naturally throttled.
Batch read
current state β
POST /crm/v3/objects/deals/batch/read
with 100 IDs per call β 6 calls. Burst weight 6.
Compute diff
in your code (no API).
Batch update
β
POST /crm/v3/objects/deals/batch/update
with 100 per call β 6 calls.
Associations
β
POST /crm/v4/associations/{from}/{to}/batch/create
if needed β another few batch calls.
Total: ~15-20 API calls for 600 deals. Burst budget consumed: 20/190 over ~5s. Daily impact: trivial.
Recognition: pre-check denies if
<weight>
slots aren't free; on 429 the response surfaces
policyName
(DAILY/SECONDLY) β log it, push the job back with
Retry-After
delay, increment a metric so you can alarm on sustained 429 rate.
Pitfalls & bottlenecks worth pre-empting
Pitfalls & bottlenecks worth pre-empting
Daily quota is shared across the whole portal
, including any n8n flows, other private apps, marketing automation calling APIs, etc. Budget for ~70-80% of the documented limit, not 100%. Add an internal per-app daily cap so a runaway sync can't starve other apps.
Search is uniquely fragile
: separate 5/s bucket, no headers to read, 10k-result cap per query. If you ever hit 10k+ deals matching a filter, partition by
hs_object_id
ranges or by
lastmodifieddate
windows.
Retry storms after HubSpot incidents
β always jitter, always cap total retries (e.g., 5 attempts, then dead-letter).
Webhook β sync β webhook loops
β when your update fires a HubSpot webhook that triggers another sync. Tag your own writes (e.g., a custom property
jy_last_sync_id
) and ignore webhooks where it just changed.
Token refresh
β OAuth refresh itself counts against burst. Cache the access token in Redis with TTL =
expires_in - 60s
, single-flight the refresh (only one worker refreshes; others wait on a lock).
Search latency for fresh writes
β newly created/updated objects don't appear in search instantly. Don't write-then-search; use returned IDs directly.
Clock skew
β Redis is authoritative. Don't use
time()
from each worker for window scoring; use
redis.call('TIME')
inside the Lua script.
Dead workers with held tokens
β sliding-window-log handles this naturally because tokens expire by score; token-bucket implementations need explicit release-on-crash logic.
The 5% error rule
counts every 429 toward your error budget, even successfully retried ones. If your pre-check is working well, 429s should be near zero β if they're not, your pre-check is wrong, not just slow.
Phantom contention with Laravel
RateLimited
middleware
: it's per-job-class by default, not per-portal. If your
SyncDealJob
and
UpdateActivityJob
are different classes both calling HubSpot, they don't share a Laravel-level limiter β you need a single
HubspotRateLimiter
service that everything routes through.
If you want, I can sketch the Lua script for the sliding-window acquire and the Laravel service wrapper around it.
Copy
Give positive feedback
Give negative feedback
Retry
You said: What will happen if there are two different types of rate limits?
You said: What will happen if there are two different types of rate limits?
What will happen if there are two different types of rate limits?
Search requests that have 5 requests per second
The other rate limit that has, let's say, 100 requests per 10 seconds How do these work together? Is there some conflict? Can I reach the limit with one request and block either as well, or are these separated? Can I still continue making search requests once I hit the normal requests limits?
13:40
Retry
Edit
Copy
Claude responded: They're independent buckets β with one shared bucket on top.
Claude responded: They're independent buckets β with one shared bucket on top.
Analyzed independent rate limit buckets and their practical interactions
Analyzed independent rate limit buckets and their practical interactions
They're independent buckets β with one shared bucket on top.
The three buckets and what each call hits
The three buckets and what each call hits
Copy to clipboard
ββββββββββββββββββββ
Search request βββ β Search: 5/sec β βββ
ββββββββββββββββββββ β
ββββ βββββββββββββββββββ
ββββββββββββββββββββ β β Daily: 250kβ1M β
Non-search call βββ β Burst: 190/10s β βββ β (per portal) β
ββββββββββββββββββββ βββββββββββββββββββ
A search call is only metered against the search bucket and the daily bucket. A non-search call (batch read/update, single PATCH, associations, etc.) is only metered against the burst bucket and the daily bucket. The two short-window buckets do not share counters.
What this means practically
What this means practically
Hitting search secondly limit (5/s):
Only further
/search
calls 429. Your batch reads, batch updates, single PATCHes, association calls β all keep working at full burst speed. This is actually useful: if your sync is bottlenecked on Search, you can pivot to using
lastmodifieddate
filters via batch endpoints, or use the IDs you already have to do batch reads, while Search cools off.
Hitting burst limit (190/10s):
Only non-search calls 429. You can still issue Search calls at 5/s. Useful for: continuing to identify deltas for queueing while in-flight updates drain, or refreshing a small set of records via Search even though your write pipeline is paused.
Hitting daily limit:
Everything stops. Search and non-search alike. Doesn't unblock until midnight in your portal's configured timezone β and remember this is shared across every private app in the portal, plus n8n flows, marketing tools, anything else hitting the API with that account.
So can one type of request block the other?
So can one type of request block the other?
Search β Burst:
No.
Saturating Search at 50 calls per 10s leaves your full 190/10s burst untouched.
Burst β Search:
No.
Saturating burst leaves Search's 5/s untouched.
Either β Daily:
Yes
, but only by contributing to the same daily counter. It's volume that kills you here, not the type.
In theory you can sustain ~50 search + ~190 other =
~240 calls per 10 seconds
indefinitely (until daily runs out), because the two buckets bill independently.
Implementation consequence
Implementation consequence
Your rate limiter needs to know which bucket a request hits before it acquires. Cleanest pattern:
Copy to clipboard
php
$limiter
->
acquire
(
'search'
,
$weight
=
1
)
;
// for search endpoints only
$limiter
->
acquire
(
'burst'
,
$weight
=
1
)
;
// for everything else
$limiter
->
acquire
(
'daily'
,
$weight
=
1
)
;...
|
Claude
|
Claude
|
NULL
|
4351
|
|
4350
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Share chat
Claude finished the response
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
how to work with multiple jobs
how to work with paginated requests Let's consider a situation when there are 600 opportunities to sync. What would be the flow? How would the rate limit be recognized? How would it be handled? What are the potential issues? [API usage guidelines and limits - HubSpot docs](
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
). Example of such a error Client error:
POST https://api.hubapi.com/crm/v3/objects/contact/search
resulted in a
429 Too Many Requests
response: {"status":"error","message":"You have reached your secondly limit.","errorType":"RATE_LIMIT","correlationId":"019dffc4-4 (truncated...). Think carefully about the implementation and potential issue and bottlenecks.
Show more
10:42
Retry
Edit
Copy
Claude responded: Current HubSpot limits (Apr 2026)
Claude responded: Current HubSpot limits (Apr 2026)
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Current HubSpot limits (Apr 2026)
Current HubSpot limits (Apr 2026)
For privately distributed apps (which is what Jiminny presumably uses with HubSpot), the limits are layered: a per-app burst window of 100/10s on Free/Starter, 190/10s on Pro/Enterprise, or 250/10s with the API Limit Increase add-on
, plus a per-account daily cap of 250k / 625k / 1M depending on tier β shared across all private apps in the account
. The burst window is per app; the daily quota is per portal.
hubspot
hubspot
hubspot
hubspot
The Search API is special: five requests per second per account, capped at 200 records per page, with a hard 10,000-result ceiling per query
. That's the limit the 429 in your example is hitting (
secondly limit
on
/crm/v3/objects/contact/search
). It's a separate bucket from the 190/10s, and critically, search responses do not include the
X-HubSpot-RateLimit-*
headers
β you can't read remaining capacity off the response, you have to track it yourself.
hubspot
hubspot
hubspot
hubspot
Non-search endpoints return
X-HubSpot-RateLimit-Remaining
,
-Max
, and
-Interval-Milliseconds
. The daily headers are not returned for OAuth-authenticated calls
, so for those you check the account-info endpoint or maintain your own counter. There's also a soft rule: errors should stay under 5% of total daily requests
β that's enforced for marketplace listing, but it's also a sane operational target.
hubspot
hubspot
hubspot
hubspot
So you have
four buckets
to track at minimum: app-burst (10s sliding), search-secondly (1s sliding), account-daily (24h fixed, midnight in HubSpot's TZ), and per-app daily share (your own budgeting on top of the account cap).
Where to store it
Where to store it
Redis. It's the only realistic option once you have multiple queue workers β DB-backed counters serialize too much, and in-process state can't coordinate across workers. Laravel already speaks Redis natively, and you get atomic
INCR
/
EXPIRE
plus Lua scripting for true CAS semantics.
Key layout I'd use:
Copy to clipboard
hubspot:rl:burst:{portalId}:{appId} ZSET (sliding 10s)
hubspot:rl:search:{portalId} ZSET (sliding 1s)
hubspot:rl:daily:{portalId} STRING + TTL to midnight TZ
hubspot:rl:meta:{portalId} HASH (last seen headers)
The two short-window buckets are sliding-window-log (Redis ZSET, score =
microtime
, member = unique request id). Lua script removes entries older than the window, counts remaining slots, and only adds the new one if there's room β all atomic. Fixed windows are simpler but allow 2Γ the limit at the boundary, which on a 5/s window is brutal.
The daily bucket is a plain
INCR
with TTL set to seconds-until-midnight in
HubSpot's account timezone
, not yours β Sofia is UTC+2/+3 but your portal might be set to US Eastern. Get this once and cache it.
How to read it
How to read it
Two-phase: optimistic pre-check, authoritative post-update.
Before a call, run the Lua acquire script. If it returns "denied," sleep until a slot frees up (the script can return ms-until-next-slot) or push the job back to the queue with a delay. Don't busy-loop.
After the call, parse
X-HubSpot-RateLimit-Remaining
/
-Max
/
-Interval-Milliseconds
and store them in
hubspot:rl:meta:{portalId}
. This is your reality check β if your local counter says 50 remaining but HubSpot's header says 5, you trust HubSpot and clamp your counter. This handles clock drift, missed accounting (e.g., crashed worker that took a token but never made the request), and other apps in the same account consuming the daily budget invisibly.
For search specifically, since headers don't come back, the local counter
is
the source of truth β meaning if you ever crash mid-flight, you've under-counted. Always release tokens on connection-level failure but
not
on 429 (you really did make that request).
How to work with multiple jobs
How to work with multiple jobs
The queue layer needs to enforce concurrency separately from the rate limiter. Both work together:
Concurrency cap
via
Queue::throttle()
or a Redis semaphore β limits how many sync workers run in parallel against HubSpot. Without this, you can have 50 workers all blocked waiting for tokens, which is wasteful and creates retry storms.
Per-tenant fairness
β if you sync many Jiminny customers into different HubSpot portals, each portal has its own bucket but you still want one slow portal not to starve others. Either separate queues per portal or a fair-share scheduler.
Priority lanes
β webhook-driven updates (user-visible latency) should outrank background batch syncs. Two queues:
hubspot-priority
and
hubspot-bulk
, with priority workers taking 70% of the burst budget and bulk taking 30% (enforce via separate sub-buckets if you really want hard separation, otherwise just pull from priority first).
Backoff on 429
β respect the
Retry-After
header. If absent, exponential with jitter (e.g.,
min(2^attempt * 250ms, 30s) Β± 20%
). The jitter is non-negotiable; without it, simultaneous 429s retry in lockstep and you get thundering-herd 429s on retry.
How to work with paginated requests
How to work with paginated requests
The trap is treating "fetch all" as one logical operation. Each page is its own API call and competes for tokens with everything else.
Two practical rules:
Don't hold the worker idle while paginating.
If page N takes 500ms and page N+1 needs to wait 800ms for a token, you've burned 800ms of worker time doing nothing. Instead, fetch page N, dispatch the
processing
of page N as a separate job, and queue a "fetch page N+1" job with a delay equal to the wait time. Each page becomes its own atomic unit.
Always batch where HubSpot offers it.
POST /crm/v3/objects/{type}/batch/{read|update|create}
accepts up to 100 IDs per call. For your "patching IDs" flow this is the difference between 600 calls and 6.
Walkthrough: 600 opportunities
Walkthrough: 600 opportunities
Naive flow (one PATCH per deal): 600 calls. At 190/10s that's ~32s of API time, well under daily. You'd hit burst easily without throttling. Plus likely 1-3 search calls upfront and N association calls.
Sane flow:
Identify deltas
β if you can avoid Search at all, do. Use
lastmodifieddate
filter on a single search if you must, paginate at limit=200. For 600 deals that's 3 search calls @ 5/s = ~600ms naturally throttled.
Batch read
current state β
POST /crm/v3/objects/deals/batch/read
with 100 IDs per call β 6 calls. Burst weight 6.
Compute diff
in your code (no API).
Batch update
β
POST /crm/v3/objects/deals/batch/update
with 100 per call β 6 calls.
Associations
β
POST /crm/v4/associations/{from}/{to}/batch/create
if needed β another few batch calls.
Total: ~15-20 API calls for 600 deals. Burst budget consumed: 20/190 over ~5s. Daily impact: trivial.
Recognition: pre-check denies if
<weight>
slots aren't free; on 429 the response surfaces
policyName
(DAILY/SECONDLY) β log it, push the job back with
Retry-After
delay, increment a metric so you can alarm on sustained 429 rate.
Pitfalls & bottlenecks worth pre-empting
Pitfalls & bottlenecks worth pre-empting
Daily quota is shared across the whole portal
, including any n8n flows, other private apps, marketing automation calling APIs, etc. Budget for ~70-80% of the documented limit, not 100%. Add an internal per-app daily cap so a runaway sync can't starve other apps.
Search is uniquely fragile
: separate 5/s bucket, no headers to read, 10k-result cap per query. If you ever hit 10k+ deals matching a filter, partition by
hs_object_id
ranges or by
lastmodifieddate
windows.
Retry storms after HubSpot incidents
β always jitter, always cap total retries (e.g., 5 attempts, then dead-letter).
Webhook β sync β webhook loops
β when your update fires a HubSpot webhook that triggers another sync. Tag your own writes (e.g., a custom property
jy_last_sync_id
) and ignore webhooks where it just changed.
Token refresh
β OAuth refresh itself counts against burst. Cache the access token in Redis with TTL =
expires_in - 60s
, single-flight the refresh (only one worker refreshes; others wait on a lock).
Search latency for fresh writes
β newly created/updated objects don't appear in search instantly. Don't write-then-search; use returned IDs directly.
Clock skew
β Redis is authoritative. Don't use
time()
from each worker for window scoring; use
redis.call('TIME')
inside the Lua script.
Dead workers with held tokens
β sliding-window-log handles this naturally because tokens expire by score; token-bucket implementations need explicit release-on-crash logic.
The 5% error rule
counts every 429 toward your error budget, even successfully retried ones. If your pre-check is working well, 429s should be near zero β if they're not, your pre-check is wrong, not just slow.
Phantom contention with Laravel
RateLimited
middleware
: it's per-job-class by default, not per-portal. If your
SyncDealJob
and
UpdateActivityJob
are different classes both calling HubSpot, they don't share a Laravel-level limiter β you need a single
HubspotRateLimiter
service that everything routes through.
If you want, I can sketch the Lua script for the sliding-window acquire and the Laravel service wrapper around it.
Copy
Give positive feedback
Give negative feedback
Retry
You said: What will happen if there are two different types of rate limits?
You said: What will happen if there are two different types of rate limits?
What will happen if there are two different types of rate limits?
Search requests that have 5 requests per second
The other rate limit that has, let's say, 100 requests per 10 seconds How do these work together? Is there some conflict? Can I reach the limit with one request and block either as well, or are these separated? Can I still continue making search requests once I hit the normal requests limits?
13:40
Retry
Edit
Copy
Claude responded: They're independent buckets β with one shared bucket on top.
Claude responded: They're independent buckets β with one shared bucket on top.
Analyzed independent rate limit buckets and their practical interactions
Analyzed independent rate limit buckets and their practical interactions
They're independent buckets β with one shared bucket on top.
The three buckets and what each call hits
The three buckets and what each call hits
Copy to clipboard
ββββββββββββββββββββ
Search request βββ β Search: 5/sec β βββ
ββββββββββββββββββββ β
ββββ βββββββββββββββββββ
ββββββββββββββββββββ β β Daily: 250kβ1M β
Non-search call βββ β Burst: 190/10s β βββ β (per portal) β
ββββββββββββββββββββ βββββββββββββββββββ
A search call is only metered against the search bucket and the daily bucket. A non-search call (batch read/update, single PATCH, associations, etc.) is only metered against the burst bucket and the daily bucket. The two short-window buckets do not share counters.
What this means practically
What this means practically
Hitting search secondly limit (5/s):
Only further
/search
calls 429. Your batch reads, batch updates, single PATCHes, association calls β all keep working at full burst speed. This is actually useful: if your sync is bottlenecked on Search, you can pivot to using
lastmodifieddate
filters via batch endpoints, or use the IDs you already have to do batch reads, while Search cools off.
Hitting burst limit (190/10s):
Only non-search calls 429. You can still issue Search calls at 5/s. Useful for: continuing to identify deltas for queueing while in-flight updates drain, or refreshing a small set of records via Search even though your write pipeline is paused.
Hitting daily limit:
Everything stops. Search and non-search alike. Doesn't unblock until midnight in your portal's configured timezone β and remember this is shared across every private app in the portal, plus n8n flows, marketing tools, anything else hitting the API with that account.
So can one type of request block the other?
So can one type of request block the other?
Search β Burst:
No.
Saturating Search at 50 calls per 10s leaves your full 190/10s burst untouched.
Burst β Search:
No.
Saturating burst leaves Search's 5/s untouched.
Either β Daily:
Yes
, but only by contributing to the same daily counter. It's volume that kills you here, not the type.
In theory you can sustain ~50 search + ~190 other =
~240 calls per 10 seconds
indefinitely (until daily runs out), because the two buckets bill independently.
Implementation consequence
Implementation consequence
Your rate limiter needs to know which bucket a request hits before it acquires. Cleanest pattern:
Copy to clipboard
php
$limiter
->
acquire
(
'search'
,
$weight
=
1
)
;
// for search endpoints only
$limiter
->
acquire
(
'burst'
,
$weight
=
1
)
;
// for everything else
$limiter
->
acquire
(
'daily'
,
$weight
=
1
)
;
// every call, both kinds
In Redis: three separate keys, three separate Lua acquire scripts (or one script with a bucket parameter). A search call calls
acquire('search')
+
acquire('daily')
. A batch update calls
acquire('burst')
+
acquire('daily')
.
One subtle pitfall: when you backoff on a 429,
inspect
policyName
in the response body
to know which bucket actually fired. If you see
SECONDLY
from a search endpoint, you only need to delay search-bound jobs β burst-bound jobs in the queue can keep running. If you blanket-pause everything on any 429, you waste capacity on the bucket that's still healthy. Two queues (or two throttle keys) make this clean; one global pause is the lazy version.
The other subtlety: the burst response gives you
X-HubSpot-RateLimit-Remaining
to clamp local state against, but search doesn't return those headers. So your search counter is unverified β be slightly more conservative there (e.g., budget 4/s instead of 5) to absorb the unaccounted-for calls.
Copy
Give positive feedback
Give negative feedback
Retry
You said: Ok, so what will happen each time I make a request?
You said: Ok, so what will happen each time I make a request?
Ok, so what will happen each time I make a request? Let's say I have 100,000 requests to make that are instant. Do I need to increment each request based on the type? For example, if there is a search request, I need to increment both the search bucket and also the daily bucket. If it's a burst, then I can go to the daily and burst buckets. If I need to check if it can make a call, do I need to see both the daily and search, or burst, respectively? Isn't that too heavy for the infrastructure, adding additional load to each request?
13:44
Retry
Edit
Copy
Claude responded: Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out.
Claude responded: Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out.
Analyzed per-request overhead concerns and quantified Redis performance impact
Analyzed per-request overhead concerns and quantified Redis performance impact
Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out. But the overhead is much smaller than it sounds, and importantly, it's nowhere near your bottleneck.
What "two buckets per request" actually costs
What "two buckets per request" actually costs
Each request makes
one round trip to Redis
β not two β because you fold both bucket checks into a single Lua script that runs atomically server-side:
Copy to clipboard
lua
-- KEYS[1] = burst bucket key (or search)
-- KEYS[2] = daily bucket key
-- ARGV[1] = now (ms) ARGV[2] = window_ms
-- ARGV[3] = bucket_max ARGV[4] = daily_max
-- ARGV[5] = request_id ARGV[6] = daily_ttl
-- Trim sliding window
redis
.
call
(
'ZREMRANGEBYSCORE'
,
KEYS
[
1
]
,
0
,
ARGV
[
1
]
-
ARGV
[
2
]
)
local
burst_used
=
redis
.
call
(
'ZCARD'
,
KEYS
[
1
]
)
local
daily_used
=
tonumber
(
redis
.
call
(
'GET'
,
KEYS
[
2
]
)
or
'0'
)
if
burst_used
>=
tonumber
(
ARGV
[
3
]
)
then
-- Tell caller how long to sleep until oldest entry expires
local
oldest
=
redis
.
call
(
'ZRANGE'
,
KEYS
[
1
]
,
0
,
0
,
'WITHSCORES'
)
return
{
0
,
'BURST'
,
(
oldest
[
2
]
+
ARGV
[
2
]
)
-
ARGV
[
1
]
}
end
if
daily_used
>=
tonumber
(
ARGV
[
4
]
)
then
return
{
0
,
'DAILY'
,
-
1
}
end...
|
Claude
|
Claude
|
NULL
|
4350
|
|
4349
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Share chat
Claude finished the response
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
how to work with multiple jobs
how to work with paginated requests Let's consider a situation when there are 600 opportunities to sync. What would be the flow? How would the rate limit be recognized? How would it be handled? What are the potential issues? [API usage guidelines and limits - HubSpot docs](
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
). Example of such a error Client error:
POST https://api.hubapi.com/crm/v3/objects/contact/search
resulted in a
429 Too Many Requests
response: {"status":"error","message":"You have reached your secondly limit.","errorType":"RATE_LIMIT","correlationId":"019dffc4-4 (truncated...). Think carefully about the implementation and potential issue and bottlenecks.
Show more
10:42
Retry
Edit
Copy
Claude responded: Current HubSpot limits (Apr 2026)
Claude responded: Current HubSpot limits (Apr 2026)
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Current HubSpot limits (Apr 2026)
Current HubSpot limits (Apr 2026)
For privately distributed apps (which is what Jiminny presumably uses with HubSpot), the limits are layered: a per-app burst window of 100/10s on Free/Starter, 190/10s on Pro/Enterprise, or 250/10s with the API Limit Increase add-on
, plus a per-account daily cap of 250k / 625k / 1M depending on tier β shared across all private apps in the account
. The burst window is per app; the daily quota is per portal.
hubspot
hubspot
hubspot
hubspot
The Search API is special: five requests per second per account, capped at 200 records per page, with a hard 10,000-result ceiling per query
. That's the limit the 429 in your example is hitting (
secondly limit
on
/crm/v3/objects/contact/search
). It's a separate bucket from the 190/10s, and critically, search responses do not include the
X-HubSpot-RateLimit-*
headers
β you can't read remaining capacity off the response, you have to track it yourself.
hubspot
hubspot
hubspot
hubspot
Non-search endpoints return
X-HubSpot-RateLimit-Remaining
,
-Max
, and
-Interval-Milliseconds
. The daily headers are not returned for OAuth-authenticated calls
, so for those you check the account-info endpoint or maintain your own counter. There's also a soft rule: errors should stay under 5% of total daily requests
β that's enforced for marketplace listing, but it's also a sane operational target.
hubspot
hubspot
hubspot
hubspot
So you have
four buckets
to track at minimum: app-burst (10s sliding), search-secondly (1s sliding), account-daily (24h fixed, midnight in HubSpot's TZ), and per-app daily share (your own budgeting on top of the account cap).
Where to store it
Where to store it
Redis. It's the only realistic option once you have multiple queue workers β DB-backed counters serialize too much, and in-process state can't coordinate across workers. Laravel already speaks Redis natively, and you get atomic
INCR
/
EXPIRE
plus Lua scripting for true CAS semantics.
Key layout I'd use:
Copy to clipboard
hubspot:rl:burst:{portalId}:{appId} ZSET (sliding 10s)
hubspot:rl:search:{portalId} ZSET (sliding 1s)
hubspot:rl:daily:{portalId} STRING + TTL to midnight TZ
hubspot:rl:meta:{portalId} HASH (last seen headers)
The two short-window buckets are sliding-window-log (Redis ZSET, score =
microtime
, member = unique request id). Lua script removes entries older than the window, counts remaining slots, and only adds the new one if there's room β all atomic. Fixed windows are simpler but allow 2Γ the limit at the boundary, which on a 5/s window is brutal.
The daily bucket is a plain
INCR
with TTL set to seconds-until-midnight in
HubSpot's account timezone
, not yours β Sofia is UTC+2/+3 but your portal might be set to US Eastern. Get this once and cache it.
How to read it
How to read it
Two-phase: optimistic pre-check, authoritative post-update.
Before a call, run the Lua acquire script. If it returns "denied," sleep until a slot frees up (the script can return ms-until-next-slot) or push the job back to the queue with a delay. Don't busy-loop.
After the call, parse
X-HubSpot-RateLimit-Remaining
/
-Max
/
-Interval-Milliseconds
and store them in
hubspot:rl:meta:{portalId}
. This is your reality check β if your local counter says 50 remaining but HubSpot's header says 5, you trust HubSpot and clamp your counter. This handles clock drift, missed accounting (e.g., crashed worker that took a token but never made the request), and other apps in the same account consuming the daily budget invisibly.
For search specifically, since headers don't come back, the local counter
is
the source of truth β meaning if you ever crash mid-flight, you've under-counted. Always release tokens on connection-level failure but
not
on 429 (you really did make that request).
How to work with multiple jobs
How to work with multiple jobs
The queue layer needs to enforce concurrency separately from the rate limiter. Both work together:
Concurrency cap
via
Queue::throttle()
or a Redis semaphore β limits how many sync workers run in parallel against HubSpot. Without this, you can have 50 workers all blocked waiting for tokens, which is wasteful and creates retry storms.
Per-tenant fairness
β if you sync many Jiminny customers into different HubSpot portals, each portal has its own bucket but you still want one slow portal not to starve others. Either separate queues per portal or a fair-share scheduler.
Priority lanes
β webhook-driven updates (user-visible latency) should outrank background batch syncs. Two queues:
hubspot-priority
and
hubspot-bulk
, with priority workers taking 70% of the burst budget and bulk taking 30% (enforce via separate sub-buckets if you really want hard separation, otherwise just pull from priority first).
Backoff on 429
β respect the
Retry-After
header. If absent, exponential with jitter (e.g.,
min(2^attempt * 250ms, 30s) Β± 20%
). The jitter is non-negotiable; without it, simultaneous 429s retry in lockstep and you get thundering-herd 429s on retry.
How to work with paginated requests
How to work with paginated requests
The trap is treating "fetch all" as one logical operation. Each page is its own API call and competes for tokens with everything else.
Two practical rules:
Don't hold the worker idle while paginating.
If page N takes 500ms and page N+1 needs to wait 800ms for a token, you've burned 800ms of worker time doing nothing. Instead, fetch page N, dispatch the
processing
of page N as a separate job, and queue a "fetch page N+1" job with a delay equal to the wait time. Each page becomes its own atomic unit.
Always batch where HubSpot offers it.
POST /crm/v3/objects/{type}/batch/{read|update|create}
accepts up to 100 IDs per call. For your "patching IDs" flow this is the difference between 600 calls and 6.
Walkthrough: 600 opportunities
Walkthrough: 600 opportunities
Naive flow (one PATCH per deal): 600 calls. At 190/10s that's ~32s of API time, well under daily. You'd hit burst easily without throttling. Plus likely 1-3 search calls upfront and N association calls.
Sane flow:
Identify deltas
β if you can avoid Search at all, do. Use
lastmodifieddate
filter on a single search if you must, paginate at limit=200. For 600 deals that's 3 search calls @ 5/s = ~600ms naturally throttled.
Batch read
current state β
POST /crm/v3/objects/deals/batch/read
with 100 IDs per call β 6 calls. Burst weight 6.
Compute diff
in your code (no API).
Batch update
β
POST /crm/v3/objects/deals/batch/update
with 100 per call β 6 calls.
Associations
β
POST /crm/v4/associations/{from}/{to}/batch/create
if needed β another few batch calls.
Total: ~15-20 API calls for 600 deals. Burst budget consumed: 20/190 over ~5s. Daily impact: trivial.
Recognition: pre-check denies if
<weight>
slots aren't free; on 429 the response surfaces
policyName
(DAILY/SECONDLY) β log it, push the job back with
Retry-After
delay, increment a metric so you can alarm on sustained 429 rate.
Pitfalls & bottlenecks worth pre-empting
Pitfalls & bottlenecks worth pre-empting
Daily quota is shared across the whole portal
, including any n8n flows, other private apps, marketing automation calling APIs, etc. Budget for ~70-80% of the documented limit, not 100%. Add an internal per-app daily cap so a runaway sync can't starve other apps.
Search is uniquely fragile
: separate 5/s bucket, no headers to read, 10k-result cap per query. If you ever hit 10k+ deals matching a filter, partition by
hs_object_id
ranges or by
lastmodifieddate
windows.
Retry storms after HubSpot incidents
β always jitter, always cap total retries (e.g., 5 attempts, then dead-letter).
Webhook β sync β webhook loops
β when your update fires a HubSpot webhook that triggers another sync. Tag your own writes (e.g., a custom property
jy_last_sync_id
) and ignore webhooks where it just changed.
Token refresh
β OAuth refresh itself counts against burst. Cache the access token in Redis with TTL =
expires_in - 60s
, single-flight the refresh (only one worker refreshes; others wait on a lock).
Search latency for fresh writes
β newly created/updated objects don't appear in search instantly. Don't write-then-search; use returned IDs directly.
Clock skew
β Redis is authoritative. Don't use
time()
from each worker for window scoring; use
redis.call('TIME')
inside the Lua script.
Dead workers with held tokens
β sliding-window-log handles this naturally because tokens expire by score; token-bucket implementations need explicit release-on-crash logic.
The 5% error rule
counts every 429 toward your error budget, even successfully retried ones. If your pre-check is working well, 429s should be near zero β if they're not, your pre-check is wrong, not just slow.
Phantom contention with Laravel
RateLimited
middleware
: it's per-job-class by default, not per-portal. If your
SyncDealJob
and
UpdateActivityJob
are different classes both calling HubSpot, they don't share a Laravel-level limiter β you need a single
HubspotRateLimiter
service that everything routes through.
If you want, I can sketch the Lua script for the sliding-window acquire and the Laravel service wrapper around it.
Copy
Give positive feedback
Give negative feedback
Retry
You said: What will happen if there are two different types of rate limits?
You said: What will happen if there are two different types of rate limits?
What will happen if there are two different types of rate limits?
Search requests that have 5 requests per second
The other rate limit that has, let's say, 100 requests per 10 seconds How do these work together? Is there some conflict? Can I reach the limit with one request and block either as well, or are these separated? Can I still continue making search requests once I hit the normal requests limits?
13:40
Retry
Edit
Copy
Claude responded: They're independent buckets β with one shared bucket on top.
Claude responded: They're independent buckets β with one shared bucket on top.
Analyzed independent rate limit buckets and their practical interactions
Analyzed independent rate limit buckets and their practical interactions
They're independent buckets β with one shared bucket on top.
The three buckets and what each call hits
The three buckets and what each call hits
Copy to clipboard
ββββββββββββββββββββ
Search request βββ β Search: 5/sec β βββ
ββββββββββββββββββββ β
ββββ βββββββββββββββββββ
ββββββββββββββββββββ β β Daily: 250kβ1M β
Non-search call βββ β Burst: 190/10s β βββ β (per portal) β
ββββββββββββββββββββ βββββββββββββββββββ
A search call is only metered against the search bucket and the daily bucket. A non-search call (batch read/update, single PATCH, associations, etc.) is only metered against the burst bucket and the daily bucket. The two short-window buckets do not share counters.
What this means practically
What this means practically
Hitting search secondly limit (5/s):
Only further
/search
calls 429. Your batch reads, batch updates, single PATCHes, association calls β all keep working at full burst speed. This is actually useful: if your sync is bottlenecked on Search, you can pivot to using
lastmodifieddate
filters via batch endpoints, or use the IDs you already have to do batch reads, while Search cools off.
Hitting burst limit (190/10s):
Only non-search calls 429. You can still issue Search calls at 5/s. Useful for: continuing to identify deltas for queueing while in-flight updates drain, or refreshing a small set of records via Search even though your write pipeline is paused.
Hitting daily limit:
Everything stops. Search and non-search alike. Doesn't unblock until midnight in your portal's configured timezone β and remember this is shared across every private app in the portal, plus n8n flows, marketing tools, anything else hitting the API with that account.
So can one type of request block the other?
So can one type of request block the other?
Search β Burst:
No.
Saturating Search at 50 calls per 10s leaves your full 190/10s burst untouched.
Burst β Search:
No.
Saturating burst leaves Search's 5/s untouched.
Either β Daily:
Yes
, but only by contributing to the same daily counter. It's volume that kills you here, not the type.
In theory you can sustain ~50 search + ~190 other =
~240 calls per 10 seconds
indefinitely (until daily runs out), because the two buckets bill independently.
Implementation consequence
Implementation consequence
Your rate limiter needs to know which bucket a request hits before it acquires. Cleanest pattern:
Copy to clipboard
php
$limiter
->
acquire
(
'search'
,
$weight
=
1
)
;
// for search endpoints only
$limiter
->
acquire
(
'burst'
,
$weight
=
1
)
;
// for everything else
$limiter
->
acquire
(
'daily'
,
$weight
=
1
)
;
// every call, both kinds
In Redis: three separate keys, three separate Lua acquire scripts (or one script with a bucket parameter). A search call calls
acquire('search')
+
acquire('daily')
. A batch update calls
acquire('burst')
+
acquire('daily')
.
One subtle pitfall: when you backoff on a 429,
inspect
policyName
in the response body
to know which bucket actually fired. If you see
SECONDLY
from a search endpoint, you only need to delay search-bound jobs β burst-bound jobs in the queue can keep running. If you blanket-pause everything on any 429, you waste capacity on the bucket that's still healthy. Two queues (or two throttle keys) make this clean; one global pause is the lazy version.
The other subtlety: the burst response gives you
X-HubSpot-RateLimit-Remaining
to clamp local state against, but search doesn't return those headers. So your search counter is unverified β be slightly more conservative there (e.g., budget 4/s instead of 5) to absorb the unaccounted-for calls.
Copy
Give positive feedback
Give negative feedback
Retry
You said: Ok, so what will happen each time I make a request?
You said: Ok, so what will happen each time I make a request?
Ok, so what will happen each time I make a request? Let's say I have 100,000 requests to make that are instant. Do I need to increment each request based on the type? For example, if there is a search request, I need to increment both the search bucket and also the daily bucket. If it's a burst, then I can go to the daily and burst buckets. If I need to check if it can make a call, do I need to see both the daily and search, or burst, respectively? Isn't that too heavy for the infrastructure, adding additional load to each request?
13:44
Retry
Edit
Copy
Claude responded: Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out.
Claude responded: Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out.
Analyzed per-request overhead concerns and quantified Redis performance impact
Analyzed per-request overhead concerns and quantified Redis performance impact
Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out. But the overhead is much smaller than it sounds, and importantly, it's nowhere near your bottleneck.
What "two buckets per request" actually costs
What "two buckets per request" actually costs
Each request makes
one round trip to Redis
β not two β because you fold both bucket checks into a single Lua script that runs atomically server-side:
Copy to clipboard
lua
-- KEYS[1] = burst bucket key (or search)
-- KEYS[2] = daily bucket key
-- ARGV[1] = now (ms) ARGV[2] = window_ms
-- ARGV[3] = bucket_max ARGV[4] = daily_max
-- ARGV[5] = request_id ARGV[6] = daily_ttl
-- Trim sliding window
redis
.
call
(
'ZREMRANGEBYSCORE'
,
KEYS
[
1
]
,
0
,
ARGV
[
1
]
-
ARGV
[
2
]
)
local
burst_used
=
redis
.
call
(
'ZCARD'
,
KEYS
[
1
]
)
local
daily_used
=
tonumber
(
redis
.
call
(
'GET'
,
KEYS
[
2
]
)
or
'0'
)
if
burst_used
>=
tonumber
(
ARGV
[
3
]
)
then
-- Tell caller how long to sleep until oldest entry expires
local
oldest
=
redis
.
call
(
'ZRANGE'
,
KEYS
[
1
]
,
0
,
0
,
'WITHSCORES'
)
return
{
0
,
'BURST'
,
(...
|
Claude
|
Claude
|
NULL
|
4349
|
|
4348
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Share chat
Claude finished the response
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
how to work with multiple jobs
how to work with paginated requests Let's consider a situation when there are 600 opportunities to sync. What would be the flow? How would the rate limit be recognized? How would it be handled? What are the potential issues? [API usage guidelines and limits - HubSpot docs](
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
). Example of such a error Client error:
POST https://api.hubapi.com/crm/v3/objects/contact/search
resulted in a
429 Too Many Requests
response: {"status":"error","message":"You have reached your secondly limit.","errorType":"RATE_LIMIT","correlationId":"019dffc4-4 (truncated...). Think carefully about the implementation and potential issue and bottlenecks.
Show more
10:42
Retry
Edit
Copy
Claude responded: Current HubSpot limits (Apr 2026)
Claude responded: Current HubSpot limits (Apr 2026)
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Current HubSpot limits (Apr 2026)
Current HubSpot limits (Apr 2026)
For privately distributed apps (which is what Jiminny presumably uses with HubSpot), the limits are layered: a per-app burst window of 100/10s on Free/Starter, 190/10s on Pro/Enterprise, or 250/10s with the API Limit Increase add-on
, plus a per-account daily cap of 250k / 625k / 1M depending on tier β shared across all private apps in the account
. The burst window is per app; the daily quota is per portal.
hubspot
hubspot
hubspot
hubspot
The Search API is special: five requests per second per account, capped at 200 records per page, with a hard 10,000-result ceiling per query
. That's the limit the 429 in your example is hitting (
secondly limit
on
/crm/v3/objects/contact/search
). It's a separate bucket from the 190/10s, and critically, search responses do not include the
X-HubSpot-RateLimit-*
headers
β you can't read remaining capacity off the response, you have to track it yourself.
hubspot
hubspot
hubspot
hubspot
Non-search endpoints return
X-HubSpot-RateLimit-Remaining
,
-Max
, and
-Interval-Milliseconds
. The daily headers are not returned for OAuth-authenticated calls
, so for those you check the account-info endpoint or maintain your own counter. There's also a soft rule: errors should stay under 5% of total daily requests
β that's enforced for marketplace listing, but it's also a sane operational target.
hubspot
hubspot
hubspot
hubspot
So you have
four buckets
to track at minimum: app-burst (10s sliding), search-secondly (1s sliding), account-daily (24h fixed, midnight in HubSpot's TZ), and per-app daily share (your own budgeting on top of the account cap).
Where to store it
Where to store it
Redis. It's the only realistic option once you have multiple queue workers β DB-backed counters serialize too much, and in-process state can't coordinate across workers. Laravel already speaks Redis natively, and you get atomic
INCR
/
EXPIRE...
|
Claude
|
Claude
|
NULL
|
4348
|
|
4347
|
Project: faVsco.js, menu
master, menu
Start Listen Project: faVsco.js, menu
master, menu
Start Listening for PHP Debug Connections
AskJiminnyReportActivityServiceTest
Run 'AskJiminnyReportActivityServiceTest'
Debug 'AskJiminnyReportActivityServiceTest'
More Actions
JetBrains AI
Search Everywhere
IDE and Project Settings
Sync Changes
Hide This Notification
Code changed:
Hide
604
Previous Highlighted Error
Next Highlighted Error
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Fetching token {"socialAccountId":1499,"provider":"hubspot"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Token needs refreshing {"socialAccountId":1499,"provider":"hubspot"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":1499,"provider":"hubspot","refreshToken":"96f94c623a404e02ebdbf07f1b75707bb6cdbf848cbf45d418baf608c41a8d86","state":"connected"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountObserver] Saving model {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountObserver] Access token was modified, encrypting {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [SocialAccountService] Token refreshed {"socialAccountId":1499,"provider":"hubspot","state":"connected"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [CrmOwnerResolver] Integration owner matched as CRM Owner {"crm_provider":"hubspot","crm_owner":148,"team_id":2} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [Hubspot] Received 429 from API {"team_id":2,"config_id":2,"retry_after":10,"reason":"Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.ERROR: Hubspot returned 429 {"exception":"[object] (Jiminny\\Exceptions\\RateLimitException(code: 0): Hubspot returned 429 at /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php:206)
[stacktrace]
#0 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#1 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#2 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#3 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#4 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#5 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#6 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#7 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#8 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#9 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#10 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#11 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#12 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#13 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#14 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#15 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#16 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#17 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#18 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#19 {main}
[previous exception] [object] (SevenShores\\Hubspot\\Exceptions\\BadRequest(code: 429): Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
at /home/jiminny/vendor/hubspot/hubspot-php/src/Exceptions/HubspotException.php:24)
[stacktrace]
#0 /home/jiminny/vendor/hubspot/hubspot-php/src/Http/Client.php(125): SevenShores\\Hubspot\\Exceptions\\HubspotException::create(Object(GuzzleHttp\\Exception\\ClientException))
#1 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(166): SevenShores\\Hubspot\\Http\\Client->request('POST', 'https://api.hub...', Array)
#2 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#3 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#4 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#5 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#6 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#7 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#8 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#9 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#10 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#11 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#12 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#13 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#14 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#15 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#16 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#17 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#18 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#19 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#20 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#21 {main}
[previous exception] [object] (GuzzleHttp\\Exception\\ClientException(code: 429): Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
at /home/jiminny/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:111)
[stacktrace]
#0 /home/jiminny/vendor/guzzlehttp/guzzle/src/Middleware.php(72): GuzzleHttp\\Exception\\RequestException::create(Object(GuzzleHttp\\Psr7\\Request), Object(GuzzleHttp\\Psr7\\Response), NULL, Array, NULL)
#1 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(209): GuzzleHttp\\Middleware::GuzzleHttp\\{closure}(Object(GuzzleHttp\\Psr7\\Response))
#2 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(158): GuzzleHttp\\Promise\\Promise::callHandler(1, Object(GuzzleHttp\\Psr7\\Response), NULL)
#3 /home/jiminny/vendor/guzzlehttp/promises/src/TaskQueue.php(52): GuzzleHttp\\Promise\\Promise::GuzzleHttp\\Promise\\{closure}()
#4 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(251): GuzzleHttp\\Promise\\TaskQueue->run(true)
#5 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(227): GuzzleHttp\\Promise\\Promise->invokeWaitFn()
#6 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(272): GuzzleHttp\\Promise\\Promise->waitIfPending()
#7 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(229): GuzzleHttp\\Promise\\Promise->invokeWaitList()
#8 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(69): GuzzleHttp\\Promise\\Promise->waitIfPending()
#9 /home/jiminny/vendor/guzzlehttp/guzzle/src/Client.php(189): GuzzleHttp\\Promise\\Promise->wait()
#10 /home/jiminny/vendor/hubspot/hubspot-php/src/Http/Client.php(113): GuzzleHttp\\Client->request('POST', 'https://api.hub...', Array)
#11 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(166): SevenShores\\Hubspot\\Http\\Client->request('POST', 'https://api.hub...', Array)
#12 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#13 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#14 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#15 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#16 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#17 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#18 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#19 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#20 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#21 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#22 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#23 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#24 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#25 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#26 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#27 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#28 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#29 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#30 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#31 {main}
"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:13] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"076c3e6b-6a67-4774-8aa0-2a84fcf5e03c","trace_id":"284e571d-ab92-4e22-b09b-c151c2871cb4"}
[2026-05-07 13:22:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"076c3e6b-6a67-4774-8aa0-2a84fcf5e03c","trace_id":"284e571d-ab92-4e22-b09b-c151c2871cb4"}
[2026-05-07 13:22:19] local.NOTICE: Monitoring start {"correlation_id":"c41d4048-0465-4dcf-bb53-176287732e3e","trace_id":"9ce4a71c-a1a0-456e-843d-38fd15e5c798"}
[2026-05-07 13:22:19] local.NOTICE: Monitoring end {"correlation_id":"c41d4048-0465-4dcf-bb53-176287732e3e","trace_id":"9ce4a71c-a1a0-456e-843d-38fd15e5c798"}
[2026-05-07 13:22:30] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"934766d6-40c0-415c-bd51-d0b67a799c7c","trace_id":"d6c773e8-adf4-453b-8a17-077bf7bdf698"}
[2026-05-07 13:22:30] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"934766d6-40c0-415c-bd51-d0b67a799c7c","trace_id":"d6c773e8-adf4-453b-8a17-077bf7bdf698"}
[2026-05-07 13:22:35] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:41] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: Running conference:monitor:count command for activities in (2026-05-07 13:20:00, 2026-05-07 13:22:00] {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: [conference:monitor:count] No activities found in (2026-05-07 13:20:00, 2026-05-07 13:22:00] {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:create","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: [EmailSchedule] STARTING batch create {"host":"docker_lamp_1"} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: [EmailSchedule] FINISHED batch create {"host":"docker_lamp_1"} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:create","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:52] local.INFO: [Jiminny\Jobs\Mailbox\CreateBatches] processed 2 inboxes and created 0 batches {"userId":null,"batchSize":30,"maxBatches":1000} {"correlation_id":"13eed139-b218-43c9-b147-38ae92c45977","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:53] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:sync","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"cf9df816-4614-4a06-b853-4d6815fb85e1","trace_id":"ca6ed313-c21f-4683-8b5b-013a3ecd4081"}
[2026-05-07 13:22:53] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:sync","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"cf9df816-4614-4a06-b853-4d6815fb85e1","trace_id":"ca6ed313-c21f-4683-8b5b-013a3ecd4081"}
[2026-05-07 13:22:57] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"twilio:recover-tracks","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"93d3bd4f-fe02-4d22-aab9-00c74309e94c","trace_id":"356db0f7-0c25-4739-8c8b-a55ba28e1df0"}
[2026-05-07 13:22:57] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"twilio:recover-tracks","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"93d3bd4f-fe02-4d22-aab9-00c74309e94c","trace_id":"356db0f7-0c25-4739-8c8b-a55ba28e1df0"}
[2026-05-07 13:23:00] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:sync-users","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"connect-and-sell"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Start user synchronisation {"provider":"justcall","teams_count":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Synchronising team {"provider":"justcall","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.WARNING: [Salesforce] Account not connected for user {"userId":"cdf9285a-8ded-4a8b-bd7d-ec68c398f2f9","account":{"Jiminny\\Models\\SocialAccount":{"id":1367,"sociable_id":1071,"provider_user_id":"005O4000003s5c7IAA","expires":null,"refresh_token_expires":null,"provider":"salesforce","state":"full-refresh","auth_scope":"refresh_token web api","retry_after":null,"created_at":"2024-09-10 07:05:21","updated_at":"2026-01-14 07:00:58"}}} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] Integration owner is not connected, attempting team members {"crm_provider":"salesforce","crm_owner":1071,"team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] No team members found with active crm connection {"crm_provider":"salesforce","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] No team member found with active crm connection {"crm_provider":"salesforce","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.WARNING: Failed to sync external users {"message":"Your Salesforce account has become disconnected. Please login to Jiminny to reconnect.","provider":"justcall","team_id":1,"team":"jiminny"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"ringcentral"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"avaya"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"telus"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"salesloft"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"talkdesk"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"vonage"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Done {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:sync-users","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:24:05] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:05] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:05] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:07] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"a2d53fd0-ef62-42d7-bf03-2b78fe690081","trace_id":"ccc71cd2-62d3-4641-bbef-d3ac924250df"}
[2026-05-07 13:24:07] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"a2d53fd0-ef62-42d7-bf03-2b78fe690081","trace_id":"ccc71cd2-62d3-4641-bbef-d3ac924250df"}
[2026-05-07 13:24:09] local.NOTICE: Monitoring start {"correlation_id":"550636b7-858f-4d9a-a78c-1a4464ffe5d6","trace_id":"3a5f8440-816e-420f-a5a4-40ad67ca1542"}
[2026-05-07 13:24:09] local.NOTICE: Monitoring end {"correlation_id":"550636b7-858f-4d9a-a78c-1a4464ffe5d6","trace_id":"3a5f8440-816e-420f-a5a4-40ad67ca1542"}
[2026-05-07 13:24:10] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"97b9a580-2259-4931-82fd-86db94dccd2f","trace_id":"1809cb02-fcd4-4cf7-b426-2fe2cf347fb0"}
[2026-05-07 13:24:11] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"97b9a580-2259-4931-82fd-86db94dccd2f","trace_id":"1809cb02-fcd4-4cf7-b426-2fe2cf347fb0"}
[2026-05-07 13:24:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: Running conference:monitor:count command for activities in (2026-05-07 13:22:00, 2026-05-07 13:24:00] {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: [conference:monitor:count] No activities found in (2026-05-07 13:22:00, 2026-05-07 13:24:00] {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:aircall:check-and-renew","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [SocialAccountService] Fetching token {"socialAccountId":1496,"provider":"aircall"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [SocialAccountService] Token retrieved {"socialAccountId":1496,"provider":"aircall"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.ERROR: [Aircall] Re-activating webhooks failed {"team_id":1,"reason":"{\"message\":\"Forbidden\"}"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:aircall:check-and-renew","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:19] local.INFO: [RetryFailedDownloads] Starting {"options":{"from":null,"to":null,"help":false,"silent":false,"quiet":false,"verbose":false,"version":false,"ansi":null,"no-interaction":false,"env":null}} {"correlation_id":"df682399-d6b7-464b-9aea-85a4d7b10c27","trace_id":"532cf674-cebb-4b99-9190-d3020576b5db"}
[2026-05-07 13:25:06] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:06] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:06] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:08] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"846be41a-5d95-4144-ad3c-273defc37bea","trace_id":"8e158a4b-31e7-4161-af5e-d83f2ad2f3b5"}
[2026-05-07 13:25:08] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"846be41a-5d95-4144-ad3c-273defc37bea","trace_id":"8e158a4b-31e7-4161-af5e-d83f2ad2f3b5"}
[2026-05-07 13:25:11] local.NOTICE: Monitoring start {"correlation_id":"779be55d-57e0-4a33-8d13-cb3fda9c8ce5","trace_id":"4eaf7c2a-5a99-4c32-9fb9-b1377cacdebb"}
[2026-05-07 13:25:11] local.NOTICE: Monitoring end {"correlation_id":"779be55d-57e0-4a33-8d13-cb3fda9c8ce5","trace_id":"4eaf7c2a-5a99-4c32-9fb9-b1377cacdebb"}
[2026-05-07 13:25:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"75ba5939-1152-41ac-bed9-e3c203b981c3","trace_id":"f8537beb-7cb8-4f02-ab66-07754746b812"}
[2026-05-07 13:25:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"75ba5939-1152-41ac-bed9-e3c203b981c3","trace_id":"f8537beb-7cb8-4f02-ab66-07754746b812"}
[2026-05-07 13:25:19] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:21] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:purge-stale","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"3c03ff8f-9391-46b3-9001-5d3e3f364d29","trace_id":"5c5f2a08-7eb1-4eb3-9754-cde3f0425216"}
[2026-05-07 13:25:21] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:purge-stale","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"3c03ff8f-9391-46b3-9001-5d3e3f364d29","trace_id":"5c5f2a08-7eb1-4eb3-9754-cde3f0425216"}
[2026-05-07 13:25:23] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:text-relay:sync","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"640405cd-fddb-4ae4-ab6b-0da9052b22fa","trace_id":"0f39ab5c-c1aa-4aa1-a71c-b62823493c4e"}
[2026-05-07 13:25:23] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:text-relay:sync","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"640405cd-fddb-4ae4-ab6b-0da9052b22fa","trace_id":"0f39ab5c-c1aa-4aa1-a71c-b62823493c4e"}
[2026-05-07 13:25:26] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:pre-meeting-notification","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:26] local.INFO: Running pre-meeting notification command {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:26] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:pre-meeting-notification","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:29] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:start","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: Running conference:monitor:start command for activities in (2026-05-07 13:15:00, 2026-05-07 13:20:00] {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: [conference:monitor:start] No activities found in (2026-05-07 13:15:00, 2026-05-07 13:20:00] {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:start","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:37] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:end","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: conference:monitor:end:Jiminny\Console\Commands\Activities\MonitorMeetingEndCommand::logActivitiesEnded {"from":"13:20","to":"13:25"} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: conference:monitor:end:Jiminny\Console\Commands\Activities\MonitorMeetingEndCommand::logActivitiesWithUnfinishedSession {"from":"03:15","to":"03:20"} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:end","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:41] local.NOTICE: Repairing HubSpot tokens start {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: Trying to refresh HubSpot token {"account_id":59,"updated_at":"2025-10-03 09:32:05"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":59,"provider":"hubspot","refreshToken":"97b78f6e2cc49965c00c2492b602b02708b1392551e6b3f113fbaa48992af90b","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.ERROR: Failed to refresh HubSpot token {"account_id":59,"updated_at":"2025-10-03 09:32:05","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: Trying to refresh HubSpot token {"account_id":306,"updated_at":"2023-11-27 09:30:03"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":306,"provider":"hubspot","refreshToken":"6fa6aa8cc641d131231acc3470f5c03cb3b07b2e580fb18f8acb3b1dbb72549b","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.ERROR: Failed to refresh HubSpot token {"account_id":306,"updated_at":"2023-11-27 09:30:03","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: Trying to refresh HubSpot token {"account_id":1372,"updated_at":"2025-10-02 14:47:06"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":1372,"provider":"hubspot","refreshToken":"9aa73948c761da29dce46c177cf9aee1fde483a44169ca38723f9f0597d7a8c4","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.ERROR: Failed to refresh HubSpot token {"account_id":1372,"updated_at":"2025-10-02 14:47:06","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.NOTICE: Repairing HubSpot tokens end {"total":3,"fixed":0,"failed":3} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:pre-meeting-reminder","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"2775b4f9-6dce-40a2-84ad-fb7f3a2729ed","trace_id":"89eb011f-145e-44f2-a376-0c57cf42c11d"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"crm:bullhorn:ping","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"1b0300f0-a82f-4bf2-b5dc-24e9d04babab","trace_id":"af7b7ef6-7376-48fe-b7b9-a5ad41237fa4"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"crm:bullhorn:ping","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id...
|
PhpStorm
|
faVsco.js β ~/jiminny/app/vendor/hubspot/hubspot-p faVsco.js β ~/jiminny/app/vendor/hubspot/hubspot-php/src/Exceptions/HubspotException.php...
|
NULL
|
4347
|
|
4346
|
Project: faVsco.js, menu
master, menu
Start Listen Project: faVsco.js, menu
master, menu
Start Listening for PHP Debug Connections
AskJiminnyReportActivityServiceTest
Run 'AskJiminnyReportActivityServiceTest'
Debug 'AskJiminnyReportActivityServiceTest'
More Actions
JetBrains AI
Search Everywhere
IDE and Project Settings
Sync Changes
Hide This Notification
Code changed:
Hide
604
Previous Highlighted Error
Next Highlighted Error
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Fetching token {"socialAccountId":1499,"provider":"hubspot"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Token needs refreshing {"socialAccountId":1499,"provider":"hubspot"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":1499,"provider":"hubspot","refreshToken":"96f94c623a404e02ebdbf07f1b75707bb6cdbf848cbf45d418baf608c41a8d86","state":"connected"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountObserver] Saving model {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountObserver] Access token was modified, encrypting {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [SocialAccountService] Token refreshed {"socialAccountId":1499,"provider":"hubspot","state":"connected"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [CrmOwnerResolver] Integration owner matched as CRM Owner {"crm_provider":"hubspot","crm_owner":148,"team_id":2} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [Hubspot] Received 429 from API {"team_id":2,"config_id":2,"retry_after":10,"reason":"Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.ERROR: Hubspot returned 429 {"exception":"[object] (Jiminny\\Exceptions\\RateLimitException(code: 0): Hubspot returned 429 at /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php:206)
[stacktrace]
#0 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#1 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#2 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#3 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#4 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#5 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#6 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#7 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#8 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#9 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#10 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#11 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#12 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#13 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#14 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#15 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#16 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#17 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#18 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#19 {main}
[previous exception] [object] (SevenShores\\Hubspot\\Exceptions\\BadRequest(code: 429): Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
at /home/jiminny/vendor/hubspot/hubspot-php/src/Exceptions/HubspotException.php:24)
[stacktrace]
#0 /home/jiminny/vendor/hubspot/hubspot-php/src/Http/Client.php(125): SevenShores\\Hubspot\\Exceptions\\HubspotException::create(Object(GuzzleHttp\\Exception\\ClientException))
#1 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(166): SevenShores\\Hubspot\\Http\\Client->request('POST', 'https://api.hub...', Array)
#2 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#3 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#4 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#5 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#6 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#7 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#8 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#9 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#10 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#11 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#12 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#13 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#14 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#15 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#16 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#17 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#18 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#19 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#20 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#21 {main}
[previous exception] [object] (GuzzleHttp\\Exception\\ClientException(code: 429): Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
at /home/jiminny/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:111)
[stacktrace]
#0 /home/jiminny/vendor/guzzlehttp/guzzle/src/Middleware.php(72): GuzzleHttp\\Exception\\RequestException::create(Object(GuzzleHttp\\Psr7\\Request), Object(GuzzleHttp\\Psr7\\Response), NULL, Array, NULL)
#1 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(209): GuzzleHttp\\Middleware::GuzzleHttp\\{closure}(Object(GuzzleHttp\\Psr7\\Response))
#2 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(158): GuzzleHttp\\Promise\\Promise::callHandler(1, Object(GuzzleHttp\\Psr7\\Response), NULL)
#3 /home/jiminny/vendor/guzzlehttp/promises/src/TaskQueue.php(52): GuzzleHttp\\Promise\\Promise::GuzzleHttp\\Promise\\{closure}()
#4 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(251): GuzzleHttp\\Promise\\TaskQueue->run(true)
#5 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(227): GuzzleHttp\\Promise\\Promise->invokeWaitFn()
#6 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(272): GuzzleHttp\\Promise\\Promise->waitIfPending()
#7 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(229): GuzzleHttp\\Promise\\Promise->invokeWaitList()
#8 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(69): GuzzleHttp\\Promise\\Promise->waitIfPending()
#9 /home/jiminny/vendor/guzzlehttp/guzzle/src/Client.php(189): GuzzleHttp\\Promise\\Promise->wait()
#10 /home/jiminny/vendor/hubspot/hubspot-php/src/Http/Client.php(113): GuzzleHttp\\Client->request('POST', 'https://api.hub...', Array)
#11 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(166): SevenShores\\Hubspot\\Http\\Client->request('POST', 'https://api.hub...', Array)
#12 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#13 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#14 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#15 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#16 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#17 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#18 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#19 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#20 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#21 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#22 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#23 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#24 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#25 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#26 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#27 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#28 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#29 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#30 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#31 {main}
"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:13] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"076c3e6b-6a67-4774-8aa0-2a84fcf5e03c","trace_id":"284e571d-ab92-4e22-b09b-c151c2871cb4"}
[2026-05-07 13:22:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"076c3e6b-6a67-4774-8aa0-2a84fcf5e03c","trace_id":"284e571d-ab92-4e22-b09b-c151c2871cb4"}
[2026-05-07 13:22:19] local.NOTICE: Monitoring start {"correlation_id":"c41d4048-0465-4dcf-bb53-176287732e3e","trace_id":"9ce4a71c-a1a0-456e-843d-38fd15e5c798"}
[2026-05-07 13:22:19] local.NOTICE: Monitoring end {"correlation_id":"c41d4048-0465-4dcf-bb53-176287732e3e","trace_id":"9ce4a71c-a1a0-456e-843d-38fd15e5c798"}
[2026-05-07 13:22:30] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"934766d6-40c0-415c-bd51-d0b67a799c7c","trace_id":"d6c773e8-adf4-453b-8a17-077bf7bdf698"}
[2026-05-07 13:22:30] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"934766d6-40c0-415c-bd51-d0b67a799c7c","trace_id":"d6c773e8-adf4-453b-8a17-077bf7bdf698"}
[2026-05-07 13:22:35] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:41] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: Running conference:monitor:count command for activities in (2026-05-07 13:20:00, 2026-05-07 13:22:00] {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: [conference:monitor:count] No activities found in (2026-05-07 13:20:00, 2026-05-07 13:22:00] {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:create","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: [EmailSchedule] STARTING batch create {"host":"docker_lamp_1"} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: [EmailSchedule] FINISHED batch create {"host":"docker_lamp_1"} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:create","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:52] local.INFO: [Jiminny\Jobs\Mailbox\CreateBatches] processed 2 inboxes and created 0 batches {"userId":null,"batchSize":30,"maxBatches":1000} {"correlation_id":"13eed139-b218-43c9-b147-38ae92c45977","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:53] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:sync","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"cf9df816-4614-4a06-b853-4d6815fb85e1","trace_id":"ca6ed313-c21f-4683-8b5b-013a3ecd4081"}
[2026-05-07 13:22:53] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:sync","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"cf9df816-4614-4a06-b853-4d6815fb85e1","trace_id":"ca6ed313-c21f-4683-8b5b-013a3ecd4081"}
[2026-05-07 13:22:57] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"twilio:recover-tracks","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"93d3bd4f-fe02-4d22-aab9-00c74309e94c","trace_id":"356db0f7-0c25-4739-8c8b-a55ba28e1df0"}
[2026-05-07 13:22:57] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"twilio:recover-tracks","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"93d3bd4f-fe02-4d22-aab9-00c74309e94c","trace_id":"356db0f7-0c25-4739-8c8b-a55ba28e1df0"}
[2026-05-07 13:23:00] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:sync-users","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"connect-and-sell"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Start user synchronisation {"provider":"justcall","teams_count":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Synchronising team {"provider":"justcall","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.WARNING: [Salesforce] Account not connected for user {"userId":"cdf9285a-8ded-4a8b-bd7d-ec68c398f2f9","account":{"Jiminny\\Models\\SocialAccount":{"id":1367,"sociable_id":1071,"provider_user_id":"005O4000003s5c7IAA","expires":null,"refresh_token_expires":null,"provider":"salesforce","state":"full-refresh","auth_scope":"refresh_token web api","retry_after":null,"created_at":"2024-09-10 07:05:21","updated_at":"2026-01-14 07:00:58"}}} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] Integration owner is not connected, attempting team members {"crm_provider":"salesforce","crm_owner":1071,"team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] No team members found with active crm connection {"crm_provider":"salesforce","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] No team member found with active crm connection {"crm_provider":"salesforce","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.WARNING: Failed to sync external users {"message":"Your Salesforce account has become disconnected. Please login to Jiminny to reconnect.","provider":"justcall","team_id":1,"team":"jiminny"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"ringcentral"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"avaya"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"telus"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"salesloft"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"talkdesk"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"vonage"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Done {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:sync-users","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:24:05] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:05] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:05] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:07] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"a2d53fd0-ef62-42d7-bf03-2b78fe690081","trace_id":"ccc71cd2-62d3-4641-bbef-d3ac924250df"}
[2026-05-07 13:24:07] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"a2d53fd0-ef62-42d7-bf03-2b78fe690081","trace_id":"ccc71cd2-62d3-4641-bbef-d3ac924250df"}
[2026-05-07 13:24:09] local.NOTICE: Monitoring start {"correlation_id":"550636b7-858f-4d9a-a78c-1a4464ffe5d6","trace_id":"3a5f8440-816e-420f-a5a4-40ad67ca1542"}
[2026-05-07 13:24:09] local.NOTICE: Monitoring end {"correlation_id":"550636b7-858f-4d9a-a78c-1a4464ffe5d6","trace_id":"3a5f8440-816e-420f-a5a4-40ad67ca1542"}
[2026-05-07 13:24:10] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"97b9a580-2259-4931-82fd-86db94dccd2f","trace_id":"1809cb02-fcd4-4cf7-b426-2fe2cf347fb0"}
[2026-05-07 13:24:11] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"97b9a580-2259-4931-82fd-86db94dccd2f","trace_id":"1809cb02-fcd4-4cf7-b426-2fe2cf347fb0"}
[2026-05-07 13:24:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: Running conference:monitor:count command for activities in (2026-05-07 13:22:00, 2026-05-07 13:24:00] {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: [conference:monitor:count] No activities found in (2026-05-07 13:22:00, 2026-05-07 13:24:00] {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:aircall:check-and-renew","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [SocialAccountService] Fetching token {"socialAccountId":1496,"provider":"aircall"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [SocialAccountService] Token retrieved {"socialAccountId":1496,"provider":"aircall"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.ERROR: [Aircall] Re-activating webhooks failed {"team_id":1,"reason":"{\"message\":\"Forbidden\"}"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:aircall:check-and-renew","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:19] local.INFO: [RetryFailedDownloads] Starting {"options":{"from":null,"to":null,"help":false,"silent":false,"quiet":false,"verbose":false,"version":false,"ansi":null,"no-interaction":false,"env":null}} {"correlation_id":"df682399-d6b7-464b-9aea-85a4d7b10c27","trace_id":"532cf674-cebb-4b99-9190-d3020576b5db"}
[2026-05-07 13:25:06] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:06] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:06] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:08] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"846be41a-5d95-4144-ad3c-273defc37bea","trace_id":"8e158a4b-31e7-4161-af5e-d83f2ad2f3b5"}
[2026-05-07 13:25:08] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"846be41a-5d95-4144-ad3c-273defc37bea","trace_id":"8e158a4b-31e7-4161-af5e-d83f2ad2f3b5"}
[2026-05-07 13:25:11] local.NOTICE: Monitoring start {"correlation_id":"779be55d-57e0-4a33-8d13-cb3fda9c8ce5","trace_id":"4eaf7c2a-5a99-4c32-9fb9-b1377cacdebb"}
[2026-05-07 13:25:11] local.NOTICE: Monitoring end {"correlation_id":"779be55d-57e0-4a33-8d13-cb3fda9c8ce5","trace_id":"4eaf7c2a-5a99-4c32-9fb9-b1377cacdebb"}
[2026-05-07 13:25:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"75ba5939-1152-41ac-bed9-e3c203b981c3","trace_id":"f8537beb-7cb8-4f02-ab66-07754746b812"}
[2026-05-07 13:25:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"75ba5939-1152-41ac-bed9-e3c203b981c3","trace_id":"f8537beb-7cb8-4f02-ab66-07754746b812"}
[2026-05-07 13:25:19] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:21] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:purge-stale","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"3c03ff8f-9391-46b3-9001-5d3e3f364d29","trace_id":"5c5f2a08-7eb1-4eb3-9754-cde3f0425216"}
[2026-05-07 13:25:21] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:purge-stale","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"3c03ff8f-9391-46b3-9001-5d3e3f364d29","trace_id":"5c5f2a08-7eb1-4eb3-9754-cde3f0425216"}
[2026-05-07 13:25:23] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:text-relay:sync","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"640405cd-fddb-4ae4-ab6b-0da9052b22fa","trace_id":"0f39ab5c-c1aa-4aa1-a71c-b62823493c4e"}
[2026-05-07 13:25:23] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:text-relay:sync","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"640405cd-fddb-4ae4-ab6b-0da9052b22fa","trace_id":"0f39ab5c-c1aa-4aa1-a71c-b62823493c4e"}
[2026-05-07 13:25:26] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:pre-meeting-notification","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:26] local.INFO: Running pre-meeting notification command {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:26] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:pre-meeting-notification","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:29] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:start","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: Running conference:monitor:start command for activities in (2026-05-07 13:15:00, 2026-05-07 13:20:00] {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: [conference:monitor:start] No activities found in (2026-05-07 13:15:00, 2026-05-07 13:20:00] {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:start","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:37] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:end","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: conference:monitor:end:Jiminny\Console\Commands\Activities\MonitorMeetingEndCommand::logActivitiesEnded {"from":"13:20","to":"13:25"} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: conference:monitor:end:Jiminny\Console\Commands\Activities\MonitorMeetingEndCommand::logActivitiesWithUnfinishedSession {"from":"03:15","to":"03:20"} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:end","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:41] local.NOTICE: Repairing HubSpot tokens start {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: Trying to refresh HubSpot token {"account_id":59,"updated_at":"2025-10-03 09:32:05"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":59,"provider":"hubspot","refreshToken":"97b78f6e2cc49965c00c2492b602b02708b1392551e6b3f113fbaa48992af90b","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.ERROR: Failed to refresh HubSpot token {"account_id":59,"updated_at":"2025-10-03 09:32:05","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: Trying to refresh HubSpot token {"account_id":306,"updated_at":"2023-11-27 09:30:03"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":306,"provider":"hubspot","refreshToken":"6fa6aa8cc641d131231acc3470f5c03cb3b07b2e580fb18f8acb3b1dbb72549b","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.ERROR: Failed to refresh HubSpot token {"account_id":306,"updated_at":"2023-11-27 09:30:03","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: Trying to refresh HubSpot token {"account_id":1372,"updated_at":"2025-10-02 14:47:06"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":1372,"provider":"hubspot","refreshToken":"9aa73948c761da29dce46c177cf9aee1fde483a44169ca38723f9f0597d7a8c4","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.ERROR: Failed to refresh HubSpot token {"account_id":1372,"updated_at":"2025-10-02 14:47:06","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.NOTICE: Repairing HubSpot tokens end {"total":3,"fixed":0,"failed":3} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:pre-meeting-reminder","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"2775b4f9-6dce-40a2-84ad-fb7f3a2729ed","trace_id":"89eb011f-145e-44f2-a376-0c57cf42c11d"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"crm:bullhorn:ping","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"1b0300f0-a82f-4bf2-b5dc-24e9d04babab","trace_id":"af7b7ef6-7376-48fe-b7b9-a5ad41237fa4"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"crm:bullhorn:ping","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id...
|
PhpStorm
|
faVsco.js β ~/jiminny/app/vendor/hubspot/hubspot-p faVsco.js β ~/jiminny/app/vendor/hubspot/hubspot-php/src/Exceptions/HubspotException.php...
|
NULL
|
4346
|
|
4345
|
Project: faVsco.js, menu
iTerm2ShellEditViewSessio Project: faVsco.js, menu
iTerm2ShellEditViewSessionScriptsProfilesWindowHelp$0.β’ Lukas/Stefka 121 - in 1h 2 m100% <478Thu 7 May 16:28:34DEV (docker)APP (-zsh)*3T81DOCKERO β΄1DEV (docker)182worker-crm-sync:worker-crm-sync_00: startedworker-crm-update:worker-crm-update_00: startedworker-download:worker-download_00: startedworker-emails:worker-emails_00: startedworker-es-update:worker-es-update_00: startedworker-nudges:worker-nudges_00: startedroot@docker_lamp_1:/home/jiminny# php artisan jiminny:debugMatching contact 0Matching contact 1Matching contact 2Matching contactMatchingcontact4Matchingcontact5Matchingcontact 6Matching contact 7Matching contact 8Matching contact 9root@docker_lamp_1:/home/jiminny# php artisan jiminny:debugMatching contact 0-zshβ’ 84|screenpipe*3 365-zshβ΄6Jiminny \Exceptions \RateLimitExceptionHubspot returned 429at app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php:206202'retry_after' =SretryAfter,203"reason"204= Se->getMessage(),205β 206throw new RateLimitException('Hubspot returned 429', SretryAfter, $e);207208} else 1throw $e;209}210+14 vendor frames15DEVapp/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php:166SevenShores\Hubspot\Http\Client:: request("POST", "[URL_WITH_CREDENTIALS] ]...
|
PhpStorm
|
faVsco.js β ~/jiminny/app/vendor/hubspot/hubspot-p faVsco.js β ~/jiminny/app/vendor/hubspot/hubspot-php/src/Exceptions/BadRequest.php...
|
NULL
|
4345
|
|
4344
|
PhostormINavigarecodeFV faVsco.jsProiect vT Delete PhostormINavigarecodeFV faVsco.jsProiect vT DeleteCrmEntityTrait.php(4 RateLimitExcention.oholΒ© PaginationState.phpΒ© PaginationConfig.phpJiminnyDeougcommano.phpβ’D takeronoβ’ telixtbeckerΒ© SyncOpportunity.php>DltidryOpportunitysyncIrait.ongβ’Dtiloc) HubspotweblΒ© WebhookSyncBatchProcessor.phctirebaseβ’ β flioboxdiaitallImportBatchJobTrait.php(c) Hubspot/Service.phpC) Companies.phgC) MatchActivityCrmData.phpΒ© CrmActivityService.phptriendsornho(C) CachedCrmServiceDecorator.phpTHubspot/..SyncCrmEntitiesTrait.phoΒ©) Pipedrive/Service.phpServicelntertace.php> truitcake> D giggsey>D googleβΊ D graham-campbel>D grpcβΊ D guzzlehttp> D halaxa) Mhameroct@ OpportunitvSvncTest.oho@ RateLimit.ohnC) ProviderRateLimiter.oho<nhnKeader Modenamesnace SevenShones Huhsnot Excentions:class BadRequest extends HubspotExceptionChoose Implementation of HubspotException|SevenShores|Hubspot\Exceptions (2 found)> C hashidsβ’ Mhtmi2toy(7 BadRequestSevenShores Hubspot Excentionsv C hubspotv C api-client>Ca.aithub>C codeger>Mlib> D testsβ’ aitianoreE.php_csM+ CHANGELOG.mdHubsparExceptionSevenShores Hubspot Excentionscomooser.isoncomooser.lockE LICENSErunhosnec.vmMIREADME.mdMhubsnot-oholv D src> D Endpointsv M Sycentiong(4 RadPequect nhnΒ© HubspotException.fΒ© InvalidArgument.phβΊ DJ Http> C UtilsΒ© Delay.phpΒ© Factory.phpphp helpers.php@ DotwMiddloworoContoΒ© Utils.php> O testsE env templateβ’.aitianorephp.pho-cs-fixer.dist.phpA.travis.vmlMA CHANGELOG.moSonarAube for ldls suadestiionsa Detect more seamitvlissueslin vour D.D flles /ltn SonarAube Claud for free //lDownload SonarOnbe Server lllearn more //lDonit ask again /(todav 10:251Lukas/Stefka 121 - in 1h 2 mAskJiminnyReportActivityServiceTest v100% 12Thu 7 May 16:28:34+0 ..=custom.log=laravel.log XA SF (jiminny@localhost]4 HS_local jiminny@localhostiti accounts (jiminny@localhost]A console [PKOU.# console [eu)* console [STAGINGI[2026-05-07 13:22:12] local.INF0:[2026-05-07 13:22:12] local.INF0:[SocialAccountService] Fetching token f"socialAccountId":1499, ",*W604 A V[SocialAccountServicel Token needs refreshing {"socialAccountId":1499. "provider'12020-05-01 15.2L.12 Local. LNFU.lencryoredlokennanacer beneracino access coken."mode"."Lecacy"r ""correlacl12026-05-07 15:22:12 Local.INFU?from provider {"socialAccountId":1499,*P112026-05-07 15:22:12 Local.INFO:Soc1aLAccountUbserver Savina model "correlation_ 1d":"345t341d-028t-4C8C-9578[2026-05-07 13:22:12] local.INF0:[SocialAccountObserver] Access token was modified, encrypting {"correlation_id"2026-05-07 15:22:15 Local.INFO:Soc1aLAccountServicel Token refreshed "soc1alAccountid":1499."providen":"hubse[2026-05-07 13:22:131 local, INF0:12026-05-07 15:22115 LOCOL INFOHubsoot Recerved 429 From APl <"team 1d":2."contlo 1d":2."retry aften":10."re{\"status\": \"error\", \"message\":\"You have reached your secondly limit.\", \"errorType\": \"RATE_LIMIT\", \"correla"- "correlation id":"343F341d-028f-4c8c-9578-252FcdebeΔΒ«c" "trace 1d":"41071c00-9712-46eb-8acf-d5c4298fea69"[2026-05-07 13:22:13] local.ERROR: Hubspot returned 429 {"exception":"[object] (Jiminny|\Exceptions\\RateLimitExcestacktrace]l#0 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny|\Services\\Crm\\Hut#1 /home/jiminny/app/Services/Crm/Hubspot/CLient.php(176): Jiminny\(Services\\Crm\\Hubspot\\Pagination\HubspotPag#2 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny(Services\\Crm\\Hubspot\\Client->getPaginatec#3/home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matc#4/home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommane#5/home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Command:#6 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminatel\Container\\BoundMethc#7/home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Uti#8/home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\Bor#9 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminatel\Container\\Bour#10/home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\Container\Contain#11/home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\Consolel\Command->execute(Obiect(Sy#12/home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\Component Consolel\C#13/home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\Console\Command->run(Obiect(Symfony))#14/home/jiminny/vendor/symfony/console/Application.php(356): Symfony|\Component\Console\Application->doRunComi#15 /home/71m1nny/vendor/symtony/console/Application.pnp (195: symtony Component Console AppLication->doRun(UbTFo home/aaminnyvendor/anaveu namework scca Luminare roundation console/ Kernel ohous: SymtonyComponent#17/home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.pho(1235): Illuminatel\Foundatio#18 /home/Timinny/artisan(13): TlluminateFoundationAopuication->handl eCommandObiect SumfonyComponent Cons.#19 {main?Lprevious exception lobject) (SevenShores)\Hubspot)\Exceptions\BadRequest(code: 429): Client error: POST https"status "* "error". "message":"You have reached vour secondly limit. ". "errorivoe": "RATE LIMIT"."correlat /home/jiminny/vendor/hubspot/hubspot-php/src/Exceptions/HubspotExcention.oho:24)listacktnace#0 /home/jiminny/vendor/hubspot/hubspot-php/src/Http/Client.php(125): SevenShores\\Hubspot\\Exceptions\\HubspotExc#1 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(166): SevenShores\\Hubspot\\Http#2 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\|Services\\Crm\\Hut#3/home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\(Services\\Crm\\Hubspot\\Pagination\\HubspotPac#4 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny|\Services|\Crm\\Hubspot|\Client->getPaginatec#5/home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matc#6 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console|\Commands|\JiminnyDebugCommane#7/home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\Console\Commands#8 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminatel|Container|\BoundMethe#9/home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): IlluminateContainer\Uti#10/home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\Container\Bc#11/home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\Container\BorCascadeHubspot Rate LimitingHubSpot Rate Limit HHow to Access the Header in Your codeIf you need to check the header manually for debugging:β’ php// For new SDK (ApiException)trySresponse = Sclient->request...:} catch (\HubSpot\Client\Crm\Objects\ApiException $e) {nseHeaders() ?: 0SretryAfter = $headers ('Retry-After'][0] ?? $headers['retry-after'] [0] ?? null;f(SretrvAfter)// HubSpot sent retry guidance} else{/ No header - use detault based on error messageSbody = ison decode(Se-saetResponseBodvd. true).SretryAfter = match($body['policyName'] ?? null) {detault = 10,RecommendationThe current imolementation at Service.oho: 1721-1727 already handles this correctly by checking policyname:β’ ph:sresponse =son decodelse->geckesponsebody, truen&& Sresponsel'policyName'] == self::TEN SECONDLY ROLLING POLICY?self::TEN SECONDLY ROLLING LIMITII/ 10 seconds|: 1; // Default 1 second for other limitsTo see if headers are actually present, add temporary logging:β’ oho.Sheaders = se->oetResponseHeaderso?::Log: : debug('[HubSpot) Rate limit response headers', [headers = Sheaders'retry_after' => $headers ['Retry-After'] ?? $headers['retry-after'] ?? 'NOT_PRESENT',1):r.al .Ask anvthina (&4DβΉ> CodeCΒ° AdantiveW Windsurf Teams5.24UTF.8io 4 spaces...
|
PhpStorm
|
|
NULL
|
4344
|
|
4343
|
Project: faVsco.js, menu
master, menu
Start Listen Project: faVsco.js, menu
master, menu
Start Listening for PHP Debug Connections
AskJiminnyReportActivityServiceTest
Run 'AskJiminnyReportActivityServiceTest'
Debug 'AskJiminnyReportActivityServiceTest'
More Actions
JetBrains AI
Search Everywhere
IDE and Project Settings
Sync Changes
Hide This Notification
Code changed:
Hide
604
Previous Highlighted Error
Next Highlighted Error
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Fetching token {"socialAccountId":1499,"provider":"hubspot"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Token needs refreshing {"socialAccountId":1499,"provider":"hubspot"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":1499,"provider":"hubspot","refreshToken":"96f94c623a404e02ebdbf07f1b75707bb6cdbf848cbf45d418baf608c41a8d86","state":"connected"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountObserver] Saving model {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountObserver] Access token was modified, encrypting {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [SocialAccountService] Token refreshed {"socialAccountId":1499,"provider":"hubspot","state":"connected"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [CrmOwnerResolver] Integration owner matched as CRM Owner {"crm_provider":"hubspot","crm_owner":148,"team_id":2} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [Hubspot] Received 429 from API {"team_id":2,"config_id":2,"retry_after":10,"reason":"Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.ERROR: Hubspot returned 429 {"exception":"[object] (Jiminny\\Exceptions\\RateLimitException(code: 0): Hubspot returned 429 at /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php:206)
[stacktrace]
#0 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#1 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#2 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#3 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#4 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#5 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#6 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#7 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#8 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#9 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#10 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#11 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#12 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#13 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#14 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#15 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#16 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#17 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#18 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#19 {main}
[previous exception] [object] (SevenShores\\Hubspot\\Exceptions\\BadRequest(code: 429): Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
at /home/jiminny/vendor/hubspot/hubspot-php/src/Exceptions/HubspotException.php:24)
[stacktrace]
#0 /home/jiminny/vendor/hubspot/hubspot-php/src/Http/Client.php(125): SevenShores\\Hubspot\\Exceptions\\HubspotException::create(Object(GuzzleHttp\\Exception\\ClientException))
#1 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(166): SevenShores\\Hubspot\\Http\\Client->request('POST', 'https://api.hub...', Array)
#2 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#3 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#4 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#5 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#6 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#7 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#8 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#9 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#10 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#11 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#12 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#13 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#14 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#15 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#16 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#17 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#18 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#19 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#20 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#21 {main}
[previous exception] [object] (GuzzleHttp\\Exception\\ClientException(code: 429): Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
at /home/jiminny/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:111)
[stacktrace]
#0 /home/jiminny/vendor/guzzlehttp/guzzle/src/Middleware.php(72): GuzzleHttp\\Exception\\RequestException::create(Object(GuzzleHttp\\Psr7\\Request), Object(GuzzleHttp\\Psr7\\Response), NULL, Array, NULL)
#1 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(209): GuzzleHttp\\Middleware::GuzzleHttp\\{closure}(Object(GuzzleHttp\\Psr7\\Response))
#2 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(158): GuzzleHttp\\Promise\\Promise::callHandler(1, Object(GuzzleHttp\\Psr7\\Response), NULL)
#3 /home/jiminny/vendor/guzzlehttp/promises/src/TaskQueue.php(52): GuzzleHttp\\Promise\\Promise::GuzzleHttp\\Promise\\{closure}()
#4 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(251): GuzzleHttp\\Promise\\TaskQueue->run(true)
#5 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(227): GuzzleHttp\\Promise\\Promise->invokeWaitFn()
#6 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(272): GuzzleHttp\\Promise\\Promise->waitIfPending()
#7 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(229): GuzzleHttp\\Promise\\Promise->invokeWaitList()
#8 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(69): GuzzleHttp\\Promise\\Promise->waitIfPending()
#9 /home/jiminny/vendor/guzzlehttp/guzzle/src/Client.php(189): GuzzleHttp\\Promise\\Promise->wait()
#10 /home/jiminny/vendor/hubspot/hubspot-php/src/Http/Client.php(113): GuzzleHttp\\Client->request('POST', 'https://api.hub...', Array)
#11 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(166): SevenShores\\Hubspot\\Http\\Client->request('POST', 'https://api.hub...', Array)
#12 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#13 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#14 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#15 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#16 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#17 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#18 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#19 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#20 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#21 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#22 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#23 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#24 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#25 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#26 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#27 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#28 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#29 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#30 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#31 {main}
"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:13] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"076c3e6b-6a67-4774-8aa0-2a84fcf5e03c","trace_id":"284e571d-ab92-4e22-b09b-c151c2871cb4"}
[2026-05-07 13:22:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"076c3e6b-6a67-4774-8aa0-2a84fcf5e03c","trace_id":"284e571d-ab92-4e22-b09b-c151c2871cb4"}
[2026-05-07 13:22:19] local.NOTICE: Monitoring start {"correlation_id":"c41d4048-0465-4dcf-bb53-176287732e3e","trace_id":"9ce4a71c-a1a0-456e-843d-38fd15e5c798"}
[2026-05-07 13:22:19] local.NOTICE: Monitoring end {"correlation_id":"c41d4048-0465-4dcf-bb53-176287732e3e","trace_id":"9ce4a71c-a1a0-456e-843d-38fd15e5c798"}
[2026-05-07 13:22:30] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"934766d6-40c0-415c-bd51-d0b67a799c7c","trace_id":"d6c773e8-adf4-453b-8a17-077bf7bdf698"}
[2026-05-07 13:22:30] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"934766d6-40c0-415c-bd51-d0b67a799c7c","trace_id":"d6c773e8-adf4-453b-8a17-077bf7bdf698"}
[2026-05-07 13:22:35] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:41] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: Running conference:monitor:count command for activities in (2026-05-07 13:20:00, 2026-05-07 13:22:00] {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: [conference:monitor:count] No activities found in (2026-05-07 13:20:00, 2026-05-07 13:22:00] {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:create","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: [EmailSchedule] STARTING batch create {"host":"docker_lamp_1"} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: [EmailSchedule] FINISHED batch create {"host":"docker_lamp_1"} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:create","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:52] local.INFO: [Jiminny\Jobs\Mailbox\CreateBatches] processed 2 inboxes and created 0 batches {"userId":null,"batchSize":30,"maxBatches":1000} {"correlation_id":"13eed139-b218-43c9-b147-38ae92c45977","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:53] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:sync","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"cf9df816-4614-4a06-b853-4d6815fb85e1","trace_id":"ca6ed313-c21f-4683-8b5b-013a3ecd4081"}
[2026-05-07 13:22:53] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:sync","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"cf9df816-4614-4a06-b853-4d6815fb85e1","trace_id":"ca6ed313-c21f-4683-8b5b-013a3ecd4081"}
[2026-05-07 13:22:57] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"twilio:recover-tracks","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"93d3bd4f-fe02-4d22-aab9-00c74309e94c","trace_id":"356db0f7-0c25-4739-8c8b-a55ba28e1df0"}
[2026-05-07 13:22:57] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"twilio:recover-tracks","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"93d3bd4f-fe02-4d22-aab9-00c74309e94c","trace_id":"356db0f7-0c25-4739-8c8b-a55ba28e1df0"}
[2026-05-07 13:23:00] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:sync-users","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"connect-and-sell"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Start user synchronisation {"provider":"justcall","teams_count":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Synchronising team {"provider":"justcall","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.WARNING: [Salesforce] Account not connected for user {"userId":"cdf9285a-8ded-4a8b-bd7d-ec68c398f2f9","account":{"Jiminny\\Models\\SocialAccount":{"id":1367,"sociable_id":1071,"provider_user_id":"005O4000003s5c7IAA","expires":null,"refresh_token_expires":null,"provider":"salesforce","state":"full-refresh","auth_scope":"refresh_token web api","retry_after":null,"created_at":"2024-09-10 07:05:21","updated_at":"2026-01-14 07:00:58"}}} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] Integration owner is not connected, attempting team members {"crm_provider":"salesforce","crm_owner":1071,"team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] No team members found with active crm connection {"crm_provider":"salesforce","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] No team member found with active crm connection {"crm_provider":"salesforce","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.WARNING: Failed to sync external users {"message":"Your Salesforce account has become disconnected. Please login to Jiminny to reconnect.","provider":"justcall","team_id":1,"team":"jiminny"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"ringcentral"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"avaya"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"telus"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"salesloft"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"talkdesk"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"vonage"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Done {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:sync-users","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:24:05] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:05] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:05] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:07] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"a2d53fd0-ef62-42d7-bf03-2b78fe690081","trace_id":"ccc71cd2-62d3-4641-bbef-d3ac924250df"}
[2026-05-07 13:24:07] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"a2d53fd0-ef62-42d7-bf03-2b78fe690081","trace_id":"ccc71cd2-62d3-4641-bbef-d3ac924250df"}
[2026-05-07 13:24:09] local.NOTICE: Monitoring start {"correlation_id":"550636b7-858f-4d9a-a78c-1a4464ffe5d6","trace_id":"3a5f8440-816e-420f-a5a4-40ad67ca1542"}
[2026-05-07 13:24:09] local.NOTICE: Monitoring end {"correlation_id":"550636b7-858f-4d9a-a78c-1a4464ffe5d6","trace_id":"3a5f8440-816e-420f-a5a4-40ad67ca1542"}
[2026-05-07 13:24:10] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"97b9a580-2259-4931-82fd-86db94dccd2f","trace_id":"1809cb02-fcd4-4cf7-b426-2fe2cf347fb0"}
[2026-05-07 13:24:11] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"97b9a580-2259-4931-82fd-86db94dccd2f","trace_id":"1809cb02-fcd4-4cf7-b426-2fe2cf347fb0"}
[2026-05-07 13:24:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: Running conference:monitor:count command for activities in (2026-05-07 13:22:00, 2026-05-07 13:24:00] {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: [conference:monitor:count] No activities found in (2026-05-07 13:22:00, 2026-05-07 13:24:00] {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:aircall:check-and-renew","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [SocialAccountService] Fetching token {"socialAccountId":1496,"provider":"aircall"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [SocialAccountService] Token retrieved {"socialAccountId":1496,"provider":"aircall"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.ERROR: [Aircall] Re-activating webhooks failed {"team_id":1,"reason":"{\"message\":\"Forbidden\"}"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:aircall:check-and-renew","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:19] local.INFO: [RetryFailedDownloads] Starting {"options":{"from":null,"to":null,"help":false,"silent":false,"quiet":false,"verbose":false,"version":false,"ansi":null,"no-interaction":false,"env":null}} {"correlation_id":"df682399-d6b7-464b-9aea-85a4d7b10c27","trace_id":"532cf674-cebb-4b99-9190-d3020576b5db"}
[2026-05-07 13:25:06] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:06] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:06] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:08] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"846be41a-5d95-4144-ad3c-273defc37bea","trace_id":"8e158a4b-31e7-4161-af5e-d83f2ad2f3b5"}
[2026-05-07 13:25:08] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"846be41a-5d95-4144-ad3c-273defc37bea","trace_id":"8e158a4b-31e7-4161-af5e-d83f2ad2f3b5"}
[2026-05-07 13:25:11] local.NOTICE: Monitoring start {"correlation_id":"779be55d-57e0-4a33-8d13-cb3fda9c8ce5","trace_id":"4eaf7c2a-5a99-4c32-9fb9-b1377cacdebb"}
[2026-05-07 13:25:11] local.NOTICE: Monitoring end {"correlation_id":"779be55d-57e0-4a33-8d13-cb3fda9c8ce5","trace_id":"4eaf7c2a-5a99-4c32-9fb9-b1377cacdebb"}
[2026-05-07 13:25:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"75ba5939-1152-41ac-bed9-e3c203b981c3","trace_id":"f8537beb-7cb8-4f02-ab66-07754746b812"}
[2026-05-07 13:25:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"75ba5939-1152-41ac-bed9-e3c203b981c3","trace_id":"f8537beb-7cb8-4f02-ab66-07754746b812"}
[2026-05-07 13:25:19] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:21] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:purge-stale","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"3c03ff8f-9391-46b3-9001-5d3e3f364d29","trace_id":"5c5f2a08-7eb1-4eb3-9754-cde3f0425216"}
[2026-05-07 13:25:21] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:purge-stale","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"3c03ff8f-9391-46b3-9001-5d3e3f364d29","trace_id":"5c5f2a08-7eb1-4eb3-9754-cde3f0425216"}
[2026-05-07 13:25:23] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:text-relay:sync","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"640405cd-fddb-4ae4-ab6b-0da9052b22fa","trace_id":"0f39ab5c-c1aa-4aa1-a71c-b62823493c4e"}
[2026-05-07 13:25:23] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:text-relay:sync","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"640405cd-fddb-4ae4-ab6b-0da9052b22fa","trace_id":"0f39ab5c-c1aa-4aa1-a71c-b62823493c4e"}
[2026-05-07 13:25:26] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:pre-meeting-notification","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:26] local.INFO: Running pre-meeting notification command {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:26] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:pre-meeting-notification","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:29] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:start","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: Running conference:monitor:start command for activities in (2026-05-07 13:15:00, 2026-05-07 13:20:00] {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: [conference:monitor:start] No activities found in (2026-05-07 13:15:00, 2026-05-07 13:20:00] {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:start","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:37] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:end","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: conference:monitor:end:Jiminny\Console\Commands\Activities\MonitorMeetingEndCommand::logActivitiesEnded {"from":"13:20","to":"13:25"} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: conference:monitor:end:Jiminny\Console\Commands\Activities\MonitorMeetingEndCommand::logActivitiesWithUnfinishedSession {"from":"03:15","to":"03:20"} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:end","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:41] local.NOTICE: Repairing HubSpot tokens start {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: Trying to refresh HubSpot token {"account_id":59,"updated_at":"2025-10-03 09:32:05"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":59,"provider":"hubspot","refreshToken":"97b78f6e2cc49965c00c2492b602b02708b1392551e6b3f113fbaa48992af90b","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.ERROR: Failed to refresh HubSpot token {"account_id":59,"updated_at":"2025-10-03 09:32:05","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: Trying to refresh HubSpot token {"account_id":306,"updated_at":"2023-11-27 09:30:03"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":306,"provider":"hubspot","refreshToken":"6fa6aa8cc641d131231acc3470f5c03cb3b07b2e580fb18f8acb3b1dbb72549b","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.ERROR: Failed to refresh HubSpot token {"account_id":306,"updated_at":"2023-11-27 09:30:03","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: Trying to refresh HubSpot token {"account_id":1372,"updated_at":"2025-10-02 14:47:06"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":1372,"provider":"hubspot","refreshToken":"9aa73948c761da29dce46c177cf9aee1fde483a44169ca38723f9f0597d7a8c4","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.ERROR: Failed to refresh HubSpot token {"account_id":1372,"updated_at":"2025-10-02 14:47:06","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.NOTICE: Repairing HubSpot tokens end {"total":3,"fixed":0,"failed":3} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:pre-meeting-reminder","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"2775b4f9-6dce-40a2-84ad-fb7f3a2729ed","trace_id":"89eb011f-145e-44f2-a376-0c57cf42c11d"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"crm:bullhorn:ping","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"1b0300f0-a82f-4bf2-b5dc-24e9d04babab","trace_id":"af7b7ef6-7376-48fe-b7b9-a5ad41237fa4"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"crm:bullhorn:ping","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id...
|
PhpStorm
|
faVsco.js β ~/jiminny/app/vendor/hubspot/api-clien faVsco.js β ~/jiminny/app/vendor/hubspot/api-client/codegen/Crm/Deals/Api/BasicApi.php...
|
NULL
|
4343
|
|
4342
|
Project: faVsco.js, menu
master, menu
Start Listen Project: faVsco.js, menu
master, menu
Start Listening for PHP Debug Connections
AskJiminnyReportActivityServiceTest
Run 'AskJiminnyReportActivityServiceTest'
Debug 'AskJiminnyReportActivityServiceTest'
More Actions
JetBrains AI
Search Everywhere
IDE and Project Settings
Sync Changes
Hide This Notification
Code changed:
Hide
604
Previous Highlighted Error
Next Highlighted Error
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Fetching token {"socialAccountId":1499,"provider":"hubspot"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Token needs refreshing {"socialAccountId":1499,"provider":"hubspot"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":1499,"provider":"hubspot","refreshToken":"96f94c623a404e02ebdbf07f1b75707bb6cdbf848cbf45d418baf608c41a8d86","state":"connected"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountObserver] Saving model {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountObserver] Access token was modified, encrypting {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [SocialAccountService] Token refreshed {"socialAccountId":1499,"provider":"hubspot","state":"connected"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [CrmOwnerResolver] Integration owner matched as CRM Owner {"crm_provider":"hubspot","crm_owner":148,"team_id":2} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [Hubspot] Received 429 from API {"team_id":2,"config_id":2,"retry_after":10,"reason":"Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.ERROR: Hubspot returned 429 {"exception":"[object] (Jiminny\\Exceptions\\RateLimitException(code: 0): Hubspot returned 429 at /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php:206)
[stacktrace]
#0 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#1 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#2 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#3 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#4 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#5 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#6 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#7 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#8 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#9 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#10 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#11 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#12 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#13 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#14 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#15 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#16 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#17 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#18 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#19 {main}
[previous exception] [object] (SevenShores\\Hubspot\\Exceptions\\BadRequest(code: 429): Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
at /home/jiminny/vendor/hubspot/hubspot-php/src/Exceptions/HubspotException.php:24)
[stacktrace]
#0 /home/jiminny/vendor/hubspot/hubspot-php/src/Http/Client.php(125): SevenShores\\Hubspot\\Exceptions\\HubspotException::create(Object(GuzzleHttp\\Exception\\ClientException))
#1 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(166): SevenShores\\Hubspot\\Http\\Client->request('POST', 'https://api.hub...', Array)
#2 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#3 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#4 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#5 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#6 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#7 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#8 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#9 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#10 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#11 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#12 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#13 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#14 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#15 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#16 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#17 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#18 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#19 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#20 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#21 {main}
[previous exception] [object] (GuzzleHttp\\Exception\\ClientException(code: 429): Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
at /home/jiminny/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:111)
[stacktrace]
#0 /home/jiminny/vendor/guzzlehttp/guzzle/src/Middleware.php(72): GuzzleHttp\\Exception\\RequestException::create(Object(GuzzleHttp\\Psr7\\Request), Object(GuzzleHttp\\Psr7\\Response), NULL, Array, NULL)
#1 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(209): GuzzleHttp\\Middleware::GuzzleHttp\\{closure}(Object(GuzzleHttp\\Psr7\\Response))
#2 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(158): GuzzleHttp\\Promise\\Promise::callHandler(1, Object(GuzzleHttp\\Psr7\\Response), NULL)
#3 /home/jiminny/vendor/guzzlehttp/promises/src/TaskQueue.php(52): GuzzleHttp\\Promise\\Promise::GuzzleHttp\\Promise\\{closure}()
#4 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(251): GuzzleHttp\\Promise\\TaskQueue->run(true)
#5 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(227): GuzzleHttp\\Promise\\Promise->invokeWaitFn()
#6 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(272): GuzzleHttp\\Promise\\Promise->waitIfPending()
#7 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(229): GuzzleHttp\\Promise\\Promise->invokeWaitList()
#8 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(69): GuzzleHttp\\Promise\\Promise->waitIfPending()
#9 /home/jiminny/vendor/guzzlehttp/guzzle/src/Client.php(189): GuzzleHttp\\Promise\\Promise->wait()
#10 /home/jiminny/vendor/hubspot/hubspot-php/src/Http/Client.php(113): GuzzleHttp\\Client->request('POST', 'https://api.hub...', Array)
#11 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(166): SevenShores\\Hubspot\\Http\\Client->request('POST', 'https://api.hub...', Array)
#12 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#13 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#14 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#15 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#16 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#17 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#18 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#19 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#20 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#21 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#22 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#23 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#24 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#25 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#26 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#27 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#28 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#29 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#30 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#31 {main}
"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:13] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"076c3e6b-6a67-4774-8aa0-2a84fcf5e03c","trace_id":"284e571d-ab92-4e22-b09b-c151c2871cb4"}
[2026-05-07 13:22:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"076c3e6b-6a67-4774-8aa0-2a84fcf5e03c","trace_id":"284e571d-ab92-4e22-b09b-c151c2871cb4"}
[2026-05-07 13:22:19] local.NOTICE: Monitoring start {"correlation_id":"c41d4048-0465-4dcf-bb53-176287732e3e","trace_id":"9ce4a71c-a1a0-456e-843d-38fd15e5c798"}
[2026-05-07 13:22:19] local.NOTICE: Monitoring end {"correlation_id":"c41d4048-0465-4dcf-bb53-176287732e3e","trace_id":"9ce4a71c-a1a0-456e-843d-38fd15e5c798"}
[2026-05-07 13:22:30] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"934766d6-40c0-415c-bd51-d0b67a799c7c","trace_id":"d6c773e8-adf4-453b-8a17-077bf7bdf698"}
[2026-05-07 13:22:30] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"934766d6-40c0-415c-bd51-d0b67a799c7c","trace_id":"d6c773e8-adf4-453b-8a17-077bf7bdf698"}
[2026-05-07 13:22:35] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:41] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: Running conference:monitor:count command for activities in (2026-05-07 13:20:00, 2026-05-07 13:22:00] {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: [conference:monitor:count] No activities found in (2026-05-07 13:20:00, 2026-05-07 13:22:00] {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:create","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: [EmailSchedule] STARTING batch create {"host":"docker_lamp_1"} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: [EmailSchedule] FINISHED batch create {"host":"docker_lamp_1"} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:create","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:52] local.INFO: [Jiminny\Jobs\Mailbox\CreateBatches] processed 2 inboxes and created 0 batches {"userId":null,"batchSize":30,"maxBatches":1000} {"correlation_id":"13eed139-b218-43c9-b147-38ae92c45977","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:53] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:sync","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"cf9df816-4614-4a06-b853-4d6815fb85e1","trace_id":"ca6ed313-c21f-4683-8b5b-013a3ecd4081"}
[2026-05-07 13:22:53] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:sync","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"cf9df816-4614-4a06-b853-4d6815fb85e1","trace_id":"ca6ed313-c21f-4683-8b5b-013a3ecd4081"}
[2026-05-07 13:22:57] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"twilio:recover-tracks","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"93d3bd4f-fe02-4d22-aab9-00c74309e94c","trace_id":"356db0f7-0c25-4739-8c8b-a55ba28e1df0"}
[2026-05-07 13:22:57] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"twilio:recover-tracks","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"93d3bd4f-fe02-4d22-aab9-00c74309e94c","trace_id":"356db0f7-0c25-4739-8c8b-a55ba28e1df0"}
[2026-05-07 13:23:00] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:sync-users","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"connect-and-sell"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Start user synchronisation {"provider":"justcall","teams_count":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Synchronising team {"provider":"justcall","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.WARNING: [Salesforce] Account not connected for user {"userId":"cdf9285a-8ded-4a8b-bd7d-ec68c398f2f9","account":{"Jiminny\\Models\\SocialAccount":{"id":1367,"sociable_id":1071,"provider_user_id":"005O4000003s5c7IAA","expires":null,"refresh_token_expires":null,"provider":"salesforce","state":"full-refresh","auth_scope":"refresh_token web api","retry_after":null,"created_at":"2024-09-10 07:05:21","updated_at":"2026-01-14 07:00:58"}}} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] Integration owner is not connected, attempting team members {"crm_provider":"salesforce","crm_owner":1071,"team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] No team members found with active crm connection {"crm_provider":"salesforce","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] No team member found with active crm connection {"crm_provider":"salesforce","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.WARNING: Failed to sync external users {"message":"Your Salesforce account has become disconnected. Please login to Jiminny to reconnect.","provider":"justcall","team_id":1,"team":"jiminny"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"ringcentral"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"avaya"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"telus"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"salesloft"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"talkdesk"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"vonage"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Done {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:sync-users","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:24:05] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:05] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:05] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:07] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"a2d53fd0-ef62-42d7-bf03-2b78fe690081","trace_id":"ccc71cd2-62d3-4641-bbef-d3ac924250df"}
[2026-05-07 13:24:07] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"a2d53fd0-ef62-42d7-bf03-2b78fe690081","trace_id":"ccc71cd2-62d3-4641-bbef-d3ac924250df"}
[2026-05-07 13:24:09] local.NOTICE: Monitoring start {"correlation_id":"550636b7-858f-4d9a-a78c-1a4464ffe5d6","trace_id":"3a5f8440-816e-420f-a5a4-40ad67ca1542"}
[2026-05-07 13:24:09] local.NOTICE: Monitoring end {"correlation_id":"550636b7-858f-4d9a-a78c-1a4464ffe5d6","trace_id":"3a5f8440-816e-420f-a5a4-40ad67ca1542"}
[2026-05-07 13:24:10] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"97b9a580-2259-4931-82fd-86db94dccd2f","trace_id":"1809cb02-fcd4-4cf7-b426-2fe2cf347fb0"}
[2026-05-07 13:24:11] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"97b9a580-2259-4931-82fd-86db94dccd2f","trace_id":"1809cb02-fcd4-4cf7-b426-2fe2cf347fb0"}
[2026-05-07 13:24:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: Running conference:monitor:count command for activities in (2026-05-07 13:22:00, 2026-05-07 13:24:00] {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: [conference:monitor:count] No activities found in (2026-05-07 13:22:00, 2026-05-07 13:24:00] {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:aircall:check-and-renew","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [SocialAccountService] Fetching token {"socialAccountId":1496,"provider":"aircall"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [SocialAccountService] Token retrieved {"socialAccountId":1496,"provider":"aircall"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.ERROR: [Aircall] Re-activating webhooks failed {"team_id":1,"reason":"{\"message\":\"Forbidden\"}"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:aircall:check-and-renew","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:19] local.INFO: [RetryFailedDownloads] Starting {"options":{"from":null,"to":null,"help":false,"silent":false,"quiet":false,"verbose":false,"version":false,"ansi":null,"no-interaction":false,"env":null}} {"correlation_id":"df682399-d6b7-464b-9aea-85a4d7b10c27","trace_id":"532cf674-cebb-4b99-9190-d3020576b5db"}
[2026-05-07 13:25:06] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:06] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:06] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:08] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"846be41a-5d95-4144-ad3c-273defc37bea","trace_id":"8e158a4b-31e7-4161-af5e-d83f2ad2f3b5"}
[2026-05-07 13:25:08] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"846be41a-5d95-4144-ad3c-273defc37bea","trace_id":"8e158a4b-31e7-4161-af5e-d83f2ad2f3b5"}
[2026-05-07 13:25:11] local.NOTICE: Monitoring start {"correlation_id":"779be55d-57e0-4a33-8d13-cb3fda9c8ce5","trace_id":"4eaf7c2a-5a99-4c32-9fb9-b1377cacdebb"}
[2026-05-07 13:25:11] local.NOTICE: Monitoring end {"correlation_id":"779be55d-57e0-4a33-8d13-cb3fda9c8ce5","trace_id":"4eaf7c2a-5a99-4c32-9fb9-b1377cacdebb"}
[2026-05-07 13:25:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"75ba5939-1152-41ac-bed9-e3c203b981c3","trace_id":"f8537beb-7cb8-4f02-ab66-07754746b812"}
[2026-05-07 13:25:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"75ba5939-1152-41ac-bed9-e3c203b981c3","trace_id":"f8537beb-7cb8-4f02-ab66-07754746b812"}
[2026-05-07 13:25:19] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:21] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:purge-stale","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"3c03ff8f-9391-46b3-9001-5d3e3f364d29","trace_id":"5c5f2a08-7eb1-4eb3-9754-cde3f0425216"}
[2026-05-07 13:25:21] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:purge-stale","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"3c03ff8f-9391-46b3-9001-5d3e3f364d29","trace_id":"5c5f2a08-7eb1-4eb3-9754-cde3f0425216"}
[2026-05-07 13:25:23] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:text-relay:sync","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"640405cd-fddb-4ae4-ab6b-0da9052b22fa","trace_id":"0f39ab5c-c1aa-4aa1-a71c-b62823493c4e"}
[2026-05-07 13:25:23] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:text-relay:sync","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"640405cd-fddb-4ae4-ab6b-0da9052b22fa","trace_id":"0f39ab5c-c1aa-4aa1-a71c-b62823493c4e"}
[2026-05-07 13:25:26] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:pre-meeting-notification","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:26] local.INFO: Running pre-meeting notification command {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:26] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:pre-meeting-notification","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:29] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:start","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: Running conference:monitor:start command for activities in (2026-05-07 13:15:00, 2026-05-07 13:20:00] {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: [conference:monitor:start] No activities found in (2026-05-07 13:15:00, 2026-05-07 13:20:00] {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:start","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:37] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:end","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: conference:monitor:end:Jiminny\Console\Commands\Activities\MonitorMeetingEndCommand::logActivitiesEnded {"from":"13:20","to":"13:25"} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: conference:monitor:end:Jiminny\Console\Commands\Activities\MonitorMeetingEndCommand::logActivitiesWithUnfinishedSession {"from":"03:15","to":"03:20"} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:end","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:41] local.NOTICE: Repairing HubSpot tokens start {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: Trying to refresh HubSpot token {"account_id":59,"updated_at":"2025-10-03 09:32:05"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":59,"provider":"hubspot","refreshToken":"97b78f6e2cc49965c00c2492b602b02708b1392551e6b3f113fbaa48992af90b","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.ERROR: Failed to refresh HubSpot token {"account_id":59,"updated_at":"2025-10-03 09:32:05","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: Trying to refresh HubSpot token {"account_id":306,"updated_at":"2023-11-27 09:30:03"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":306,"provider":"hubspot","refreshToken":"6fa6aa8cc641d131231acc3470f5c03cb3b07b2e580fb18f8acb3b1dbb72549b","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.ERROR: Failed to refresh HubSpot token {"account_id":306,"updated_at":"2023-11-27 09:30:03","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: Trying to refresh HubSpot token {"account_id":1372,"updated_at":"2025-10-02 14:47:06"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":1372,"provider":"hubspot","refreshToken":"9aa73948c761da29dce46c177cf9aee1fde483a44169ca38723f9f0597d7a8c4","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.ERROR: Failed to refresh HubSpot token {"account_id":1372,"updated_at":"2025-10-02 14:47:06","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.NOTICE: Repairing HubSpot tokens end {"total":3,"fixed":0,"failed":3} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:pre-meeting-reminder","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"2775b4f9-6dce-40a2-84ad-fb7f3a2729ed","trace_id":"89eb011f-145e-44f2-a376-0c57cf42c11d"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"crm:bullhorn:ping","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"1b0300f0-a82f-4bf2-b5dc-24e9d04babab","trace_id":"af7b7ef6-7376-48fe-b7b9-a5ad41237fa4"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"crm:bullhorn:ping","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id...
|
PhpStorm
|
faVsco.js β ~/jiminny/app/vendor/hubspot/api-clien faVsco.js β ~/jiminny/app/vendor/hubspot/api-client/codegen/Crm/Deals/Api/BasicApi.php...
|
NULL
|
4342
|
|
4341
|
PhostormVIewINavigarecodeLaravelKeractorFV faVsco. PhostormVIewINavigarecodeLaravelKeractorFV faVsco.jsΒ°9 master kProiect vRematchActivityOnCrmObjectDetach.phpΒ© Client.php X(C) TranscodeParameterResdΒ© HubspotPaginationService.phpΒ© UserService.phpΒ© Uuid.php> D TraitsD UseCases> D User> D UtilsβΊ D Validation> OvOphp nelpers.ongΒ© InitialFrontendState.phpΒ© Jiminny.phpc) Plan.ohoc) serializer.onoC) TeamScimDetails.ohpbootstrap>Β© build.> contiaβ contrioβ database>M docsM front-end>D lang> node_modules library rootM ohostan> M nublic> D resourcesv Mroutesphp api.phppnp api_vz.ongpnp console.onopnp customer_api.onppnp embedded.ongpnp nealtn.onppnp scim.onophp uprotectedweb.phpphp web.phpphp webhook.php>O scriptsv O storage>M debugbarM frameworkv Mloas.aitianoreΓͺ audio. wav= custom.loalT OpportunitySyncTrait.phpΒ© HubspotSingleSyncStrategy.phpΒ© WebhookSyncBatchProcessor.phcImportbatchJoblrait.ono(C) Hubspot/Service.pho=hubsnot-iournal-noll.log= laravel logus tht isΒ© Companies.phc(C) MatchActivityermData.pho(C) CrmActivityService.phpΒ©) CachedCrmServiceDecorator.phg* Hubspot/.../SyncCrmEntitiesTrait.phpΒ©) Pipedrive/Service.php0 Servicelntertace.php@ OpportunitvSvncTest.oho(C) RateLimit.ohoΒ© ProviderRateLimiter.phpcllass Uuient extends Basedlient imoilements Huhsnotu ientinterface82 A68 V2 ^1121231341135private function executeRequest(callable $apiCall)= Sthis->conf1q->team1d=> Sthis->config->qetIdo.= Se-βΊqetMessageothrow new RateLimitException( message: 'Hubspot returned 429', SretryAfter,throw $e;2 usagespublic function isHubspotRateLimit(Throwable $e): boolmethod: 'getCode') && (int) $e->getCode === 429:2 usagespublic function parseRetryAfter(Throwable Se): intif (method exists(Senethod: 'qetResponseHeaders')) {Sheaders = se->qetResponseleaderso?:Sthis->loq->info('[Hubspot] DEBUG Getting headers'. [= Sheaders,$value = $headers['Retry-After'] ?? $headers['retry-after'] ?? null;if Gis arrav(Svalue)) {Svalue = $valuel0l 22 null:if Gis numeric(svalue)) <returnaint) Svalte,neturn 10.1AGT )public function getMinimumApiVersion: string{...}narAube for lblE suadestiionsa Detect more seawritvlsaues lin vour D.D files llia SonarAube Claud for free //lDownload SonarOnbe Server lllearn more //lDonit ask again /(today 105251I111==custom.log=laravel.log X4 SF jiminny@localhost4 HS_local jiminny@localhostiti accounts (jiminny@localhost]A console [PKOU.# console [eu)* console [STAGINGI[2026-05-07 13:22:12] local.INF0:[2026-05-07 13:22:12] local.INF0:[SocialAccountService] Fetching token f"socialAccountId":1499, ",*W604 A V[SocialAccountServicel Token needs refreshing {"socialAccountId":1499. "provider'12020-05-01 15.2L.12 Local. LNFU.lencryoredlokennanacer beneracino access coken.de". Lecacy" "correlacl12026-05-07 15:22:12 Local.INFU?{"socialAccountId" :1499, "P112026-05-07 15:22:12 Local.INFO:Soc1aLAccountUbserver Saving model""correlation_1d":"345t341d-028t-4C8C-957β΄modified, encrypting {"correlation_id"12026-05-07 13:22:15 Local.INF0:Soc1aLAccountServicel Token refreshed "soc1alAccountid":1499."providen":"hubse[2026-05-07 13:22:13] Local. INFO:12026-05-07 15:22151"retry aften": 10."rei\"status)":\"error)", "message)":\"You have reached your secondly limit.\", \"errorType)": \"RATE_LIMIT\", \"correla"-"correlation id":"343F341d-028f-4c8c-9578-252FcdebebΒ«c" "trace id"."41071c00-9712-46eb-8acf-d5c4298Fea69"12026-05-07 13:22:13 Local, ERROR: Hubsoot returned 429 <"excentioni(Jiminny)\Exceptions\\RateLimitExcestacktrace]l#0 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny|\Services\\Crm\\Hut#1 /home/jiminny/app/Services/Crm/Hubspot/CLient.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPag#2 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\|Services\\Crm\\Hubspot\\Client->getPaginatec#3/home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matc#4/home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommane#5/home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Command:#6 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\BoundMethc/home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Uti#8/home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\Bor#9 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminatel\Container\\Bour#10/home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\Container\Contain#1.1/home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\Consolel\Command->execute(Obiect(Sy#12/home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\Component Consolel\C#13/home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\Console\Command->run(Obiect(Symfony))#14/home/jiminny/vendor/symfony/console/Application.php(356): Symfony|\Component\Console\Application->doRunComihome/71m1nny/vendor/symtonyconsole/Application.pnp(195: symtony Component Console Application->doRun(UbTFo home/aaminnyvendor/anaveu namework scca Luminare roundation console/ Kernel ohous: SymtonyComponent#18 /home/Timinny/artisan(13): TlluminateFoundationAopuication->handl eCommandObiect SumfonyComponent Cons.#19 {main?Lprevious exception lobject) (SevenShores)\Hubspot)\Exceptions\BadRequest(code: 429): Client error: POST https"status "* "error". "message":"You have reached vour secondly limit. ". "errorivoe": "RATE LIMIT"."correlat /home/jiminny/vendor/hubspot/hubspot-php/src/Exceptions/HubspotExcention.oho:24)listacktnace#0 /home/jiminny/vendor/hubspot/hubspot-php/src/Http/Client.php(125): SevenShores\\Hubspot\\Exceptions\\HubspotExc#1 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(166): SevenShores\\Hubspot\\Http:/home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny|\Services\\Crm\\Hut#3/home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\(Services\\Crm\\Hubspot\\Pagination\\HubspotPac/home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatechome/Ltiminnv/ann/Console/Commande/_Liminnv0ohuaCommand.ohn/@52LiminnvSonviicosom.WmbsnotSonvico-smatc/home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommane/bomo/4iminnv/vondon/lanavol/fnamowonk/cnc/Tlluminato/Containen/RoundMothod nhn(2/)β’ liminnvl\Concolel\Command#8 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminatel|Container|\BoundMethe#9/home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): IlluminateContainer\Uti#10/home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\Container\Bc#11/home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\Container\BorLukas/Stefka 121 - in 1h 2 m100% 12Thu 7 May 16:28:06AskJiminnyReportActivityServiceTest vCascadeHubspot Rate LimitingHubSpot Rate Limit HHow to Access the Header in Your codeIf you need to check the header manually for debugging:β’ php// For new SDK (ApiException)trySresponse = Sclient->request...:} catch (\HubSpot\Client\Crm\Objects\ApiException $e) {nseHeaders() ?: 0SretryAfter = $headers ('Retry-After'][0] ?? $headers['retry-after'] [0] ?? null;f(SretrvAfter)// HubSpot sent retry guidance} else{/ No header - use detault based on error messageSbody = ison decode(Se-saetResponseBodvo). true).SretryAfter = match($body['policyName'] ?? null) {detault = 10,RecommendationThe current imolementation at Service.oho: 1721-1727 already handles this correctly by checking policyName:β’ ph:sresponse =son decodelse->geckesponsebody, true&& Sresponsel'policyName'] == self::TEN SECONDLY ROLLING POLICY?self::TEN SECONDLY ROLLING LIMITI: 1; // Default 1 second for other limitsI/ 10 seconds|To see if headers are actually present, add temporary logging:β’ oho.Sheaders = se->oetResponseHeaderso?::Log: : debug('[HubSpot) Rate limit response headers', [headers = Sheaders'retry_after' => $headers ['Retry-After'] ?? $headers['retry-after'] ?? 'NOT_PRESENT',1):Ask anvthina (&4DβΉ> CodeCΒ° AdantiveW Windsurf Teams+0 ..r.al .22β’61UTF.8io 4 spaces...
|
PhpStorm
|
faVsco.js β Client.php
|
NULL
|
4341
|
|
4340
|
iTerm2ShellEditViewSessionScriptsProfilesWindowHel iTerm2ShellEditViewSessionScriptsProfilesWindowHelp$0.β’ Lukas/Stefka 121 - in 1h 2 m100% <478Thu 7 May 16:28:06DOCKERDEV (docker)182worker-crm-sync:worker-crm-sync_00: startedworker-crm-update:worker-crm-update_00: startedworker-download:worker-download_00: startedworker-emails:worker-emails_00: startedworker-es-update:worker-es-update_00: startedworker-nudges:worker-nudges_00: startedroot@docker_lamp_1:/home/jiminny# php artisan jiminny:debugMatching contact 0Matching contact 1Matching contact 2Matching contactMatchingcontact4Matchingcontact5Matchingcontact 6Matching contact 7Matching contact 8Matching contact 9root@docker_lamp_1:/home/jiminny# php artisan jiminny:debugMatching contact 0APP (-zsh)DEV (docker)*3T81-zshβ’ 84|screenpipe*β’$5Jiminny \Exceptions \RateLimitExceptionHubspot returned 429at app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php:206202'retry_after' =SretryAfter,203"reason"204= Se->getMessage(),205β 206throw new RateLimitException('Hubspot returned 429', SretryAfter, $e);207208} else 1throw $e;209}210+14 vendor frames15-zshβ΄6DEVapp/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php:166SevenShores\Hubspot\Http\Client:: request("POST", "[URL_WITH_CREDENTIALS] ]...
|
PhpStorm
|
faVsco.js β Client.php
|
NULL
|
4340
|
|
4339
|
All Places
Preview
Filter
Open in Find Tool Window All Places
Preview
Filter
Open in Find Tool Window
SevenShores\\Hubspot\\Exceptions\\BadRequest
Jobs/Crm/MatchActivityCrmData.php
Open In Right Split...
|
PhpStorm
|
|
NULL
|
4339
|
|
4338
|
All Places
Preview
Filter
Open in Find Tool Window All Places
Preview
Filter
Open in Find Tool Window
SevenShores\\Hubspot\\Exceptions\\BadRequest
Jobs/Crm/MatchActivityCrmData.php
Open In Right Split...
|
PhpStorm
|
|
NULL
|
4338
|
|
4337
|
Project: faVsco.js, menu
master, menu
Start Listen Project: faVsco.js, menu
master, menu
Start Listening for PHP Debug Connections
AskJiminnyReportActivityServiceTest
Run 'AskJiminnyReportActivityServiceTest'
Debug 'AskJiminnyReportActivityServiceTest'
More Actions
JetBrains AI
Search Everywhere
IDE and Project Settings
Sync Changes
Hide This Notification
Code changed:
Hide
286
Previous Highlighted Error
Next Highlighted Error
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Fetching token {"socialAccountId":1499,"provider":"hubspot"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Token needs refreshing {"socialAccountId":1499,"provider":"hubspot"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":1499,"provider":"hubspot","refreshToken":"96f94c623a404e02ebdbf07f1b75707bb6cdbf848cbf45d418baf608c41a8d86","state":"connected"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountObserver] Saving model {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountObserver] Access token was modified, encrypting {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [SocialAccountService] Token refreshed {"socialAccountId":1499,"provider":"hubspot","state":"connected"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [CrmOwnerResolver] Integration owner matched as CRM Owner {"crm_provider":"hubspot","crm_owner":148,"team_id":2} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [Hubspot] Received 429 from API {"team_id":2,"config_id":2,"retry_after":10,"reason":"Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.ERROR: Hubspot returned 429 {"exception":"[object] (Jiminny\\Exceptions\\RateLimitException(code: 0): Hubspot returned 429 at /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php:206)
[stacktrace]
#0 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#1 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#2 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#3 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#4 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#5 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#6 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#7 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#8 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#9 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#10 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#11 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#12 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#13 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#14 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#15 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#16 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#17 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#18 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#19 {main}
[previous exception] [object] (SevenShores\\Hubspot\\Exceptions\\BadRequest(code: 429): Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
at /home/jiminny/vendor/hubspot/hubspot-php/src/Exceptions/HubspotException.php:24)
[stacktrace]
#0 /home/jiminny/vendor/hubspot/hubspot-php/src/Http/Client.php(125): SevenShores\\Hubspot\\Exceptions\\HubspotException::create(Object(GuzzleHttp\\Exception\\ClientException))
#1 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(166): SevenShores\\Hubspot\\Http\\Client->request('POST', 'https://api.hub...', Array)
#2 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#3 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#4 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#5 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#6 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#7 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#8 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#9 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#10 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#11 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#12 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#13 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#14 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#15 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#16 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#17 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#18 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#19 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#20 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#21 {main}
[previous exception] [object] (GuzzleHttp\\Exception\\ClientException(code: 429): Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
at /home/jiminny/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:111)
[stacktrace]
#0 /home/jiminny/vendor/guzzlehttp/guzzle/src/Middleware.php(72): GuzzleHttp\\Exception\\RequestException::create(Object(GuzzleHttp\\Psr7\\Request), Object(GuzzleHttp\\Psr7\\Response), NULL, Array, NULL)
#1 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(209): GuzzleHttp\\Middleware::GuzzleHttp\\{closure}(Object(GuzzleHttp\\Psr7\\Response))
#2 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(158): GuzzleHttp\\Promise\\Promise::callHandler(1, Object(GuzzleHttp\\Psr7\\Response), NULL)
#3 /home/jiminny/vendor/guzzlehttp/promises/src/TaskQueue.php(52): GuzzleHttp\\Promise\\Promise::GuzzleHttp\\Promise\\{closure}()
#4 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(251): GuzzleHttp\\Promise\\TaskQueue->run(true)
#5 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(227): GuzzleHttp\\Promise\\Promise->invokeWaitFn()
#6 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(272): GuzzleHttp\\Promise\\Promise->waitIfPending()
#7 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(229): GuzzleHttp\\Promise\\Promise->invokeWaitList()
#8 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(69): GuzzleHttp\\Promise\\Promise->waitIfPending()
#9 /home/jiminny/vendor/guzzlehttp/guzzle/src/Client.php(189): GuzzleHttp\\Promise\\Promise->wait()
#10 /home/jiminny/vendor/hubspot/hubspot-php/src/Http/Client.php(113): GuzzleHttp\\Client->request('POST', 'https://api.hub...', Array)
#11 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(166): SevenShores\\Hubspot\\Http\\Client->request('POST', 'https://api.hub...', Array)
#12 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#13 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#14 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#15 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#16 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#17 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#18 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#19 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#20 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#21 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#22 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#23 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#24 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#25 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#26 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#27 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#28 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#29 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#30 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#31 {main}
"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:13] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"076c3e6b-6a67-4774-8aa0-2a84fcf5e03c","trace_id":"284e571d-ab92-4e22-b09b-c151c2871cb4"}
[2026-05-07 13:22:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"076c3e6b-6a67-4774-8aa0-2a84fcf5e03c","trace_id":"284e571d-ab92-4e22-b09b-c151c2871cb4"}
[2026-05-07 13:22:19] local.NOTICE: Monitoring start {"correlation_id":"c41d4048-0465-4dcf-bb53-176287732e3e","trace_id":"9ce4a71c-a1a0-456e-843d-38fd15e5c798"}
[2026-05-07 13:22:19] local.NOTICE: Monitoring end {"correlation_id":"c41d4048-0465-4dcf-bb53-176287732e3e","trace_id":"9ce4a71c-a1a0-456e-843d-38fd15e5c798"}
[2026-05-07 13:22:30] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"934766d6-40c0-415c-bd51-d0b67a799c7c","trace_id":"d6c773e8-adf4-453b-8a17-077bf7bdf698"}
[2026-05-07 13:22:30] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"934766d6-40c0-415c-bd51-d0b67a799c7c","trace_id":"d6c773e8-adf4-453b-8a17-077bf7bdf698"}
[2026-05-07 13:22:35] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:41] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: Running conference:monitor:count command for activities in (2026-05-07 13:20:00, 2026-05-07 13:22:00] {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: [conference:monitor:count] No activities found in (2026-05-07 13:20:00, 2026-05-07 13:22:00] {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:create","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: [EmailSchedule] STARTING batch create {"host":"docker_lamp_1"} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: [EmailSchedule] FINISHED batch create {"host":"docker_lamp_1"} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:create","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:52] local.INFO: [Jiminny\Jobs\Mailbox\CreateBatches] processed 2 inboxes and created 0 batches {"userId":null,"batchSize":30,"maxBatches":1000} {"correlation_id":"13eed139-b218-43c9-b147-38ae92c45977","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:53] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:sync","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"cf9df816-4614-4a06-b853-4d6815fb85e1","trace_id":"ca6ed313-c21f-4683-8b5b-013a3ecd4081"}
[2026-05-07 13:22:53] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:sync","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"cf9df816-4614-4a06-b853-4d6815fb85e1","trace_id":"ca6ed313-c21f-4683-8b5b-013a3ecd4081"}
[2026-05-07 13:22:57] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"twilio:recover-tracks","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"93d3bd4f-fe02-4d22-aab9-00c74309e94c","trace_id":"356db0f7-0c25-4739-8c8b-a55ba28e1df0"}
[2026-05-07 13:22:57] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"twilio:recover-tracks","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"93d3bd4f-fe02-4d22-aab9-00c74309e94c","trace_id":"356db0f7-0c25-4739-8c8b-a55ba28e1df0"}
[2026-05-07 13:23:00] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:sync-users","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"connect-and-sell"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Start user synchronisation {"provider":"justcall","teams_count":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Synchronising team {"provider":"justcall","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.WARNING: [Salesforce] Account not connected for user {"userId":"cdf9285a-8ded-4a8b-bd7d-ec68c398f2f9","account":{"Jiminny\\Models\\SocialAccount":{"id":1367,"sociable_id":1071,"provider_user_id":"005O4000003s5c7IAA","expires":null,"refresh_token_expires":null,"provider":"salesforce","state":"full-refresh","auth_scope":"refresh_token web api","retry_after":null,"created_at":"2024-09-10 07:05:21","updated_at":"2026-01-14 07:00:58"}}} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] Integration owner is not connected, attempting team members {"crm_provider":"salesforce","crm_owner":1071,"team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] No team members found with active crm connection {"crm_provider":"salesforce","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] No team member found with active crm connection {"crm_provider":"salesforce","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.WARNING: Failed to sync external users {"message":"Your Salesforce account has become disconnected. Please login to Jiminny to reconnect.","provider":"justcall","team_id":1,"team":"jiminny"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"ringcentral"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"avaya"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"telus"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"salesloft"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"talkdesk"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"vonage"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Done {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:sync-users","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:24:05] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:05] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:05] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:07] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"a2d53fd0-ef62-42d7-bf03-2b78fe690081","trace_id":"ccc71cd2-62d3-4641-bbef-d3ac924250df"}
[2026-05-07 13:24:07] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"a2d53fd0-ef62-42d7-bf03-2b78fe690081","trace_id":"ccc71cd2-62d3-4641-bbef-d3ac924250df"}
[2026-05-07 13:24:09] local.NOTICE: Monitoring start {"correlation_id":"550636b7-858f-4d9a-a78c-1a4464ffe5d6","trace_id":"3a5f8440-816e-420f-a5a4-40ad67ca1542"}
[2026-05-07 13:24:09] local.NOTICE: Monitoring end {"correlation_id":"550636b7-858f-4d9a-a78c-1a4464ffe5d6","trace_id":"3a5f8440-816e-420f-a5a4-40ad67ca1542"}
[2026-05-07 13:24:10] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"97b9a580-2259-4931-82fd-86db94dccd2f","trace_id":"1809cb02-fcd4-4cf7-b426-2fe2cf347fb0"}
[2026-05-07 13:24:11] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"97b9a580-2259-4931-82fd-86db94dccd2f","trace_id":"1809cb02-fcd4-4cf7-b426-2fe2cf347fb0"}
[2026-05-07 13:24:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: Running conference:monitor:count command for activities in (2026-05-07 13:22:00, 2026-05-07 13:24:00] {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: [conference:monitor:count] No activities found in (2026-05-07 13:22:00, 2026-05-07 13:24:00] {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:aircall:check-and-renew","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [SocialAccountService] Fetching token {"socialAccountId":1496,"provider":"aircall"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [SocialAccountService] Token retrieved {"socialAccountId":1496,"provider":"aircall"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.ERROR: [Aircall] Re-activating webhooks failed {"team_id":1,"reason":"{\"message\":\"Forbidden\"}"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:aircall:check-and-renew","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:19] local.INFO: [RetryFailedDownloads] Starting {"options":{"from":null,"to":null,"help":false,"silent":false,"quiet":false,"verbose":false,"version":false,"ansi":null,"no-interaction":false,"env":null}} {"correlation_id":"df682399-d6b7-464b-9aea-85a4d7b10c27","trace_id":"532cf674-cebb-4b99-9190-d3020576b5db"}
[2026-05-07 13:25:06] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:06] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:06] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:08] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"846be41a-5d95-4144-ad3c-273defc37bea","trace_id":"8e158a4b-31e7-4161-af5e-d83f2ad2f3b5"}
[2026-05-07 13:25:08] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"846be41a-5d95-4144-ad3c-273defc37bea","trace_id":"8e158a4b-31e7-4161-af5e-d83f2ad2f3b5"}
[2026-05-07 13:25:11] local.NOTICE: Monitoring start {"correlation_id":"779be55d-57e0-4a33-8d13-cb3fda9c8ce5","trace_id":"4eaf7c2a-5a99-4c32-9fb9-b1377cacdebb"}
[2026-05-07 13:25:11] local.NOTICE: Monitoring end {"correlation_id":"779be55d-57e0-4a33-8d13-cb3fda9c8ce5","trace_id":"4eaf7c2a-5a99-4c32-9fb9-b1377cacdebb"}
[2026-05-07 13:25:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"75ba5939-1152-41ac-bed9-e3c203b981c3","trace_id":"f8537beb-7cb8-4f02-ab66-07754746b812"}
[2026-05-07 13:25:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"75ba5939-1152-41ac-bed9-e3c203b981c3","trace_id":"f8537beb-7cb8-4f02-ab66-07754746b812"}
[2026-05-07 13:25:19] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:21] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:purge-stale","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"3c03ff8f-9391-46b3-9001-5d3e3f364d29","trace_id":"5c5f2a08-7eb1-4eb3-9754-cde3f0425216"}
[2026-05-07 13:25:21] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:purge-stale","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"3c03ff8f-9391-46b3-9001-5d3e3f364d29","trace_id":"5c5f2a08-7eb1-4eb3-9754-cde3f0425216"}
[2026-05-07 13:25:23] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:text-relay:sync","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"640405cd-fddb-4ae4-ab6b-0da9052b22fa","trace_id":"0f39ab5c-c1aa-4aa1-a71c-b62823493c4e"}
[2026-05-07 13:25:23] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:text-relay:sync","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"640405cd-fddb-4ae4-ab6b-0da9052b22fa","trace_id":"0f39ab5c-c1aa-4aa1-a71c-b62823493c4e"}
[2026-05-07 13:25:26] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:pre-meeting-notification","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:26] local.INFO: Running pre-meeting notification command {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:26] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:pre-meeting-notification","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:29] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:start","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: Running conference:monitor:start command for activities in (2026-05-07 13:15:00, 2026-05-07 13:20:00] {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: [conference:monitor:start] No activities found in (2026-05-07 13:15:00, 2026-05-07 13:20:00] {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:start","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:37] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:end","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: conference:monitor:end:Jiminny\Console\Commands\Activities\MonitorMeetingEndCommand::logActivitiesEnded {"from":"13:20","to":"13:25"} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: conference:monitor:end:Jiminny\Console\Commands\Activities\MonitorMeetingEndCommand::logActivitiesWithUnfinishedSession {"from":"03:15","to":"03:20"} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:end","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:41] local.NOTICE: Repairing HubSpot tokens start {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: Trying to refresh HubSpot token {"account_id":59,"updated_at":"2025-10-03 09:32:05"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":59,"provider":"hubspot","refreshToken":"97b78f6e2cc49965c00c2492b602b02708b1392551e6b3f113fbaa48992af90b","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.ERROR: Failed to refresh HubSpot token {"account_id":59,"updated_at":"2025-10-03 09:32:05","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: Trying to refresh HubSpot token {"account_id":306,"updated_at":"2023-11-27 09:30:03"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":306,"provider":"hubspot","refreshToken":"6fa6aa8cc641d131231acc3470f5c03cb3b07b2e580fb18f8acb3b1dbb72549b","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.ERROR: Failed to refresh HubSpot token {"account_id":306,"updated_at":"2023-11-27 09:30:03","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: Trying to refresh HubSpot token {"account_id":1372,"updated_at":"2025-10-02 14:47:06"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":1372,"provider":"hubspot","refreshToken":"9aa73948c761da29dce46c177cf9aee1fde483a44169ca38723f9f0597d7a8c4","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.ERROR: Failed to refresh HubSpot token {"account_id":1372,"updated_at":"2025-10-02 14:47:06","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.NOTICE: Repairing HubSpot tokens end {"total":3,"fixed":0,"failed":3} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:pre-meeting-reminder","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"2775b4f9-6dce-40a2-84ad-fb7f3a2729ed","trace_id":"89eb011f-145e-44f2-a376-0c57cf42c11d"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"crm:bullhorn:ping","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"1b0300f0-a82f-4bf2-b5dc-24e9d04babab","trace_id":"af7b7ef6-7376-48fe-b7b9-a5ad41237fa4"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"crm:bullhorn:ping","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id...
|
PhpStorm
|
faVsco.js β laravel.log
|
NULL
|
4337
|
|
4336
|
Project: faVsco.js, menu
master, menu
Start Listen Project: faVsco.js, menu
master, menu
Start Listening for PHP Debug Connections
AskJiminnyReportActivityServiceTest
Run 'AskJiminnyReportActivityServiceTest'
Debug 'AskJiminnyReportActivityServiceTest'
More Actions
JetBrains AI
Search Everywhere
IDE and Project Settings
Sync Changes
Hide This Notification
Code changed:
Hide
286
Previous Highlighted Error
Next Highlighted Error
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Fetching token {"socialAccountId":1499,"provider":"hubspot"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Token needs refreshing {"socialAccountId":1499,"provider":"hubspot"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":1499,"provider":"hubspot","refreshToken":"96f94c623a404e02ebdbf07f1b75707bb6cdbf848cbf45d418baf608c41a8d86","state":"connected"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountObserver] Saving model {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountObserver] Access token was modified, encrypting {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [SocialAccountService] Token refreshed {"socialAccountId":1499,"provider":"hubspot","state":"connected"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [CrmOwnerResolver] Integration owner matched as CRM Owner {"crm_provider":"hubspot","crm_owner":148,"team_id":2} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [Hubspot] Received 429 from API {"team_id":2,"config_id":2,"retry_after":10,"reason":"Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.ERROR: Hubspot returned 429 {"exception":"[object] (Jiminny\\Exceptions\\RateLimitException(code: 0): Hubspot returned 429 at /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php:206)
[stacktrace]
#0 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#1 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#2 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#3 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#4 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#5 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#6 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#7 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#8 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#9 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#10 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#11 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#12 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#13 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#14 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#15 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#16 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#17 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#18 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#19 {main}
[previous exception] [object] (SevenShores\\Hubspot\\Exceptions\\BadRequest(code: 429): Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
at /home/jiminny/vendor/hubspot/hubspot-php/src/Exceptions/HubspotException.php:24)
[stacktrace]
#0 /home/jiminny/vendor/hubspot/hubspot-php/src/Http/Client.php(125): SevenShores\\Hubspot\\Exceptions\\HubspotException::create(Object(GuzzleHttp\\Exception\\ClientException))
#1 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(166): SevenShores\\Hubspot\\Http\\Client->request('POST', 'https://api.hub...', Array)
#2 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#3 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#4 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#5 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#6 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#7 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#8 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#9 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#10 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#11 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#12 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#13 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#14 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#15 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#16 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#17 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#18 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#19 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#20 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#21 {main}
[previous exception] [object] (GuzzleHttp\\Exception\\ClientException(code: 429): Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
at /home/jiminny/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:111)
[stacktrace]
#0 /home/jiminny/vendor/guzzlehttp/guzzle/src/Middleware.php(72): GuzzleHttp\\Exception\\RequestException::create(Object(GuzzleHttp\\Psr7\\Request), Object(GuzzleHttp\\Psr7\\Response), NULL, Array, NULL)
#1 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(209): GuzzleHttp\\Middleware::GuzzleHttp\\{closure}(Object(GuzzleHttp\\Psr7\\Response))
#2 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(158): GuzzleHttp\\Promise\\Promise::callHandler(1, Object(GuzzleHttp\\Psr7\\Response), NULL)
#3 /home/jiminny/vendor/guzzlehttp/promises/src/TaskQueue.php(52): GuzzleHttp\\Promise\\Promise::GuzzleHttp\\Promise\\{closure}()
#4 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(251): GuzzleHttp\\Promise\\TaskQueue->run(true)
#5 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(227): GuzzleHttp\\Promise\\Promise->invokeWaitFn()
#6 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(272): GuzzleHttp\\Promise\\Promise->waitIfPending()
#7 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(229): GuzzleHttp\\Promise\\Promise->invokeWaitList()
#8 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(69): GuzzleHttp\\Promise\\Promise->waitIfPending()
#9 /home/jiminny/vendor/guzzlehttp/guzzle/src/Client.php(189): GuzzleHttp\\Promise\\Promise->wait()
#10 /home/jiminny/vendor/hubspot/hubspot-php/src/Http/Client.php(113): GuzzleHttp\\Client->request('POST', 'https://api.hub...', Array)
#11 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(166): SevenShores\\Hubspot\\Http\\Client->request('POST', 'https://api.hub...', Array)
#12 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#13 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#14 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#15 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#16 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#17 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#18 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#19 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#20 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#21 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#22 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#23 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#24 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#25 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#26 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#27 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#28 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#29 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#30 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#31 {main}
"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:13] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"076c3e6b-6a67-4774-8aa0-2a84fcf5e03c","trace_id":"284e571d-ab92-4e22-b09b-c151c2871cb4"}
[2026-05-07 13:22:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"076c3e6b-6a67-4774-8aa0-2a84fcf5e03c","trace_id":"284e571d-ab92-4e22-b09b-c151c2871cb4"}
[2026-05-07 13:22:19] local.NOTICE: Monitoring start {"correlation_id":"c41d4048-0465-4dcf-bb53-176287732e3e","trace_id":"9ce4a71c-a1a0-456e-843d-38fd15e5c798"}
[2026-05-07 13:22:19] local.NOTICE: Monitoring end {"correlation_id":"c41d4048-0465-4dcf-bb53-176287732e3e","trace_id":"9ce4a71c-a1a0-456e-843d-38fd15e5c798"}
[2026-05-07 13:22:30] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"934766d6-40c0-415c-bd51-d0b67a799c7c","trace_id":"d6c773e8-adf4-453b-8a17-077bf7bdf698"}
[2026-05-07 13:22:30] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"934766d6-40c0-415c-bd51-d0b67a799c7c","trace_id":"d6c773e8-adf4-453b-8a17-077bf7bdf698"}
[2026-05-07 13:22:35] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:41] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: Running conference:monitor:count command for activities in (2026-05-07 13:20:00, 2026-05-07 13:22:00] {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: [conference:monitor:count] No activities found in (2026-05-07 13:20:00, 2026-05-07 13:22:00] {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:create","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: [EmailSchedule] STARTING batch create {"host":"docker_lamp_1"} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: [EmailSchedule] FINISHED batch create {"host":"docker_lamp_1"} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:create","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:52] local.INFO: [Jiminny\Jobs\Mailbox\CreateBatches] processed 2 inboxes and created 0 batches {"userId":null,"batchSize":30,"maxBatches":1000} {"correlation_id":"13eed139-b218-43c9-b147-38ae92c45977","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:53] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:sync","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"cf9df816-4614-4a06-b853-4d6815fb85e1","trace_id":"ca6ed313-c21f-4683-8b5b-013a3ecd4081"}
[2026-05-07 13:22:53] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:sync","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"cf9df816-4614-4a06-b853-4d6815fb85e1","trace_id":"ca6ed313-c21f-4683-8b5b-013a3ecd4081"}
[2026-05-07 13:22:57] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"twilio:recover-tracks","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"93d3bd4f-fe02-4d22-aab9-00c74309e94c","trace_id":"356db0f7-0c25-4739-8c8b-a55ba28e1df0"}
[2026-05-07 13:22:57] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"twilio:recover-tracks","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"93d3bd4f-fe02-4d22-aab9-00c74309e94c","trace_id":"356db0f7-0c25-4739-8c8b-a55ba28e1df0"}
[2026-05-07 13:23:00] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:sync-users","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"connect-and-sell"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Start user synchronisation {"provider":"justcall","teams_count":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Synchronising team {"provider":"justcall","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.WARNING: [Salesforce] Account not connected for user {"userId":"cdf9285a-8ded-4a8b-bd7d-ec68c398f2f9","account":{"Jiminny\\Models\\SocialAccount":{"id":1367,"sociable_id":1071,"provider_user_id":"005O4000003s5c7IAA","expires":null,"refresh_token_expires":null,"provider":"salesforce","state":"full-refresh","auth_scope":"refresh_token web api","retry_after":null,"created_at":"2024-09-10 07:05:21","updated_at":"2026-01-14 07:00:58"}}} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] Integration owner is not connected, attempting team members {"crm_provider":"salesforce","crm_owner":1071,"team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] No team members found with active crm connection {"crm_provider":"salesforce","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] No team member found with active crm connection {"crm_provider":"salesforce","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.WARNING: Failed to sync external users {"message":"Your Salesforce account has become disconnected. Please login to Jiminny to reconnect.","provider":"justcall","team_id":1,"team":"jiminny"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"ringcentral"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"avaya"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"telus"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"salesloft"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"talkdesk"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"vonage"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Done {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:sync-users","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:24:05] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:05] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:05] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:07] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"a2d53fd0-ef62-42d7-bf03-2b78fe690081","trace_id":"ccc71cd2-62d3-4641-bbef-d3ac924250df"}
[2026-05-07 13:24:07] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"a2d53fd0-ef62-42d7-bf03-2b78fe690081","trace_id":"ccc71cd2-62d3-4641-bbef-d3ac924250df"}
[2026-05-07 13:24:09] local.NOTICE: Monitoring start {"correlation_id":"550636b7-858f-4d9a-a78c-1a4464ffe5d6","trace_id":"3a5f8440-816e-420f-a5a4-40ad67ca1542"}
[2026-05-07 13:24:09] local.NOTICE: Monitoring end {"correlation_id":"550636b7-858f-4d9a-a78c-1a4464ffe5d6","trace_id":"3a5f8440-816e-420f-a5a4-40ad67ca1542"}
[2026-05-07 13:24:10] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"97b9a580-2259-4931-82fd-86db94dccd2f","trace_id":"1809cb02-fcd4-4cf7-b426-2fe2cf347fb0"}
[2026-05-07 13:24:11] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"97b9a580-2259-4931-82fd-86db94dccd2f","trace_id":"1809cb02-fcd4-4cf7-b426-2fe2cf347fb0"}
[2026-05-07 13:24:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: Running conference:monitor:count command for activities in (2026-05-07 13:22:00, 2026-05-07 13:24:00] {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: [conference:monitor:count] No activities found in (2026-05-07 13:22:00, 2026-05-07 13:24:00] {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:aircall:check-and-renew","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [SocialAccountService] Fetching token {"socialAccountId":1496,"provider":"aircall"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [SocialAccountService] Token retrieved {"socialAccountId":1496,"provider":"aircall"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.ERROR: [Aircall] Re-activating webhooks failed {"team_id":1,"reason":"{\"message\":\"Forbidden\"}"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:aircall:check-and-renew","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:19] local.INFO: [RetryFailedDownloads] Starting {"options":{"from":null,"to":null,"help":false,"silent":false,"quiet":false,"verbose":false,"version":false,"ansi":null,"no-interaction":false,"env":null}} {"correlation_id":"df682399-d6b7-464b-9aea-85a4d7b10c27","trace_id":"532cf674-cebb-4b99-9190-d3020576b5db"}
[2026-05-07 13:25:06] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:06] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:06] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:08] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"846be41a-5d95-4144-ad3c-273defc37bea","trace_id":"8e158a4b-31e7-4161-af5e-d83f2ad2f3b5"}
[2026-05-07 13:25:08] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"846be41a-5d95-4144-ad3c-273defc37bea","trace_id":"8e158a4b-31e7-4161-af5e-d83f2ad2f3b5"}
[2026-05-07 13:25:11] local.NOTICE: Monitoring start {"correlation_id":"779be55d-57e0-4a33-8d13-cb3fda9c8ce5","trace_id":"4eaf7c2a-5a99-4c32-9fb9-b1377cacdebb"}
[2026-05-07 13:25:11] local.NOTICE: Monitoring end {"correlation_id":"779be55d-57e0-4a33-8d13-cb3fda9c8ce5","trace_id":"4eaf7c2a-5a99-4c32-9fb9-b1377cacdebb"}
[2026-05-07 13:25:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"75ba5939-1152-41ac-bed9-e3c203b981c3","trace_id":"f8537beb-7cb8-4f02-ab66-07754746b812"}
[2026-05-07 13:25:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"75ba5939-1152-41ac-bed9-e3c203b981c3","trace_id":"f8537beb-7cb8-4f02-ab66-07754746b812"}
[2026-05-07 13:25:19] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:21] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:purge-stale","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"3c03ff8f-9391-46b3-9001-5d3e3f364d29","trace_id":"5c5f2a08-7eb1-4eb3-9754-cde3f0425216"}
[2026-05-07 13:25:21] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:purge-stale","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"3c03ff8f-9391-46b3-9001-5d3e3f364d29","trace_id":"5c5f2a08-7eb1-4eb3-9754-cde3f0425216"}
[2026-05-07 13:25:23] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:text-relay:sync","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"640405cd-fddb-4ae4-ab6b-0da9052b22fa","trace_id":"0f39ab5c-c1aa-4aa1-a71c-b62823493c4e"}
[2026-05-07 13:25:23] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:text-relay:sync","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"640405cd-fddb-4ae4-ab6b-0da9052b22fa","trace_id":"0f39ab5c-c1aa-4aa1-a71c-b62823493c4e"}
[2026-05-07 13:25:26] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:pre-meeting-notification","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:26] local.INFO: Running pre-meeting notification command {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:26] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:pre-meeting-notification","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:29] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:start","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: Running conference:monitor:start command for activities in (2026-05-07 13:15:00, 2026-05-07 13:20:00] {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: [conference:monitor:start] No activities found in (2026-05-07 13:15:00, 2026-05-07 13:20:00] {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:start","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:37] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:end","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: conference:monitor:end:Jiminny\Console\Commands\Activities\MonitorMeetingEndCommand::logActivitiesEnded {"from":"13:20","to":"13:25"} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: conference:monitor:end:Jiminny\Console\Commands\Activities\MonitorMeetingEndCommand::logActivitiesWithUnfinishedSession {"from":"03:15","to":"03:20"} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:end","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:41] local.NOTICE: Repairing HubSpot tokens start {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: Trying to refresh HubSpot token {"account_id":59,"updated_at":"2025-10-03 09:32:05"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":59,"provider":"hubspot","refreshToken":"97b78f6e2cc49965c00c2492b602b02708b1392551e6b3f113fbaa48992af90b","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.ERROR: Failed to refresh HubSpot token {"account_id":59,"updated_at":"2025-10-03 09:32:05","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: Trying to refresh HubSpot token {"account_id":306,"updated_at":"2023-11-27 09:30:03"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":306,"provider":"hubspot","refreshToken":"6fa6aa8cc641d131231acc3470f5c03cb3b07b2e580fb18f8acb3b1dbb72549b","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.ERROR: Failed to refresh HubSpot token {"account_id":306,"updated_at":"2023-11-27 09:30:03","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: Trying to refresh HubSpot token {"account_id":1372,"updated_at":"2025-10-02 14:47:06"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":1372,"provider":"hubspot","refreshToken":"9aa73948c761da29dce46c177cf9aee1fde483a44169ca38723f9f0597d7a8c4","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.ERROR: Failed to refresh HubSpot token {"account_id":1372,"updated_at":"2025-10-02 14:47:06","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.NOTICE: Repairing HubSpot tokens end {"total":3,"fixed":0,"failed":3} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:pre-meeting-reminder","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"2775b4f9-6dce-40a2-84ad-fb7f3a2729ed","trace_id":"89eb011f-145e-44f2-a376-0c57cf42c11d"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"crm:bullhorn:ping","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"1b0300f0-a82f-4bf2-b5dc-24e9d04babab","trace_id":"af7b7ef6-7376-48fe-b7b9-a5ad41237fa4"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"crm:bullhorn:ping","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id...
|
PhpStorm
|
faVsco.js β laravel.log
|
NULL
|
4336
|
|
4335
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Claude is responding
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
how to work with multiple jobs
how to work with paginated requests Let's consider a situation when there are 600 opportunities to sync. What would be the flow? How would the rate limit be recognized? How would it be handled? What are the potential issues? [API usage guidelines and limits - HubSpot docs](
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
). Example of such a error Client error:
POST https://api.hubapi.com/crm/v3/objects/contact/search
resulted in a
429 Too Many Requests
response: {"status":"error","message":"You have reached your secondly limit.","errorType":"RATE_LIMIT","correlationId":"019dffc4-4 (truncated...). Think carefully about the implementation and potential issue and bottlenecks.
Show more
10:42
Edit
Copy
Claude responded: Current HubSpot limits (Apr 2026)
Claude responded: Current HubSpot limits (Apr 2026)
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Current HubSpot limits (Apr 2026)
Current HubSpot limits (Apr 2026)
For privately distributed apps (which is what Jiminny presumably uses with HubSpot), the limits are layered: a per-app burst window of 100/10s on Free/Starter, 190/10s on Pro/Enterprise, or 250/10s with the API Limit Increase add-on
, plus a per-account daily cap of 250k / 625k / 1M depending on tier β shared across all private apps in the account
. The burst window is per app; the daily quota is per portal.
hubspot
hubspot
hubspot
hubspot
The Search API is special: five requests per second per account, capped at 200 records per page, with a hard 10,000-result ceiling per query
. That's the limit the 429 in your example is hitting (
secondly limit
on
/crm/v3/objects/contact/search
). It's a separate bucket from the 190/10s, and critically, search responses do not include the
X-HubSpot-RateLimit-*
headers
β you can't read remaining capacity off the response, you have to track it yourself.
hubspot
hubspot
hubspot
hubspot
Non-search endpoints return
X-HubSpot-RateLimit-Remaining
,
-Max
, and
-Interval-Milliseconds
. The daily headers are not returned for OAuth-authenticated calls
, so for those you check the account-info endpoint or maintain your own counter. There's also a soft rule: errors should stay under 5% of total daily requests
β that's enforced for marketplace listing, but it's also a sane operational target.
hubspot
hubspot
hubspot
hubspot
So you have
four buckets
to track at minimum: app-burst (10s sliding), search-secondly (1s sliding), account-daily (24h fixed, midnight in HubSpot's TZ), and per-app daily share (your own budgeting on top of the account cap).
Where to store it
Where to store it
Redis. It's the only realistic option once you have multiple queue workers β DB-backed counters serialize too much, and in-process state can't coordinate across workers. Laravel already speaks Redis natively, and you get atomic
INCR
/
EXPIRE
plus Lua scripting for true CAS semantics.
Key layout I'd use:
Copy to clipboard
hubspot:rl:burst:{portalId}:{appId} ZSET (sliding 10s)
hubspot:rl:search:{portalId} ZSET (sliding 1s)
hubspot:rl:daily:{portalId} STRING + TTL to midnight TZ
hubspot:rl:meta:{portalId} HASH (last seen headers)
The two short-window buckets are sliding-window-log (Redis ZSET, score =
microtime
, member = unique request id). Lua script removes entries older than the window, counts remaining slots, and only adds the new one if there's room β all atomic. Fixed windows are simpler but allow 2Γ the limit at the boundary, which on a 5/s window is brutal.
The daily bucket is a plain
INCR
with TTL set to seconds-until-midnight in
HubSpot's account timezone
, not yours β Sofia is UTC+2/+3 but your portal might be set to US Eastern. Get this once and cache it.
How to read it
How to read it
Two-phase: optimistic pre-check, authoritative post-update.
Before a call, run the Lua acquire script. If it returns "denied," sleep until a slot frees up (the script can return ms-until-next-slot) or push the job back to the queue with a delay. Don't busy-loop.
After the call, parse
X-HubSpot-RateLimit-Remaining
/
-Max
/
-Interval-Milliseconds
and store them in
hubspot:rl:meta:{portalId}
. This is your reality check β if your local counter says 50 remaining but HubSpot's header says 5, you trust HubSpot and clamp your counter. This handles clock drift, missed accounting (e.g., crashed worker that took a token but never made the request), and other apps in the same account consuming the daily budget invisibly.
For search specifically, since headers don't come back, the local counter
is
the source of truth β meaning if you ever crash mid-flight, you've under-counted. Always release tokens on connection-level failure but
not
on 429 (you really did make that request).
How to work with multiple jobs
How to work with multiple jobs
The queue layer needs to enforce concurrency separately from the rate limiter. Both work together:
Concurrency cap
via
Queue::throttle()
or a Redis semaphore β limits how many sync workers run in parallel against HubSpot. Without this, you can have 50 workers all blocked waiting for tokens, which is wasteful and creates retry storms.
Per-tenant fairness
β if you sync many Jiminny customers into different HubSpot portals, each portal has its own bucket but you still want one slow portal not to starve others. Either separate queues per portal or a fair-share scheduler.
Priority lanes
β webhook-driven updates (user-visible latency) should outrank background batch syncs. Two queues:
hubspot-priority
and
hubspot-bulk
, with priority workers taking 70% of the burst budget and bulk taking 30% (enforce via separate sub-buckets if you really want hard separation, otherwise just pull from priority first).
Backoff on 429
β respect the
Retry-After
header. If absent, exponential with jitter (e.g.,
min(2^attempt * 250ms, 30s) Β± 20%
). The jitter is non-negotiable; without it, simultaneous 429s retry in lockstep and you get thundering-herd 429s on retry.
How to work with paginated requests
How to work with paginated requests
The trap is treating "fetch all" as one logical operation. Each page is its own API call and competes for tokens with everything else.
Two practical rules:
Don't hold the worker idle while paginating.
If page N takes 500ms and page N+1 needs to wait 800ms for a token, you've burned 800ms of worker time doing nothing. Instead, fetch page N, dispatch the
processing
of page N as a separate job, and queue a "fetch page N+1" job with a delay equal to the wait time. Each page becomes its own atomic unit.
Always batch where HubSpot offers it.
POST /crm/v3/objects/{type}/batch/{read|update|create}
accepts up to 100 IDs per call. For your "patching IDs" flow this is the difference between 600 calls and 6.
Walkthrough: 600 opportunities
Walkthrough: 600 opportunities
Naive flow (one PATCH per deal): 600 calls. At 190/10s that's ~32s of API time, well under daily. You'd hit burst easily without throttling. Plus likely 1-3 search calls upfront and N association calls.
Sane flow:
Identify deltas
β if you can avoid Search at all, do. Use
lastmodifieddate
filter on a single search if you must, paginate at limit=200. For 600 deals that's 3 search calls @ 5/s = ~600ms naturally throttled.
Batch read
current state β
POST /crm/v3/objects/deals/batch/read
with 100 IDs per call β 6 calls. Burst weight 6.
Compute diff
in your code (no API).
Batch update
β
POST /crm/v3/objects/deals/batch/update
with 100 per call β 6 calls.
Associations
β
POST /crm/v4/associations/{from}/{to}/batch/create
if needed β another few batch calls.
Total: ~15-20 API calls for 600 deals. Burst budget consumed: 20/190 over ~5s. Daily impact: trivial.
Recognition: pre-check denies if
<weight>
slots aren't free; on 429 the response surfaces
policyName
(DAILY/SECONDLY) β log it, push the job back with
Retry-After
delay, increment a metric so you can alarm on sustained 429 rate.
Pitfalls & bottlenecks worth pre-empting
Pitfalls & bottlenecks worth pre-empting
Daily quota is shared across the whole portal
, including any n8n flows, other private apps, marketing automation calling APIs, etc. Budget for ~70-80% of the documented limit, not 100%. Add an internal per-app daily cap so a runaway sync can't starve other apps.
Search is uniquely fragile
: separate 5/s bucket, no headers to read, 10k-result cap per query. If you ever hit 10k+ deals matching a filter, partition by
hs_object_id
ranges or by
lastmodifieddate
windows.
Retry storms after HubSpot incidents
β always jitter, always cap total retries (e.g., 5 attempts, then dead-letter).
Webhook β sync β webhook loops
β when your update fires a HubSpot webhook that triggers another sync. Tag your own writes (e.g., a custom property
jy_last_sync_id
) and ignore webhooks where it just changed.
Token refresh
β OAuth refresh itself counts against burst. Cache the access token in Redis with TTL =
expires_in - 60s
, single-flight the refresh (only one worker refreshes; others wait on a lock).
Search latency for fresh writes
β newly created/updated objects don't appear in search instantly. Don't write-then-search; use returned IDs directly.
Clock skew
β Redis is authoritative. Don't use
time()
from each worker for window scoring; use
redis.call('TIME')
inside the Lua script.
Dead workers with held tokens
β sliding-window-log handles this naturally because tokens expire by score; token-bucket implementations need explicit release-on-crash logic.
The 5% error rule
counts every 429 toward your error budget, even successfully retried ones. If your pre-check is working well, 429s should be near zero β if they're not, your pre-check is wrong, not just slow.
Phantom contention with Laravel
RateLimited
middleware
: it's per-job-class by default, not per-portal. If your
SyncDealJob
and
UpdateActivityJob
are different classes both calling HubSpot, they don't share a Laravel-level limiter β you need a single
HubspotRateLimiter
service that everything routes through.
If you want, I can sketch the Lua script for the sliding-window acquire and the Laravel service wrapper around it.
Copy
Give positive feedback
Give negative feedback
You said: What will happen if there are two different types of rate limits?
You said: What will happen if there are two different types of rate limits?
What will happen if there are two different types of rate limits?
Search requests that have 5 requests per second
The other rate limit that has, let's say, 100 requests per 10 seconds How do these work together? Is there some conflict? Can I reach the limit with one request and block either as well, or are these separated? Can I still continue making search requests once I hit the normal requests limits?
13:40
Edit
Copy
Claude responded: They're independent buckets β with one shared bucket on top.
Claude responded: They're independent buckets β with one shared bucket on top.
Analyzed independent rate limit buckets and their practical interactions
Analyzed independent rate limit buckets and their practical interactions
They're independent buckets β with one shared bucket on top.
The three buckets and what each call hits
The three buckets and what each call hits
Copy to clipboard
ββββββββββββββββββββ
Search request βββ β Search: 5/sec β βββ
ββββββββββββββββββββ β
ββββ βββββββββββββββββββ
ββββββββββββββββββββ β β Daily: 250kβ1M β
Non-search call βββ β Burst: 190/10s β βββ β (per portal) β
ββββββββββββββββββββ βββββββββββββββββββ
A search call is only metered against the search bucket and the daily bucket. A non-search call (batch read/update, single PATCH, associations, etc.) is only metered against the burst bucket and the daily bucket. The two short-window buckets do not share counters.
What this means practically
What this means practically
Hitting search secondly limit (5/s):
Only further
/search
calls 429. Your batch reads, batch updates, single PATCHes, association calls β all keep working at full burst speed. This is actually useful: if your sync is bottlenecked on Search, you can pivot to using
lastmodifieddate
filters via batch endpoints, or use the IDs you already have to do batch reads, while Search cools off.
Hitting burst limit (190/10s):
Only non-search calls 429. You can still issue Search calls at 5/s. Useful for: continuing to identify deltas for queueing while in-flight updates drain, or refreshing a small set of records via Search even though your write pipeline is paused.
Hitting daily limit:
Everything stops. Search and non-search alike. Doesn't unblock until midnight in your portal's configured timezone β and remember this is shared across every private app in the portal, plus n8n flows, marketing tools, anything else hitting the API with that account.
So can one type of request block the other?
So can one type of request block the other?
Search β Burst:
No.
Saturating Search at 50 calls per 10s leaves your full 190/10s burst untouched.
Burst β Search:
No.
Saturating burst leaves Search's 5/s untouched.
Either β Daily:
Yes
, but only by contributing to the same daily counter. It's volume that kills you here, not the type.
In theory you can sustain ~50 search + ~190 other =
~240 calls per 10 seconds
indefinitely (until daily runs out), because the two buckets bill independently.
Implementation consequence
Implementation consequence
Your rate limiter needs to know which bucket a request hits before it acquires. Cleanest pattern:
Copy to clipboard
php
$limiter
->
acquire
(
'search'
,
$weight
=
1
)
;
// for search endpoints only
$limiter
->
acquire
(
'burst'
,
$weight
=
1
)
;
// for everything else
$limiter
->
acquire
(
'daily'
,
$weight
=
1
)
;
// every call, both kinds
In Redis: three separate keys, three separate Lua acquire scripts (or one script with a bucket parameter). A search call calls
acquire('search')
+
acquire('daily')
. A batch update calls
acquire('burst')
+
acquire('daily')
.
One subtle pitfall: when you backoff on a 429,
inspect
policyName
in the response body
to know which bucket actually fired. If you see
SECONDLY
from a search endpoint, you only need to delay search-bound jobs β burst-bound jobs in the queue can keep running. If you blanket-pause everything on any 429, you waste capacity on the bucket that's still healthy. Two queues (or two throttle keys) make this clean; one global pause is the lazy version.
The other subtlety: the burst response gives you
X-HubSpot-RateLimit-Remaining
to clamp local state against, but search doesn't return those headers. So your search counter is unverified β be slightly more conservative there (e.g., budget 4/s instead of 5) to absorb the unaccounted-for calls.
Copy
Give positive feedback
Give negative feedback
You said: Ok, so what will happen each time I make a request?
You said: Ok, so what will happen each time I make a request?
Ok, so what will happen each time I make a request? Let's say I have 100,000 requests to make that are instant. Do I need to increment each request based on the type? For example, if there is a search request, I need to increment both the search bucket and also the daily bucket. If it's a burst, then I can go to the daily and burst buckets. If I need to check if it can make a call, do I need to see both the daily and search, or burst, respectively? Isn't that too heavy for the infrastructure, adding additional load to each request?
13:44
Edit
Copy
Claude responded: Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out.
Claude responded: Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out.
Analyzed per-request overhead concerns and quantified Redis performance impact
Analyzed per-request overhead concerns and quantified Redis performance impact
Yes, your understanding is correct β every request must check and reserve from each bucket it applies to, atomically, before the call goes out. But the overhead is much smaller than it sounds, and importantly, it's nowhere near your bottleneck.
What "two buckets per request" actually costs
What "two buckets per request" actually costs
Each request makes
one round trip to Redis
β not two β because you fold both bucket checks into a single Lua script that runs atomically server-side:
Copy to clipboard
lua
-- KEYS[1] = burst bucket key (or search)
-- KEYS[2] = daily bucket key
-- ARGV[1] = now (ms) ARGV[2] = window_ms
-- ARGV[3] = bucket_max ARGV[4] = daily_max
-- ARGV[5] = request_id ARGV[6] = daily_ttl
-- Trim sliding window
redis
.
call
(
'ZREMRANGEBYSCORE'
,
KEYS
[
1
]
,
0
,
ARGV
[
1
]
-
ARGV
[
2
]
)
local
burst_used
=
redis
.
call
(
'ZCARD'
,
KEYS
[
1
]
)
local
daily_used
=
tonumber
(
redis
.
call
(
'GET'
,
KEYS
[
2
]
)
or
'0'
)
if
burst_used
>=
tonumber
(
ARGV
[
3
]
)
then
-- Tell caller how long to sleep until oldest entry expires
local
oldest
=
redis
.
call
(
'ZRANGE'
,
KEYS
[
1
]
,
0
,
0
,
'WITHSCORES'
)
return
{...
|
Claude
|
Claude
|
NULL
|
4335
|
|
4334
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Share chat
Claude finished the response
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
how to work with multiple jobs
how to work with paginated requests Let's consider a situation when there are 600 opportunities to sync. What would be the flow? How would the rate limit be recognized? How would it be handled? What are the potential issues? [API usage guidelines and limits - HubSpot docs](
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
). Example of such a error Client error:
POST https://api.hubapi.com/crm/v3/objects/contact/search
resulted in a
429 Too Many Requests
response: {"status":"error","message":"You have reached your secondly limit.","errorType":"RATE_LIMIT","correlationId":"019dffc4-4 (truncated...). Think carefully about the implementation and potential issue and bottlenecks.
Show more
10:42
Retry
Edit
Copy
Claude responded: Current HubSpot limits (Apr 2026)
Claude responded: Current HubSpot limits (Apr 2026)
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Current HubSpot limits (Apr 2026)
Current HubSpot limits (Apr 2026)
For privately distributed apps (which is what Jiminny presumably uses with HubSpot), the limits are layered: a per-app burst window of 100/10s on Free/Starter, 190/10s on Pro/Enterprise, or 250/10s with the API Limit Increase add-on
, plus a per-account daily cap of 250k / 625k / 1M depending on tier β shared across all private apps in the account
. The burst window is per app; the daily quota is per portal.
hubspot
hubspot
hubspot
hubspot
The Search API is special: five requests per second per account, capped at 200 records per page, with a hard 10,000-result ceiling per query
. That's the limit the 429 in your example is hitting (
secondly limit
on
/crm/v3/objects/contact/search
). It's a separate bucket from the 190/10s, and critically, search responses do not include the
X-HubSpot-RateLimit-*
headers
β you can't read remaining capacity off the response, you have to track it yourself.
hubspot
hubspot
hubspot
hubspot
Non-search endpoints return
X-HubSpot-RateLimit-Remaining
,
-Max
, and
-Interval-Milliseconds
. The daily headers are not returned for OAuth-authenticated calls
, so for those you check the account-info endpoint or maintain your own counter. There's also a soft rule: errors should stay under 5% of total daily requests
β that's enforced for marketplace listing, but it's also a sane operational target.
hubspot
hubspot
hubspot
hubspot
So you have
four buckets
to track at minimum: app-burst (10s sliding), search-secondly (1s sliding), account-daily (24h fixed, midnight in HubSpot's TZ), and per-app daily share (your own budgeting on top of the account cap).
Where to store it
Where to store it
Redis. It's the only realistic option once you have multiple queue workers β DB-backed counters serialize too much, and in-process state can't coordinate across workers. Laravel already speaks Redis natively, and you get atomic
INCR
/
EXPIRE
plus Lua scripting for true CAS semantics.
Key layout I'd use:
Copy to clipboard
hubspot:rl:burst:{portalId}:{appId} ZSET (sliding 10s)
hubspot:rl:search:{portalId} ZSET (sliding 1s)
hubspot:rl:daily:{portalId} STRING + TTL to midnight TZ
hubspot:rl:meta:{portalId} HASH (last seen headers)
The two short-window buckets are sliding-window-log (Redis ZSET, score =
microtime
, member = unique request id). Lua script removes entries older than the window, counts remaining slots, and only adds the new one if there's room β all atomic. Fixed windows are simpler but allow 2Γ the limit at the boundary, which on a 5/s window is brutal.
The daily bucket is a plain
INCR
with TTL set to seconds-until-midnight in
HubSpot's account timezone
, not yours β Sofia is UTC+2/+3 but your portal might be set to US Eastern. Get this once and cache it.
How to read it
How to read it
Two-phase: optimistic pre-check, authoritative post-update.
Before a call, run the Lua acquire script. If it returns "denied," sleep until a slot frees up (the script can return ms-until-next-slot) or push the job back to the queue with a delay. Don't busy-loop.
After the call, parse
X-HubSpot-RateLimit-Remaining
/
-Max
/
-Interval-Milliseconds
and store them in
hubspot:rl:meta:{portalId}
. This is your reality check β if your local counter says 50 remaining but HubSpot's header says 5, you trust HubSpot and clamp your counter. This handles clock drift, missed accounting (e.g., crashed worker that took a token but never made the request), and other apps in the same account consuming the daily budget invisibly.
For search specifically, since headers don't come back, the local counter
is
the source of truth β meaning if you ever crash mid-flight, you've under-counted. Always release tokens on connection-level failure but
not
on 429 (you really did make that request).
How to work with multiple jobs
How to work with multiple jobs
The queue layer needs to enforce concurrency separately from the rate limiter. Both work together:
Concurrency cap
via
Queue::throttle()
or a Redis semaphore β limits how many sync workers run in parallel against HubSpot. Without this, you can have 50 workers all blocked waiting for tokens, which is wasteful and creates retry storms.
Per-tenant fairness
β if you sync many Jiminny customers into different HubSpot portals, each portal has its own bucket but you still want one slow portal not to starve others. Either separate queues per portal or a fair-share scheduler.
Priority lanes
β webhook-driven updates (user-visible latency) should outrank background batch syncs. Two queues:
hubspot-priority
and
hubspot-bulk
, with priority workers taking 70% of the burst budget and bulk taking 30% (enforce via separate sub-buckets if you really want hard separation, otherwise just pull from priority first).
Backoff on 429
β respect the
Retry-After
header. If absent, exponential with jitter (e.g.,
min(2^attempt * 250ms, 30s) Β± 20%
). The jitter is non-negotiable; without it, simultaneous 429s retry in lockstep and you get thundering-herd 429s on retry.
How to work with paginated requests
How to work with paginated requests
The trap is treating "fetch all" as one logical operation. Each page is its own API call and competes for tokens with everything else.
Two practical rules:
Don't hold the worker idle while paginating.
If page N takes 500ms and page N+1 needs to wait 800ms for a token, you've burned 800ms of worker time doing nothing. Instead, fetch page N, dispatch the
processing
of page N as a separate job, and queue a "fetch page N+1" job with a delay equal to the wait time. Each page becomes its own atomic unit.
Always batch where HubSpot offers it.
POST /crm/v3/objects/{type}/batch/{read|update|create}
accepts up to 100 IDs per call. For your "patching IDs" flow this is the difference between 600 calls and 6.
Walkthrough: 600 opportunities
Walkthrough: 600 opportunities
Naive flow (one PATCH per deal): 600 calls. At 190/10s that's ~32s of API time, well under daily. You'd hit burst easily without throttling. Plus likely 1-3 search calls upfront and N association calls.
Sane flow:
Identify deltas
β if you can avoid Search at all, do. Use
lastmodifieddate
filter on a single search if you must, paginate at limit=200. For 600 deals that's 3 search calls @ 5/s = ~600ms naturally throttled.
Batch read
current state β
POST /crm/v3/objects/deals/batch/read
with 100 IDs per call β 6 calls. Burst weight 6.
Compute diff
in your code (no API).
Batch update
β
POST /crm/v3/objects/deals/batch/update
with 100 per call β 6 calls.
Associations
β...
|
Claude
|
Claude
|
NULL
|
4334
|
|
4333
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Share chat
Claude finished the response
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
how to work with multiple jobs
how to work with paginated requests Let's consider a situation when there are 600 opportunities to sync. What would be the flow? How would the rate limit be recognized? How would it be handled? What are the potential issues? [API usage guidelines and limits - HubSpot docs](
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
). Example of such a error Client error:
POST https://api.hubapi.com/crm/v3/objects/contact/search
resulted in a
429 Too Many Requests
response: {"status":"error","message":"You have reached your secondly limit.","errorType":"RATE_LIMIT","correlationId":"019dffc4-4 (truncated...). Think carefully about the implementation and potential issue and bottlenecks.
Show more
10:42
Retry
Edit
Copy
Claude responded: Current HubSpot limits (Apr 2026)
Claude responded: Current HubSpot limits (Apr 2026)
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Synthesized HubSpot rate limit architecture with Redis storage and sliding window algorithms
Current HubSpot limits (Apr 2026)
Current HubSpot limits (Apr 2026)
For privately distributed apps (which is what Jiminny presumably uses with HubSpot), the limits are layered: a per-app burst window of 100/10s on Free/Starter, 190/10s on Pro/Enterprise, or 250/10s with the API Limit Increase add-on
, plus a per-account daily cap of 250k / 625k / 1M depending on tier β shared across all private apps in the account
. The burst window is per app; the daily quota is per portal.
hubspot
hubspot
hubspot
hubspot
The Search API is special: five requests per second per account, capped at 200 records per page, with a hard 10,000-result ceiling per query
. That's the limit the 429 in your example is hitting (
secondly limit
on
/crm/v3/objects/contact/search
). It's a separate bucket from the 190/10s, and critically, search responses do not include the
X-HubSpot-RateLimit-*
headers
β you can't read remaining capacity off the response, you have to track it yourself.
hubspot
hubspot
hubspot
hubspot
Non-search endpoints return
X-HubSpot-RateLimit-Remaining
,
-Max
, and
-Interval-Milliseconds
. The daily headers are not returned for OAuth-authenticated calls
, so for those you check the account-info endpoint or maintain your own counter. There's also a soft rule: errors should stay under 5% of total daily requests
β that's enforced for marketplace listing, but it's also a sane operational target.
hubspot
hubspot
hubspot
hubspot
So you have
four buckets
to track at minimum: app-burst (10s sliding), search-secondly (1s sliding), account-daily (24h fixed, midnight in HubSpot's TZ), and per-app daily share (your own budgeting on top of the account cap).
Where to store it
Where to store it
Redis. It's the only realistic option once you have multiple queue workers β DB-backed counters serialize too much, and in-process state can't coordinate across workers. Laravel already speaks Redis natively, and you get atomic
INCR
/
EXPIRE
plus Lua scripting for true CAS semantics.
Key layout I'd use:
Copy to clipboard
hubspot:rl:burst:{portalId}:{appId} ZSET (sliding 10s)
hubspot:rl:search:{portalId} ZSET (sliding 1s)
hubspot:rl:daily:{portalId} STRING + TTL to midnight TZ
hubspot:rl:meta:{portalId} HASH (last seen headers)
The two short-window buckets are sliding-window-log (Redis ZSET, score =
microtime
, member = unique request id). Lua script removes entries older than the window, counts remaining slots, and only adds the new one if there's room β all atomic. Fixed windows are simpler but allow 2Γ the limit at the boundary, which on a 5/s window is brutal.
The daily bucket is a plain
INCR
with TTL set to seconds-until-midnight in
HubSpot's account timezone
, not yours β Sofia is UTC+2/+3 but your portal might be set to US Eastern. Get this once and cache it.
How to read it
How to read it
Two-phase: optimistic pre-check, authoritative post-update.
Before a call, run the Lua acquire script. If it returns "denied," sleep until a slot frees up (the script can return ms-until-next-slot) or push the job back to the queue with a delay. Don't busy-loop.
After the call, parse
X-HubSpot-RateLimit-Remaining
/
-Max
/
-Interval-Milliseconds
and store them in
hubspot:rl:meta:{portalId}
. This is your reality check β if your local counter says 50 remaining but HubSpot's header says 5, you trust HubSpot and clamp your counter. This handles clock drift, missed accounting (e.g., crashed worker that took a token but never made the request), and other apps in the same account consuming the daily budget invisibly.
For search specifically, since headers don't come back, the local counter
is
the source of truth β meaning if you ever crash mid-flight, you've under-counted. Always release tokens on connection-level failure but
not
on 429 (you really did make that request).
How to work with multiple jobs
How to work with multiple jobs
The queue layer needs to enforce concurrency separately from the rate limiter. Both work together:
Concurrency cap
via
Queue::throttle()
or a Redis semaphore β limits how many sync workers run in parallel against HubSpot. Without this, you can have 50 workers all blocked waiting for tokens, which is wasteful and creates retry storms.
Per-tenant fairness
β if you sync many Jiminny customers into different HubSpot portals, each portal has its own bucket but you still want one slow portal not to starve others. Either separate queues per portal or a fair-share scheduler.
Priority lanes
β webhook-driven updates (user-visible latency) should outrank background batch syncs. Two queues:
hubspot-priority
and
hubspot-bulk
, with priority workers taking 70% of the burst budget and bulk taking 30% (enforce via separate sub-buckets if you really want hard separation, otherwise just pull from priority first).
Backoff on 429
β respect the
Retry-After
header. If absent, exponential with jitter (e.g.,
min(2^attempt * 250ms, 30s) Β± 20%
). The jitter is non-negotiable; without it, simultaneous 429s retry in lockstep and you get thundering-herd 429s on retry.
How to work with paginated requests
How to work with paginated requests
The trap is treating "fetch all" as one logical operation. Each page is its own API call and competes for tokens with everything else.
Two practical rules:
Don't hold the worker idle while paginating.
If page N takes 500ms and page N+1 needs to wait 800ms for a token, you've burned 800ms of worker time doing nothing. Instead, fetch page N, dispatch the
processing
of page N as a separate job, and queue a "fetch page N+1" job with a delay equal to the wait time. Each page becomes its own atomic unit.
Always batch where HubSpot offers it.
POST /crm/v3/objects/{type}/batch/{read|update|create}
accepts up to 100 IDs per call. For your "patching IDs" flow this is the difference between 600 calls and 6.
Walkthrough: 600 opportunities
Walkthrough: 600 opportunities
Naive flow (one PATCH per deal): 600 calls. At 190/10s that's ~32s of API time, well under daily. You'd hit burst easily without throttling. Plus likely 1-3 search calls upfront and N association calls.
Sane flow:
Identify deltas
β if you can avoid Search at all, do. Use
lastmodifieddate
filter on a single search if you must, paginate at limit=200. For 600 deals that's 3 search calls @ 5/s = ~600ms naturally throttled.
Batch read
current state β
POST /crm/v3/objects/deals/batch/read
with 100 IDs per call β 6 calls. Burst weight 6.
Compute diff
in your code (no API).
Batch update
β
POST /crm/v3/objects/deals/batch/update
with 100 per call β 6 calls.
Associations
β
POST /crm/v4/associations/{from}/{to}/batch/create
if needed β another few batch calls.
Total: ~15-20 API calls for 600 deals. Burst budget consumed: 20/190 over ~5s. Daily impact: trivial.
Recognition: pre-check denies if
<weight>
slots aren't free; on 429 the response surfaces
policyName
(DAILY/SECONDLY) β log it, push the job back with
Retry-After
delay, increment a metric so you can alarm on sustained 429 rate.
Pitfalls & bottlenecks worth pre-empting
Pitfalls & bottlenecks worth pre-empting
Daily quota is shared across the whole portal
, including any n8n flows, other private apps, marketing automation calling APIs, etc. Budget for ~70-80% of the documented limit, not 100%. Add an internal per-app daily cap so a runaway sync can't starve other apps.
Search is uniquely fragile
: separate 5/s bucket, no headers to read, 10k-result cap per query. If you ever hit 10k+ deals matching a filter, partition by
hs_object_id
ranges or by
lastmodifieddate
windows.
Retry storms after HubSpot incidents
β always jitter, always cap total retries (e.g., 5 attempts, then dead-letter).
Webhook β sync β webhook loops
β when your update fires a HubSpot webhook that triggers another sync. Tag your own writes (e.g., a custom property
jy_last_sync_id
) and ignore webhooks where it just changed.
Token refresh
β OAuth refresh itself counts against burst. Cache the access token in Redis with TTL =
expires_in - 60s
, single-flight the refresh (only one worker refreshes; others wait on a lock).
Search latency for fresh writes
β newly created/updated objects don't appear in search instantly. Don't write-then-search; use returned IDs directly.
Clock skew
β Redis is authoritative. Don't use
time()
from each worker for window scoring; use
redis.call('TIME')
inside the Lua script.
Dead workers with held tokens
β sliding-window-log handles this naturally because tokens expire by score; token-bucket implementations need explicit release-on-crash logic.
The 5% error rule
counts every 429 toward your error budget, even successfully retried ones. If your pre-check is working well, 429s should be near zero β if they're not, your pre-check is wrong, not just slow.
Phantom contention with Laravel
RateLimited
middleware
: it's per-job-class by default, not per-portal. If your
SyncDealJob
and
UpdateActivityJob
are different classes both calling HubSpot, they don't share a Laravel-level limiter β you need a single
HubspotRateLimiter
service that everything routes through.
If you want, I can sketch the Lua script for the sliding-window acquire and the Laravel service wrapper around it.
Copy
Give positive feedback
Give negative feedback
Retry
You said: What will happen if there are two different types of rate limits?
You said: What will happen if there are two different types of rate limits?
What will happen if there are two different types of rate limits?
Search requests that have 5 requests per second
The other rate limit that has, let's say, 100 requests per 10 seconds How do these work together? Is there some conflict? Can I reach the limit with one request and block either as well, or are these separated? Can I still continue making search requests once I hit the normal requests limits?
13:40
Retry
Edit
Copy
Claude responded: They're independent buckets β with one shared bucket on top.
Claude responded: They're independent buckets β with one shared bucket on top.
Analyzed independent rate limit buckets and their practical interactions
Analyzed independent rate limit buckets and their practical interactions
They're independent buckets β with one shared bucket on top....
|
Claude
|
Claude
|
NULL
|
4333
|
|
4332
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Share chat
Claude finished the response
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
iTerm2ShellEditViewSessionScriptsProfilesWindowHelplablβ’ Lukas/Stefka 121 β’ in 1h 3 m100% [8Thu 7 May 16:27:34DEV (docker)APP (-zsh)*3181DOCKERO β΄1DEV (docker)182worker-crm-sync:worker-crm-sync_00: startedworker-crm-update:worker-crm-update_00: startedworker-download:worker-download_00: startedworker-emails:worker-emails_00: startedworker-es-update:worker-es-update_00: startedworker-nudges:worker-nudges_00: startedroot@docker_lamp_1:/home/jiminny# php artisan jiminny:debugMatching contact 0Matching contact 1Matching contact 2Matching contactMatching contact4MatchingcontactMatchingcontact 6Matching contact 7Matching contact 8Matching contact 9root@docker_lamp_1:/home/jiminny# php artisan jiminny:debugMatching contact 0Jiminny Exceptions\RateLimitException$I-zshβ’ 84|screenpipe*-zshβ΄6DEVhhlHubspot returned 429at app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php:206202'retry_after'=>SretryAfter,203"reason'204= Se->getMessage(),205β 206throw new RateLimitException('Hubspot returned 429', SretryAfter, $e);207208} else 1throw $e;209}210}+14 vendor frames15app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php:166SevenShores\Hubspot\Http\Client::request("POST", "[URL_WITH_CREDENTIALS] 0...
|
Claude
|
Claude
|
NULL
|
4332
|
|
4331
|
Skip to content
Skip to content
Click to collapse
Skip to content
Skip to content
Click to collapse
βB
Drag to resize
Open sidebar
Chat
Cowork
Code
New chat βN
New chat
βN
Projects
Artifacts
Customize
Pinned
Bulgarian citizenship application process for EU residents
More options for Bulgarian citizenship application process for EU residents
Dawarich location tracking project
More options for Dawarich location tracking project
Recents
View all
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Screenpipe retention policy code location
More options for Screenpipe retention policy code location
Viewing retention policy in screenpipe
More options for Viewing retention policy in screenpipe
Clean shot x video recording termination issue
More options for Clean shot x video recording termination issue
HubSpot rate limit handling with executeRequest
More options for HubSpot rate limit handling with executeRequest
Untitled
More options
π¬ Screen pipe. Is there abilityβ¦
More options for π¬ Screen pipe. Is there abilityβ¦
SMB mount access inconsistency between Finder and iTerm
More options for SMB mount access inconsistency between Finder and iTerm
π¬ What is the best switch I canβ¦
More options for π¬ What is the best switch I canβ¦
Permission denied on screenpipe volume
More options for Permission denied on screenpipe volume
Screenpipe sync database attachment error
More options for Screenpipe sync database attachment error
Last swimming outing with Dani
More options for Last swimming outing with Dani
Definition of incarcerated
More options for Definition of incarcerated
Chromecast remote volume buttons not working
More options for Chromecast remote volume buttons not working
Salesforce API errors with Organization and FieldDefinition queries
More options for Salesforce API errors with Organization and FieldDefinition queries
Daily activity summary from screenpipe data
More options for Daily activity summary from screenpipe data
MacBook unexpected restarts and kanji screen
More options for MacBook unexpected restarts and kanji screen
Security patch review and testing guidance
More options for Security patch review and testing guidance
Food calorie values reference
More options for Food calorie values reference
Tracking location history from last week
More options for Tracking location history from last week
Lukas Pro
Get apps and extensions
HubSpot rate limit implementation strategy, rename chat
HubSpot rate limit implementation strategy
More options for HubSpot rate limit implementation strategy
Close
Share chat
Claude finished the response
You said: So just a solution for rate limit implementation.
You said: So just a solution for rate limit implementation.
So just a solution for rate limit implementation. The situation currently is that there are some daily and secondary limits for HubSpot. I would like to make sure I never reach a 429 error rate limit. The requests can come from any flow. It can be:
updating activity (engagement, meeting, call, note)
searching for a company or contact
updating deal
patching IDs
Review what the limit is at the moment in the HubSpot documentation and then think of the solution:
where to store it
how to read it
how to work with multiple jobs
how to work with paginated requests Let's consider a situation when there are 600 opportunities to sync. What would be the flow? How would the rate limit be recognized? How would it be handled? What are the potential issues? [API usage guidelines and limits - HubSpot docs](
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines
). Example of such a error Client error:
POST https://api.hubapi.com/crm/v3/objects/contact/search
resulted in a
429 Too Many Requests...
|
Claude
|
Claude
|
NULL
|
4331
|
|
4330
|
Project: faVsco.js, menu
master, menu
Start Listen Project: faVsco.js, menu
master, menu
Start Listening for PHP Debug Connections
AskJiminnyReportActivityServiceTest
Run 'AskJiminnyReportActivityServiceTest'
Debug 'AskJiminnyReportActivityServiceTest'
More Actions
JetBrains AI
Search Everywhere
IDE and Project Settings
Sync Changes
Hide This Notification
Code changed:
Hide
286
Previous Highlighted Error
Next Highlighted Error
iTerm2ShellEditViewSessionScriptsProfilesWindowHelplablβ’ Lukas/Stefka 121 β’ in 1h 3 m100% <478Thu 7 May 16:27:30DEV (docker)APP (-zsh)*3T81DOCKERO β΄1DEV (docker)182worker-crm-sync:worker-crm-sync_00: startedworker-crm-update:worker-crm-update_00: startedworker-download:worker-download_00: startedworker-emails:worker-emails_00: startedworker-es-update:worker-es-update_00: startedworker-nudges:worker-nudges_00: startedroot@docker_lamp_1:/home/jiminny# php artisan jiminny:debugMatching contact 0Matching contact 1Matching contact 2Matching contactMatchingcontact4Matchingcontact5Matchingcontact 6Matching contact 7Matching contact 8Matching contact 9root@docker_lamp_1:/home/jiminny# php artisan jiminny:debugMatching contact 0-zshβ’ 84|screenpipe*β’$5Jiminny \Exceptions \RateLimitExceptionHubspot returned 429at app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php:206202'retry_after' =SretryAfter,203"reason"204= Se->getMessage(),205β 206throw new RateLimitException('Hubspot returned 429', SretryAfter, $e);207208} else 1throw $e;209}210+14 vendor frames15-zshβ΄6DEVapp/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php:166SevenShores\Hubspot\Http\Client:: request("POST", "[URL_WITH_CREDENTIALS] ]...
|
PhpStorm
|
faVsco.js β laravel.log
|
NULL
|
4330
|
|
4329
|
Project: faVsco.js, menu
master, menu
Start Listen Project: faVsco.js, menu
master, menu
Start Listening for PHP Debug Connections
AskJiminnyReportActivityServiceTest
Run 'AskJiminnyReportActivityServiceTest'
Debug 'AskJiminnyReportActivityServiceTest'
More Actions
JetBrains AI
Search Everywhere
IDE and Project Settings
Sync Changes
Hide This Notification
Code changed:
Hide
286
Previous Highlighted Error
Next Highlighted Error
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Fetching token {"socialAccountId":1499,"provider":"hubspot"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Token needs refreshing {"socialAccountId":1499,"provider":"hubspot"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":1499,"provider":"hubspot","refreshToken":"96f94c623a404e02ebdbf07f1b75707bb6cdbf848cbf45d418baf608c41a8d86","state":"connected"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountObserver] Saving model {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountObserver] Access token was modified, encrypting {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [SocialAccountService] Token refreshed {"socialAccountId":1499,"provider":"hubspot","state":"connected"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [CrmOwnerResolver] Integration owner matched as CRM Owner {"crm_provider":"hubspot","crm_owner":148,"team_id":2} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [Hubspot] Received 429 from API {"team_id":2,"config_id":2,"retry_after":10,"reason":"Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.ERROR: Hubspot returned 429 {"exception":"[object] (Jiminny\\Exceptions\\RateLimitException(code: 0): Hubspot returned 429 at /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php:206)
[stacktrace]
#0 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#1 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#2 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#3 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#4 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#5 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#6 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#7 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#8 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#9 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#10 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#11 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#12 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#13 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#14 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#15 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#16 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#17 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#18 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#19 {main}
[previous exception] [object] (SevenShores\\Hubspot\\Exceptions\\BadRequest(code: 429): Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
at /home/jiminny/vendor/hubspot/hubspot-php/src/Exceptions/HubspotException.php:24)
[stacktrace]
#0 /home/jiminny/vendor/hubspot/hubspot-php/src/Http/Client.php(125): SevenShores\\Hubspot\\Exceptions\\HubspotException::create(Object(GuzzleHttp\\Exception\\ClientException))
#1 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(166): SevenShores\\Hubspot\\Http\\Client->request('POST', 'https://api.hub...', Array)
#2 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#3 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#4 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#5 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#6 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#7 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#8 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#9 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#10 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#11 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#12 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#13 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#14 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#15 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#16 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#17 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#18 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#19 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#20 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#21 {main}
[previous exception] [object] (GuzzleHttp\\Exception\\ClientException(code: 429): Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
at /home/jiminny/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:111)
[stacktrace]
#0 /home/jiminny/vendor/guzzlehttp/guzzle/src/Middleware.php(72): GuzzleHttp\\Exception\\RequestException::create(Object(GuzzleHttp\\Psr7\\Request), Object(GuzzleHttp\\Psr7\\Response), NULL, Array, NULL)
#1 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(209): GuzzleHttp\\Middleware::GuzzleHttp\\{closure}(Object(GuzzleHttp\\Psr7\\Response))
#2 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(158): GuzzleHttp\\Promise\\Promise::callHandler(1, Object(GuzzleHttp\\Psr7\\Response), NULL)
#3 /home/jiminny/vendor/guzzlehttp/promises/src/TaskQueue.php(52): GuzzleHttp\\Promise\\Promise::GuzzleHttp\\Promise\\{closure}()
#4 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(251): GuzzleHttp\\Promise\\TaskQueue->run(true)
#5 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(227): GuzzleHttp\\Promise\\Promise->invokeWaitFn()
#6 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(272): GuzzleHttp\\Promise\\Promise->waitIfPending()
#7 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(229): GuzzleHttp\\Promise\\Promise->invokeWaitList()
#8 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(69): GuzzleHttp\\Promise\\Promise->waitIfPending()
#9 /home/jiminny/vendor/guzzlehttp/guzzle/src/Client.php(189): GuzzleHttp\\Promise\\Promise->wait()
#10 /home/jiminny/vendor/hubspot/hubspot-php/src/Http/Client.php(113): GuzzleHttp\\Client->request('POST', 'https://api.hub...', Array)
#11 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(166): SevenShores\\Hubspot\\Http\\Client->request('POST', 'https://api.hub...', Array)
#12 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#13 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#14 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#15 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#16 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#17 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#18 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#19 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#20 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#21 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#22 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#23 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#24 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#25 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#26 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#27 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#28 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#29 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#30 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#31 {main}
"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:13] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"076c3e6b-6a67-4774-8aa0-2a84fcf5e03c","trace_id":"284e571d-ab92-4e22-b09b-c151c2871cb4"}
[2026-05-07 13:22:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"076c3e6b-6a67-4774-8aa0-2a84fcf5e03c","trace_id":"284e571d-ab92-4e22-b09b-c151c2871cb4"}
[2026-05-07 13:22:19] local.NOTICE: Monitoring start {"correlation_id":"c41d4048-0465-4dcf-bb53-176287732e3e","trace_id":"9ce4a71c-a1a0-456e-843d-38fd15e5c798"}
[2026-05-07 13:22:19] local.NOTICE: Monitoring end {"correlation_id":"c41d4048-0465-4dcf-bb53-176287732e3e","trace_id":"9ce4a71c-a1a0-456e-843d-38fd15e5c798"}
[2026-05-07 13:22:30] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"934766d6-40c0-415c-bd51-d0b67a799c7c","trace_id":"d6c773e8-adf4-453b-8a17-077bf7bdf698"}
[2026-05-07 13:22:30] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"934766d6-40c0-415c-bd51-d0b67a799c7c","trace_id":"d6c773e8-adf4-453b-8a17-077bf7bdf698"}
[2026-05-07 13:22:35] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:41] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: Running conference:monitor:count command for activities in (2026-05-07 13:20:00, 2026-05-07 13:22:00] {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: [conference:monitor:count] No activities found in (2026-05-07 13:20:00, 2026-05-07 13:22:00] {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:create","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: [EmailSchedule] STARTING batch create {"host":"docker_lamp_1"} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: [EmailSchedule] FINISHED batch create {"host":"docker_lamp_1"} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:create","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:52] local.INFO: [Jiminny\Jobs\Mailbox\CreateBatches] processed 2 inboxes and created 0 batches {"userId":null,"batchSize":30,"maxBatches":1000} {"correlation_id":"13eed139-b218-43c9-b147-38ae92c45977","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:53] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:sync","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"cf9df816-4614-4a06-b853-4d6815fb85e1","trace_id":"ca6ed313-c21f-4683-8b5b-013a3ecd4081"}
[2026-05-07 13:22:53] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:sync","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"cf9df816-4614-4a06-b853-4d6815fb85e1","trace_id":"ca6ed313-c21f-4683-8b5b-013a3ecd4081"}
[2026-05-07 13:22:57] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"twilio:recover-tracks","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"93d3bd4f-fe02-4d22-aab9-00c74309e94c","trace_id":"356db0f7-0c25-4739-8c8b-a55ba28e1df0"}
[2026-05-07 13:22:57] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"twilio:recover-tracks","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"93d3bd4f-fe02-4d22-aab9-00c74309e94c","trace_id":"356db0f7-0c25-4739-8c8b-a55ba28e1df0"}
[2026-05-07 13:23:00] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:sync-users","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"connect-and-sell"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Start user synchronisation {"provider":"justcall","teams_count":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Synchronising team {"provider":"justcall","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.WARNING: [Salesforce] Account not connected for user {"userId":"cdf9285a-8ded-4a8b-bd7d-ec68c398f2f9","account":{"Jiminny\\Models\\SocialAccount":{"id":1367,"sociable_id":1071,"provider_user_id":"005O4000003s5c7IAA","expires":null,"refresh_token_expires":null,"provider":"salesforce","state":"full-refresh","auth_scope":"refresh_token web api","retry_after":null,"created_at":"2024-09-10 07:05:21","updated_at":"2026-01-14 07:00:58"}}} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] Integration owner is not connected, attempting team members {"crm_provider":"salesforce","crm_owner":1071,"team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] No team members found with active crm connection {"crm_provider":"salesforce","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] No team member found with active crm connection {"crm_provider":"salesforce","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.WARNING: Failed to sync external users {"message":"Your Salesforce account has become disconnected. Please login to Jiminny to reconnect.","provider":"justcall","team_id":1,"team":"jiminny"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"ringcentral"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"avaya"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"telus"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"salesloft"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"talkdesk"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"vonage"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Done {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:sync-users","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:24:05] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:05] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:05] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:07] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"a2d53fd0-ef62-42d7-bf03-2b78fe690081","trace_id":"ccc71cd2-62d3-4641-bbef-d3ac924250df"}
[2026-05-07 13:24:07] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"a2d53fd0-ef62-42d7-bf03-2b78fe690081","trace_id":"ccc71cd2-62d3-4641-bbef-d3ac924250df"}
[2026-05-07 13:24:09] local.NOTICE: Monitoring start {"correlation_id":"550636b7-858f-4d9a-a78c-1a4464ffe5d6","trace_id":"3a5f8440-816e-420f-a5a4-40ad67ca1542"}
[2026-05-07 13:24:09] local.NOTICE: Monitoring end {"correlation_id":"550636b7-858f-4d9a-a78c-1a4464ffe5d6","trace_id":"3a5f8440-816e-420f-a5a4-40ad67ca1542"}
[2026-05-07 13:24:10] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"97b9a580-2259-4931-82fd-86db94dccd2f","trace_id":"1809cb02-fcd4-4cf7-b426-2fe2cf347fb0"}
[2026-05-07 13:24:11] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"97b9a580-2259-4931-82fd-86db94dccd2f","trace_id":"1809cb02-fcd4-4cf7-b426-2fe2cf347fb0"}
[2026-05-07 13:24:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: Running conference:monitor:count command for activities in (2026-05-07 13:22:00, 2026-05-07 13:24:00] {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: [conference:monitor:count] No activities found in (2026-05-07 13:22:00, 2026-05-07 13:24:00] {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:aircall:check-and-renew","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [SocialAccountService] Fetching token {"socialAccountId":1496,"provider":"aircall"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [SocialAccountService] Token retrieved {"socialAccountId":1496,"provider":"aircall"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.ERROR: [Aircall] Re-activating webhooks failed {"team_id":1,"reason":"{\"message\":\"Forbidden\"}"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:aircall:check-and-renew","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:19] local.INFO: [RetryFailedDownloads] Starting {"options":{"from":null,"to":null,"help":false,"silent":false,"quiet":false,"verbose":false,"version":false,"ansi":null,"no-interaction":false,"env":null}} {"correlation_id":"df682399-d6b7-464b-9aea-85a4d7b10c27","trace_id":"532cf674-cebb-4b99-9190-d3020576b5db"}
[2026-05-07 13:25:06] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:06] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:06] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:08] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"846be41a-5d95-4144-ad3c-273defc37bea","trace_id":"8e158a4b-31e7-4161-af5e-d83f2ad2f3b5"}
[2026-05-07 13:25:08] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"846be41a-5d95-4144-ad3c-273defc37bea","trace_id":"8e158a4b-31e7-4161-af5e-d83f2ad2f3b5"}
[2026-05-07 13:25:11] local.NOTICE: Monitoring start {"correlation_id":"779be55d-57e0-4a33-8d13-cb3fda9c8ce5","trace_id":"4eaf7c2a-5a99-4c32-9fb9-b1377cacdebb"}
[2026-05-07 13:25:11] local.NOTICE: Monitoring end {"correlation_id":"779be55d-57e0-4a33-8d13-cb3fda9c8ce5","trace_id":"4eaf7c2a-5a99-4c32-9fb9-b1377cacdebb"}
[2026-05-07 13:25:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"75ba5939-1152-41ac-bed9-e3c203b981c3","trace_id":"f8537beb-7cb8-4f02-ab66-07754746b812"}
[2026-05-07 13:25:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"75ba5939-1152-41ac-bed9-e3c203b981c3","trace_id":"f8537beb-7cb8-4f02-ab66-07754746b812"}
[2026-05-07 13:25:19] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:21] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:purge-stale","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"3c03ff8f-9391-46b3-9001-5d3e3f364d29","trace_id":"5c5f2a08-7eb1-4eb3-9754-cde3f0425216"}
[2026-05-07 13:25:21] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:purge-stale","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"3c03ff8f-9391-46b3-9001-5d3e3f364d29","trace_id":"5c5f2a08-7eb1-4eb3-9754-cde3f0425216"}
[2026-05-07 13:25:23] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:text-relay:sync","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"640405cd-fddb-4ae4-ab6b-0da9052b22fa","trace_id":"0f39ab5c-c1aa-4aa1-a71c-b62823493c4e"}
[2026-05-07 13:25:23] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:text-relay:sync","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"640405cd-fddb-4ae4-ab6b-0da9052b22fa","trace_id":"0f39ab5c-c1aa-4aa1-a71c-b62823493c4e"}
[2026-05-07 13:25:26] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:pre-meeting-notification","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:26] local.INFO: Running pre-meeting notification command {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:26] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:pre-meeting-notification","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:29] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:start","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: Running conference:monitor:start command for activities in (2026-05-07 13:15:00, 2026-05-07 13:20:00] {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: [conference:monitor:start] No activities found in (2026-05-07 13:15:00, 2026-05-07 13:20:00] {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:start","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:37] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:end","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: conference:monitor:end:Jiminny\Console\Commands\Activities\MonitorMeetingEndCommand::logActivitiesEnded {"from":"13:20","to":"13:25"} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: conference:monitor:end:Jiminny\Console\Commands\Activities\MonitorMeetingEndCommand::logActivitiesWithUnfinishedSession {"from":"03:15","to":"03:20"} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:end","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:41] local.NOTICE: Repairing HubSpot tokens start {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: Trying to refresh HubSpot token {"account_id":59,"updated_at":"2025-10-03 09:32:05"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":59,"provider":"hubspot","refreshToken":"97b78f6e2cc49965c00c2492b602b02708b1392551e6b3f113fbaa48992af90b","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.ERROR: Failed to refresh HubSpot token {"account_id":59,"updated_at":"2025-10-03 09:32:05","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: Trying to refresh HubSpot token {"account_id":306,"updated_at":"2023-11-27 09:30:03"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":306,"provider":"hubspot","refreshToken":"6fa6aa8cc641d131231acc3470f5c03cb3b07b2e580fb18f8acb3b1dbb72549b","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.ERROR: Failed to refresh HubSpot token {"account_id":306,"updated_at":"2023-11-27 09:30:03","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: Trying to refresh HubSpot token {"account_id":1372,"updated_at":"2025-10-02 14:47:06"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":1372,"provider":"hubspot","refreshToken":"9aa73948c761da29dce46c177cf9aee1fde483a44169ca38723f9f0597d7a8c4","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.ERROR: Failed to refresh HubSpot token {"account_id":1372,"updated_at":"2025-10-02 14:47:06","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.NOTICE: Repairing HubSpot tokens end {"total":3,"fixed":0,"failed":3} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:pre-meeting-reminder","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"2775b4f9-6dce-40a2-84ad-fb7f3a2729ed","trace_id":"89eb011f-145e-44f2-a376-0c57cf42c11d"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"crm:bullhorn:ping","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"1b0300f0-a82f-4bf2-b5dc-24e9d04babab","trace_id":"af7b7ef6-7376-48fe-b7b9-a5ad41237fa4"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"crm:bullhorn:ping","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id...
|
PhpStorm
|
faVsco.js β laravel.log
|
NULL
|
4329
|
|
4328
|
Project: faVsco.js, menu
master, menu
Start Listen Project: faVsco.js, menu
master, menu
Start Listening for PHP Debug Connections
AskJiminnyReportActivityServiceTest
Run 'AskJiminnyReportActivityServiceTest'
Debug 'AskJiminnyReportActivityServiceTest'
More Actions
JetBrains AI
Search Everywhere
IDE and Project Settings
Sync Changes
Hide This Notification
Code changed:
Hide
286
Previous Highlighted Error
Next Highlighted Error
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Fetching token {"socialAccountId":1499,"provider":"hubspot"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Token needs refreshing {"socialAccountId":1499,"provider":"hubspot"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":1499,"provider":"hubspot","refreshToken":"96f94c623a404e02ebdbf07f1b75707bb6cdbf848cbf45d418baf608c41a8d86","state":"connected"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountObserver] Saving model {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountObserver] Access token was modified, encrypting {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [SocialAccountService] Token refreshed {"socialAccountId":1499,"provider":"hubspot","state":"connected"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [CrmOwnerResolver] Integration owner matched as CRM Owner {"crm_provider":"hubspot","crm_owner":148,"team_id":2} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [Hubspot] Received 429 from API {"team_id":2,"config_id":2,"retry_after":10,"reason":"Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.ERROR: Hubspot returned 429 {"exception":"[object] (Jiminny\\Exceptions\\RateLimitException(code: 0): Hubspot returned 429 at /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php:206)
[stacktrace]
#0 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#1 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#2 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#3 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#4 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#5 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#6 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#7 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#8 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#9 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#10 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#11 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#12 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#13 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#14 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#15 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#16 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#17 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#18 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#19 {main}
[previous exception] [object] (SevenShores\\Hubspot\\Exceptions\\BadRequest(code: 429): Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
at /home/jiminny/vendor/hubspot/hubspot-php/src/Exceptions/HubspotException.php:24)
[stacktrace]
#0 /home/jiminny/vendor/hubspot/hubspot-php/src/Http/Client.php(125): SevenShores\\Hubspot\\Exceptions\\HubspotException::create(Object(GuzzleHttp\\Exception\\ClientException))
#1 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(166): SevenShores\\Hubspot\\Http\\Client->request('POST', 'https://api.hub...', Array)
#2 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#3 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#4 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#5 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#6 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#7 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#8 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#9 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#10 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#11 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#12 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#13 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#14 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#15 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#16 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#17 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#18 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#19 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#20 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#21 {main}
[previous exception] [object] (GuzzleHttp\\Exception\\ClientException(code: 429): Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
at /home/jiminny/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:111)
[stacktrace]
#0 /home/jiminny/vendor/guzzlehttp/guzzle/src/Middleware.php(72): GuzzleHttp\\Exception\\RequestException::create(Object(GuzzleHttp\\Psr7\\Request), Object(GuzzleHttp\\Psr7\\Response), NULL, Array, NULL)
#1 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(209): GuzzleHttp\\Middleware::GuzzleHttp\\{closure}(Object(GuzzleHttp\\Psr7\\Response))
#2 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(158): GuzzleHttp\\Promise\\Promise::callHandler(1, Object(GuzzleHttp\\Psr7\\Response), NULL)
#3 /home/jiminny/vendor/guzzlehttp/promises/src/TaskQueue.php(52): GuzzleHttp\\Promise\\Promise::GuzzleHttp\\Promise\\{closure}()
#4 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(251): GuzzleHttp\\Promise\\TaskQueue->run(true)
#5 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(227): GuzzleHttp\\Promise\\Promise->invokeWaitFn()
#6 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(272): GuzzleHttp\\Promise\\Promise->waitIfPending()
#7 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(229): GuzzleHttp\\Promise\\Promise->invokeWaitList()
#8 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(69): GuzzleHttp\\Promise\\Promise->waitIfPending()
#9 /home/jiminny/vendor/guzzlehttp/guzzle/src/Client.php(189): GuzzleHttp\\Promise\\Promise->wait()
#10 /home/jiminny/vendor/hubspot/hubspot-php/src/Http/Client.php(113): GuzzleHttp\\Client->request('POST', 'https://api.hub...', Array)
#11 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(166): SevenShores\\Hubspot\\Http\\Client->request('POST', 'https://api.hub...', Array)
#12 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#13 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#14 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#15 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#16 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#17 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#18 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#19 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#20 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#21 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#22 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#23 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#24 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#25 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#26 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#27 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#28 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#29 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#30 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#31 {main}
"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:13] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"076c3e6b-6a67-4774-8aa0-2a84fcf5e03c","trace_id":"284e571d-ab92-4e22-b09b-c151c2871cb4"}
[2026-05-07 13:22:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"076c3e6b-6a67-4774-8aa0-2a84fcf5e03c","trace_id":"284e571d-ab92-4e22-b09b-c151c2871cb4"}
[2026-05-07 13:22:19] local.NOTICE: Monitoring start {"correlation_id":"c41d4048-0465-4dcf-bb53-176287732e3e","trace_id":"9ce4a71c-a1a0-456e-843d-38fd15e5c798"}
[2026-05-07 13:22:19] local.NOTICE: Monitoring end {"correlation_id":"c41d4048-0465-4dcf-bb53-176287732e3e","trace_id":"9ce4a71c-a1a0-456e-843d-38fd15e5c798"}
[2026-05-07 13:22:30] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"934766d6-40c0-415c-bd51-d0b67a799c7c","trace_id":"d6c773e8-adf4-453b-8a17-077bf7bdf698"}
[2026-05-07 13:22:30] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"934766d6-40c0-415c-bd51-d0b67a799c7c","trace_id":"d6c773e8-adf4-453b-8a17-077bf7bdf698"}
[2026-05-07 13:22:35] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:41] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: Running conference:monitor:count command for activities in (2026-05-07 13:20:00, 2026-05-07 13:22:00] {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: [conference:monitor:count] No activities found in (2026-05-07 13:20:00, 2026-05-07 13:22:00] {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:create","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: [EmailSchedule] STARTING batch create {"host":"docker_lamp_1"} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: [EmailSchedule] FINISHED batch create {"host":"docker_lamp_1"} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:create","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:52] local.INFO: [Jiminny\Jobs\Mailbox\CreateBatches] processed 2 inboxes and created 0 batches {"userId":null,"batchSize":30,"maxBatches":1000} {"correlation_id":"13eed139-b218-43c9-b147-38ae92c45977","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:53] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:sync","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"cf9df816-4614-4a06-b853-4d6815fb85e1","trace_id":"ca6ed313-c21f-4683-8b5b-013a3ecd4081"}
[2026-05-07 13:22:53] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:sync","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"cf9df816-4614-4a06-b853-4d6815fb85e1","trace_id":"ca6ed313-c21f-4683-8b5b-013a3ecd4081"}
[2026-05-07 13:22:57] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"twilio:recover-tracks","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"93d3bd4f-fe02-4d22-aab9-00c74309e94c","trace_id":"356db0f7-0c25-4739-8c8b-a55ba28e1df0"}
[2026-05-07 13:22:57] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"twilio:recover-tracks","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"93d3bd4f-fe02-4d22-aab9-00c74309e94c","trace_id":"356db0f7-0c25-4739-8c8b-a55ba28e1df0"}
[2026-05-07 13:23:00] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:sync-users","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"connect-and-sell"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Start user synchronisation {"provider":"justcall","teams_count":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Synchronising team {"provider":"justcall","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.WARNING: [Salesforce] Account not connected for user {"userId":"cdf9285a-8ded-4a8b-bd7d-ec68c398f2f9","account":{"Jiminny\\Models\\SocialAccount":{"id":1367,"sociable_id":1071,"provider_user_id":"005O4000003s5c7IAA","expires":null,"refresh_token_expires":null,"provider":"salesforce","state":"full-refresh","auth_scope":"refresh_token web api","retry_after":null,"created_at":"2024-09-10 07:05:21","updated_at":"2026-01-14 07:00:58"}}} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] Integration owner is not connected, attempting team members {"crm_provider":"salesforce","crm_owner":1071,"team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] No team members found with active crm connection {"crm_provider":"salesforce","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] No team member found with active crm connection {"crm_provider":"salesforce","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.WARNING: Failed to sync external users {"message":"Your Salesforce account has become disconnected. Please login to Jiminny to reconnect.","provider":"justcall","team_id":1,"team":"jiminny"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"ringcentral"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"avaya"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"telus"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"salesloft"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"talkdesk"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"vonage"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Done {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:sync-users","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:24:05] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:05] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:05] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:07] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"a2d53fd0-ef62-42d7-bf03-2b78fe690081","trace_id":"ccc71cd2-62d3-4641-bbef-d3ac924250df"}
[2026-05-07 13:24:07] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"a2d53fd0-ef62-42d7-bf03-2b78fe690081","trace_id":"ccc71cd2-62d3-4641-bbef-d3ac924250df"}
[2026-05-07 13:24:09] local.NOTICE: Monitoring start {"correlation_id":"550636b7-858f-4d9a-a78c-1a4464ffe5d6","trace_id":"3a5f8440-816e-420f-a5a4-40ad67ca1542"}
[2026-05-07 13:24:09] local.NOTICE: Monitoring end {"correlation_id":"550636b7-858f-4d9a-a78c-1a4464ffe5d6","trace_id":"3a5f8440-816e-420f-a5a4-40ad67ca1542"}
[2026-05-07 13:24:10] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"97b9a580-2259-4931-82fd-86db94dccd2f","trace_id":"1809cb02-fcd4-4cf7-b426-2fe2cf347fb0"}
[2026-05-07 13:24:11] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"97b9a580-2259-4931-82fd-86db94dccd2f","trace_id":"1809cb02-fcd4-4cf7-b426-2fe2cf347fb0"}
[2026-05-07 13:24:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: Running conference:monitor:count command for activities in (2026-05-07 13:22:00, 2026-05-07 13:24:00] {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: [conference:monitor:count] No activities found in (2026-05-07 13:22:00, 2026-05-07 13:24:00] {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:aircall:check-and-renew","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [SocialAccountService] Fetching token {"socialAccountId":1496,"provider":"aircall"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [SocialAccountService] Token retrieved {"socialAccountId":1496,"provider":"aircall"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.ERROR: [Aircall] Re-activating webhooks failed {"team_id":1,"reason":"{\"message\":\"Forbidden\"}"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:aircall:check-and-renew","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:19] local.INFO: [RetryFailedDownloads] Starting {"options":{"from":null,"to":null,"help":false,"silent":false,"quiet":false,"verbose":false,"version":false,"ansi":null,"no-interaction":false,"env":null}} {"correlation_id":"df682399-d6b7-464b-9aea-85a4d7b10c27","trace_id":"532cf674-cebb-4b99-9190-d3020576b5db"}
[2026-05-07 13:25:06] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:06] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:06] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:08] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"846be41a-5d95-4144-ad3c-273defc37bea","trace_id":"8e158a4b-31e7-4161-af5e-d83f2ad2f3b5"}
[2026-05-07 13:25:08] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"846be41a-5d95-4144-ad3c-273defc37bea","trace_id":"8e158a4b-31e7-4161-af5e-d83f2ad2f3b5"}
[2026-05-07 13:25:11] local.NOTICE: Monitoring start {"correlation_id":"779be55d-57e0-4a33-8d13-cb3fda9c8ce5","trace_id":"4eaf7c2a-5a99-4c32-9fb9-b1377cacdebb"}
[2026-05-07 13:25:11] local.NOTICE: Monitoring end {"correlation_id":"779be55d-57e0-4a33-8d13-cb3fda9c8ce5","trace_id":"4eaf7c2a-5a99-4c32-9fb9-b1377cacdebb"}
[2026-05-07 13:25:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"75ba5939-1152-41ac-bed9-e3c203b981c3","trace_id":"f8537beb-7cb8-4f02-ab66-07754746b812"}
[2026-05-07 13:25:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"75ba5939-1152-41ac-bed9-e3c203b981c3","trace_id":"f8537beb-7cb8-4f02-ab66-07754746b812"}
[2026-05-07 13:25:19] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:21] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:purge-stale","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"3c03ff8f-9391-46b3-9001-5d3e3f364d29","trace_id":"5c5f2a08-7eb1-4eb3-9754-cde3f0425216"}
[2026-05-07 13:25:21] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:purge-stale","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"3c03ff8f-9391-46b3-9001-5d3e3f364d29","trace_id":"5c5f2a08-7eb1-4eb3-9754-cde3f0425216"}
[2026-05-07 13:25:23] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:text-relay:sync","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"640405cd-fddb-4ae4-ab6b-0da9052b22fa","trace_id":"0f39ab5c-c1aa-4aa1-a71c-b62823493c4e"}
[2026-05-07 13:25:23] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:text-relay:sync","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"640405cd-fddb-4ae4-ab6b-0da9052b22fa","trace_id":"0f39ab5c-c1aa-4aa1-a71c-b62823493c4e"}
[2026-05-07 13:25:26] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:pre-meeting-notification","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:26] local.INFO: Running pre-meeting notification command {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:26] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:pre-meeting-notification","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:29] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:start","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: Running conference:monitor:start command for activities in (2026-05-07 13:15:00, 2026-05-07 13:20:00] {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: [conference:monitor:start] No activities found in (2026-05-07 13:15:00, 2026-05-07 13:20:00] {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:start","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:37] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:end","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: conference:monitor:end:Jiminny\Console\Commands\Activities\MonitorMeetingEndCommand::logActivitiesEnded {"from":"13:20","to":"13:25"} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: conference:monitor:end:Jiminny\Console\Commands\Activities\MonitorMeetingEndCommand::logActivitiesWithUnfinishedSession {"from":"03:15","to":"03:20"} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:end","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:41] local.NOTICE: Repairing HubSpot tokens start {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: Trying to refresh HubSpot token {"account_id":59,"updated_at":"2025-10-03 09:32:05"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":59,"provider":"hubspot","refreshToken":"97b78f6e2cc49965c00c2492b602b02708b1392551e6b3f113fbaa48992af90b","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.ERROR: Failed to refresh HubSpot token {"account_id":59,"updated_at":"2025-10-03 09:32:05","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: Trying to refresh HubSpot token {"account_id":306,"updated_at":"2023-11-27 09:30:03"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":306,"provider":"hubspot","refreshToken":"6fa6aa8cc641d131231acc3470f5c03cb3b07b2e580fb18f8acb3b1dbb72549b","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.ERROR: Failed to refresh HubSpot token {"account_id":306,"updated_at":"2023-11-27 09:30:03","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: Trying to refresh HubSpot token {"account_id":1372,"updated_at":"2025-10-02 14:47:06"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":1372,"provider":"hubspot","refreshToken":"9aa73948c761da29dce46c177cf9aee1fde483a44169ca38723f9f0597d7a8c4","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.ERROR: Failed to refresh HubSpot token {"account_id":1372,"updated_at":"2025-10-02 14:47:06","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.NOTICE: Repairing HubSpot tokens end {"total":3,"fixed":0,"failed":3} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:pre-meeting-reminder","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"2775b4f9-6dce-40a2-84ad-fb7f3a2729ed","trace_id":"89eb011f-145e-44f2-a376-0c57cf42c11d"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"crm:bullhorn:ping","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"1b0300f0-a82f-4bf2-b5dc-24e9d04babab","trace_id":"af7b7ef6-7376-48fe-b7b9-a5ad41237fa4"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"crm:bullhorn:ping","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id...
|
PhpStorm
|
faVsco.js β Client.php
|
NULL
|
4328
|
|
4327
|
Search
\Tests\Unit\Component\AiActivityType\Servic Search
\Tests\Unit\Component\AiActivityType\Services
\Tests\Unit\Component\AiActivityType\Services
\Tests\Unit\Jobs\Crm
\Tests\Unit\Jobs\Crm
\Tests\Unit\Jobs\Crm
\Tests\Unit\Jobs\Crm
ActivityLanguageCodeMissingException \Jiminny\Component\ProphetAi\Exceptions
ActivityLanguageCodeMissingException \Jiminny\Component\ProphetAi\Exceptions
ActivityProviderException \Jiminny\Exceptions
ActivityProviderException \Jiminny\Exceptions
ApiException \Jiminny\Exceptions
ApiException \Jiminny\Exceptions
ApiException \Jiminny\Services\Activity\Vonage\Exception
ApiException \Jiminny\Services\Activity\Vonage\Exception
ApiResponseException \Jiminny\Exceptions
ApiResponseException \Jiminny\Exceptions
ApplicationException \Jiminny\Exceptions
ApplicationException \Jiminny\Exceptions
AskJiminnyException \Jiminny\Component\AskJiminnyAi\Exceptions
AskJiminnyException \Jiminny\Component\AskJiminnyAi\Exceptions
AsyncElasticSearchUpdateChunkFailed \Jiminny\Exceptions
AsyncElasticSearchUpdateChunkFailed \Jiminny\Exceptions
BadKeywordsQueryException \Jiminny\Exceptions
BadKeywordsQueryException \Jiminny\Exceptions
BadResponseException \Jiminny\Services\Activity\Talkdesk\Exception
BadResponseException \Jiminny\Services\Activity\Talkdesk\Exception
BadResponseException \Jiminny\Services\Activity\Vonage\Exception
BadResponseException \Jiminny\Services\Activity\Vonage\Exception
CalculateSilenceException \Jiminny\Component\Encoding\Exceptions
ActivityProviderException \Jiminny\Exceptions
CloseException \Jiminny\Services\Crm\Close
CloseException \Jiminny\Services\Crm\Close
ConfigurationException \Jiminny\Component\BillingManagement\Exception
ConfigurationException \Jiminny\Component\BillingManagement\Exception
ConfigurationException \Jiminny\Exceptions
ActivityProviderException \Jiminny\Exceptions
ContentLengthNotFoundInResponseException \Jiminny\Component\Uploader\Exceptions
ContentLengthNotFoundInResponseException \Jiminny\Component\Uploader\Exceptions
CopperException \Jiminny\Services\Crm\Copper\Exception
CopperException \Jiminny\Services\Crm\Copper\Exception
CrmConnectionExpired \Jiminny\Component\Twilio\Exception
CrmConnectionExpired \Jiminny\Component\Twilio\Exception
CrmException \Jiminny\Exceptions
CrmException \Jiminny\Exceptions
CrmUpdateException \Jiminny\Exceptions...
|
PhpStorm
|
|
NULL
|
4327
|
|
4326
|
Project: faVsco.js, menu
master, menu
Start Listen Project: faVsco.js, menu
master, menu
Start Listening for PHP Debug Connections
AskJiminnyReportActivityServiceTest
Run 'AskJiminnyReportActivityServiceTest'
Debug 'AskJiminnyReportActivityServiceTest'
More Actions
JetBrains AI
Search Everywhere
IDE and Project Settings
Sync Changes
Hide This Notification
Code changed:
Hide
286
Previous Highlighted Error
Next Highlighted Error
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Fetching token {"socialAccountId":1499,"provider":"hubspot"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Token needs refreshing {"socialAccountId":1499,"provider":"hubspot"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":1499,"provider":"hubspot","refreshToken":"96f94c623a404e02ebdbf07f1b75707bb6cdbf848cbf45d418baf608c41a8d86","state":"connected"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountObserver] Saving model {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountObserver] Access token was modified, encrypting {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [SocialAccountService] Token refreshed {"socialAccountId":1499,"provider":"hubspot","state":"connected"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [CrmOwnerResolver] Integration owner matched as CRM Owner {"crm_provider":"hubspot","crm_owner":148,"team_id":2} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [Hubspot] Received 429 from API {"team_id":2,"config_id":2,"retry_after":10,"reason":"Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.ERROR: Hubspot returned 429 {"exception":"[object] (Jiminny\\Exceptions\\RateLimitException(code: 0): Hubspot returned 429 at /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php:206)
[stacktrace]
#0 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#1 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#2 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#3 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#4 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#5 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#6 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#7 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#8 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#9 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#10 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#11 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#12 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#13 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#14 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#15 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#16 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#17 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#18 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#19 {main}
[previous exception] [object] (SevenShores\\Hubspot\\Exceptions\\BadRequest(code: 429): Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
at /home/jiminny/vendor/hubspot/hubspot-php/src/Exceptions/HubspotException.php:24)
[stacktrace]
#0 /home/jiminny/vendor/hubspot/hubspot-php/src/Http/Client.php(125): SevenShores\\Hubspot\\Exceptions\\HubspotException::create(Object(GuzzleHttp\\Exception\\ClientException))
#1 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(166): SevenShores\\Hubspot\\Http\\Client->request('POST', 'https://api.hub...', Array)
#2 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#3 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#4 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#5 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#6 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#7 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#8 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#9 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#10 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#11 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#12 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#13 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#14 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#15 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#16 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#17 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#18 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#19 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#20 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#21 {main}
[previous exception] [object] (GuzzleHttp\\Exception\\ClientException(code: 429): Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
at /home/jiminny/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:111)
[stacktrace]
#0 /home/jiminny/vendor/guzzlehttp/guzzle/src/Middleware.php(72): GuzzleHttp\\Exception\\RequestException::create(Object(GuzzleHttp\\Psr7\\Request), Object(GuzzleHttp\\Psr7\\Response), NULL, Array, NULL)
#1 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(209): GuzzleHttp\\Middleware::GuzzleHttp\\{closure}(Object(GuzzleHttp\\Psr7\\Response))
#2 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(158): GuzzleHttp\\Promise\\Promise::callHandler(1, Object(GuzzleHttp\\Psr7\\Response), NULL)
#3 /home/jiminny/vendor/guzzlehttp/promises/src/TaskQueue.php(52): GuzzleHttp\\Promise\\Promise::GuzzleHttp\\Promise\\{closure}()
#4 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(251): GuzzleHttp\\Promise\\TaskQueue->run(true)
#5 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(227): GuzzleHttp\\Promise\\Promise->invokeWaitFn()
#6 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(272): GuzzleHttp\\Promise\\Promise->waitIfPending()
#7 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(229): GuzzleHttp\\Promise\\Promise->invokeWaitList()
#8 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(69): GuzzleHttp\\Promise\\Promise->waitIfPending()
#9 /home/jiminny/vendor/guzzlehttp/guzzle/src/Client.php(189): GuzzleHttp\\Promise\\Promise->wait()
#10 /home/jiminny/vendor/hubspot/hubspot-php/src/Http/Client.php(113): GuzzleHttp\\Client->request('POST', 'https://api.hub...', Array)
#11 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(166): SevenShores\\Hubspot\\Http\\Client->request('POST', 'https://api.hub...', Array)
#12 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#13 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#14 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#15 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#16 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#17 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#18 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#19 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#20 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#21 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#22 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#23 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#24 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#25 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#26 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#27 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#28 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#29 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#30 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#31 {main}
"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:13] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"076c3e6b-6a67-4774-8aa0-2a84fcf5e03c","trace_id":"284e571d-ab92-4e22-b09b-c151c2871cb4"}
[2026-05-07 13:22:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"076c3e6b-6a67-4774-8aa0-2a84fcf5e03c","trace_id":"284e571d-ab92-4e22-b09b-c151c2871cb4"}
[2026-05-07 13:22:19] local.NOTICE: Monitoring start {"correlation_id":"c41d4048-0465-4dcf-bb53-176287732e3e","trace_id":"9ce4a71c-a1a0-456e-843d-38fd15e5c798"}
[2026-05-07 13:22:19] local.NOTICE: Monitoring end {"correlation_id":"c41d4048-0465-4dcf-bb53-176287732e3e","trace_id":"9ce4a71c-a1a0-456e-843d-38fd15e5c798"}
[2026-05-07 13:22:30] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"934766d6-40c0-415c-bd51-d0b67a799c7c","trace_id":"d6c773e8-adf4-453b-8a17-077bf7bdf698"}
[2026-05-07 13:22:30] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"934766d6-40c0-415c-bd51-d0b67a799c7c","trace_id":"d6c773e8-adf4-453b-8a17-077bf7bdf698"}
[2026-05-07 13:22:35] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:41] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: Running conference:monitor:count command for activities in (2026-05-07 13:20:00, 2026-05-07 13:22:00] {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: [conference:monitor:count] No activities found in (2026-05-07 13:20:00, 2026-05-07 13:22:00] {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:create","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: [EmailSchedule] STARTING batch create {"host":"docker_lamp_1"} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: [EmailSchedule] FINISHED batch create {"host":"docker_lamp_1"} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:create","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:52] local.INFO: [Jiminny\Jobs\Mailbox\CreateBatches] processed 2 inboxes and created 0 batches {"userId":null,"batchSize":30,"maxBatches":1000} {"correlation_id":"13eed139-b218-43c9-b147-38ae92c45977","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:53] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:sync","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"cf9df816-4614-4a06-b853-4d6815fb85e1","trace_id":"ca6ed313-c21f-4683-8b5b-013a3ecd4081"}
[2026-05-07 13:22:53] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:sync","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"cf9df816-4614-4a06-b853-4d6815fb85e1","trace_id":"ca6ed313-c21f-4683-8b5b-013a3ecd4081"}
[2026-05-07 13:22:57] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"twilio:recover-tracks","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"93d3bd4f-fe02-4d22-aab9-00c74309e94c","trace_id":"356db0f7-0c25-4739-8c8b-a55ba28e1df0"}
[2026-05-07 13:22:57] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"twilio:recover-tracks","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"93d3bd4f-fe02-4d22-aab9-00c74309e94c","trace_id":"356db0f7-0c25-4739-8c8b-a55ba28e1df0"}
[2026-05-07 13:23:00] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:sync-users","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"connect-and-sell"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Start user synchronisation {"provider":"justcall","teams_count":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Synchronising team {"provider":"justcall","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.WARNING: [Salesforce] Account not connected for user {"userId":"cdf9285a-8ded-4a8b-bd7d-ec68c398f2f9","account":{"Jiminny\\Models\\SocialAccount":{"id":1367,"sociable_id":1071,"provider_user_id":"005O4000003s5c7IAA","expires":null,"refresh_token_expires":null,"provider":"salesforce","state":"full-refresh","auth_scope":"refresh_token web api","retry_after":null,"created_at":"2024-09-10 07:05:21","updated_at":"2026-01-14 07:00:58"}}} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] Integration owner is not connected, attempting team members {"crm_provider":"salesforce","crm_owner":1071,"team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] No team members found with active crm connection {"crm_provider":"salesforce","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] No team member found with active crm connection {"crm_provider":"salesforce","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.WARNING: Failed to sync external users {"message":"Your Salesforce account has become disconnected. Please login to Jiminny to reconnect.","provider":"justcall","team_id":1,"team":"jiminny"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"ringcentral"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"avaya"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"telus"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"salesloft"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"talkdesk"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"vonage"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Done {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:sync-users","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:24:05] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:05] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:05] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:07] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"a2d53fd0-ef62-42d7-bf03-2b78fe690081","trace_id":"ccc71cd2-62d3-4641-bbef-d3ac924250df"}
[2026-05-07 13:24:07] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"a2d53fd0-ef62-42d7-bf03-2b78fe690081","trace_id":"ccc71cd2-62d3-4641-bbef-d3ac924250df"}
[2026-05-07 13:24:09] local.NOTICE: Monitoring start {"correlation_id":"550636b7-858f-4d9a-a78c-1a4464ffe5d6","trace_id":"3a5f8440-816e-420f-a5a4-40ad67ca1542"}
[2026-05-07 13:24:09] local.NOTICE: Monitoring end {"correlation_id":"550636b7-858f-4d9a-a78c-1a4464ffe5d6","trace_id":"3a5f8440-816e-420f-a5a4-40ad67ca1542"}
[2026-05-07 13:24:10] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"97b9a580-2259-4931-82fd-86db94dccd2f","trace_id":"1809cb02-fcd4-4cf7-b426-2fe2cf347fb0"}
[2026-05-07 13:24:11] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"97b9a580-2259-4931-82fd-86db94dccd2f","trace_id":"1809cb02-fcd4-4cf7-b426-2fe2cf347fb0"}
[2026-05-07 13:24:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: Running conference:monitor:count command for activities in (2026-05-07 13:22:00, 2026-05-07 13:24:00] {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: [conference:monitor:count] No activities found in (2026-05-07 13:22:00, 2026-05-07 13:24:00] {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:aircall:check-and-renew","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [SocialAccountService] Fetching token {"socialAccountId":1496,"provider":"aircall"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [SocialAccountService] Token retrieved {"socialAccountId":1496,"provider":"aircall"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.ERROR: [Aircall] Re-activating webhooks failed {"team_id":1,"reason":"{\"message\":\"Forbidden\"}"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:aircall:check-and-renew","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:19] local.INFO: [RetryFailedDownloads] Starting {"options":{"from":null,"to":null,"help":false,"silent":false,"quiet":false,"verbose":false,"version":false,"ansi":null,"no-interaction":false,"env":null}} {"correlation_id":"df682399-d6b7-464b-9aea-85a4d7b10c27","trace_id":"532cf674-cebb-4b99-9190-d3020576b5db"}
[2026-05-07 13:25:06] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:06] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:06] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:08] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"846be41a-5d95-4144-ad3c-273defc37bea","trace_id":"8e158a4b-31e7-4161-af5e-d83f2ad2f3b5"}
[2026-05-07 13:25:08] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"846be41a-5d95-4144-ad3c-273defc37bea","trace_id":"8e158a4b-31e7-4161-af5e-d83f2ad2f3b5"}
[2026-05-07 13:25:11] local.NOTICE: Monitoring start {"correlation_id":"779be55d-57e0-4a33-8d13-cb3fda9c8ce5","trace_id":"4eaf7c2a-5a99-4c32-9fb9-b1377cacdebb"}
[2026-05-07 13:25:11] local.NOTICE: Monitoring end {"correlation_id":"779be55d-57e0-4a33-8d13-cb3fda9c8ce5","trace_id":"4eaf7c2a-5a99-4c32-9fb9-b1377cacdebb"}
[2026-05-07 13:25:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"75ba5939-1152-41ac-bed9-e3c203b981c3","trace_id":"f8537beb-7cb8-4f02-ab66-07754746b812"}
[2026-05-07 13:25:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"75ba5939-1152-41ac-bed9-e3c203b981c3","trace_id":"f8537beb-7cb8-4f02-ab66-07754746b812"}
[2026-05-07 13:25:19] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:21] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:purge-stale","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"3c03ff8f-9391-46b3-9001-5d3e3f364d29","trace_id":"5c5f2a08-7eb1-4eb3-9754-cde3f0425216"}
[2026-05-07 13:25:21] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:purge-stale","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"3c03ff8f-9391-46b3-9001-5d3e3f364d29","trace_id":"5c5f2a08-7eb1-4eb3-9754-cde3f0425216"}
[2026-05-07 13:25:23] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:text-relay:sync","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"640405cd-fddb-4ae4-ab6b-0da9052b22fa","trace_id":"0f39ab5c-c1aa-4aa1-a71c-b62823493c4e"}
[2026-05-07 13:25:23] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:text-relay:sync","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"640405cd-fddb-4ae4-ab6b-0da9052b22fa","trace_id":"0f39ab5c-c1aa-4aa1-a71c-b62823493c4e"}
[2026-05-07 13:25:26] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:pre-meeting-notification","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:26] local.INFO: Running pre-meeting notification command {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:26] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:pre-meeting-notification","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:29] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:start","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: Running conference:monitor:start command for activities in (2026-05-07 13:15:00, 2026-05-07 13:20:00] {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: [conference:monitor:start] No activities found in (2026-05-07 13:15:00, 2026-05-07 13:20:00] {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:start","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:37] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:end","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: conference:monitor:end:Jiminny\Console\Commands\Activities\MonitorMeetingEndCommand::logActivitiesEnded {"from":"13:20","to":"13:25"} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: conference:monitor:end:Jiminny\Console\Commands\Activities\MonitorMeetingEndCommand::logActivitiesWithUnfinishedSession {"from":"03:15","to":"03:20"} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:end","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:41] local.NOTICE: Repairing HubSpot tokens start {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: Trying to refresh HubSpot token {"account_id":59,"updated_at":"2025-10-03 09:32:05"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":59,"provider":"hubspot","refreshToken":"97b78f6e2cc49965c00c2492b602b02708b1392551e6b3f113fbaa48992af90b","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.ERROR: Failed to refresh HubSpot token {"account_id":59,"updated_at":"2025-10-03 09:32:05","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: Trying to refresh HubSpot token {"account_id":306,"updated_at":"2023-11-27 09:30:03"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":306,"provider":"hubspot","refreshToken":"6fa6aa8cc641d131231acc3470f5c03cb3b07b2e580fb18f8acb3b1dbb72549b","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.ERROR: Failed to refresh HubSpot token {"account_id":306,"updated_at":"2023-11-27 09:30:03","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: Trying to refresh HubSpot token {"account_id":1372,"updated_at":"2025-10-02 14:47:06"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":1372,"provider":"hubspot","refreshToken":"9aa73948c761da29dce46c177cf9aee1fde483a44169ca38723f9f0597d7a8c4","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.ERROR: Failed to refresh HubSpot token {"account_id":1372,"updated_at":"2025-10-02 14:47:06","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.NOTICE: Repairing HubSpot tokens end {"total":3,"fixed":0,"failed":3} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:pre-meeting-reminder","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"2775b4f9-6dce-40a2-84ad-fb7f3a2729ed","trace_id":"89eb011f-145e-44f2-a376-0c57cf42c11d"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"crm:bullhorn:ping","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"1b0300f0-a82f-4bf2-b5dc-24e9d04babab","trace_id":"af7b7ef6-7376-48fe-b7b9-a5ad41237fa4"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"crm:bullhorn:ping","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id...
|
PhpStorm
|
faVsco.js β RateLimitException.php
|
NULL
|
4326
|
|
4325
|
iTerm2ShellEditViewSessionScriptsProfilesWindowHel iTerm2ShellEditViewSessionScriptsProfilesWindowHelplabl= Lukas/Stefka 121 - in 1h 4 m100% <478Thu 7 May 16:26:45DEV (docker)APP (-zsh)*3T81DOCKERDEV (docker)182worker-crm-sync:worker-crm-sync_00: startedworker-crm-update:worker-crm-update_00: startedworker-download:worker-download_00: startedworker-emails:worker-emails_00: startedworker-es-update:worker-es-update_00: startedworker-nudges:worker-nudges_00: startedroot@docker_lamp_1:/home/jiminny# php artisan jiminny:debugMatching contact 0Matching contact 1Matching contact 2Matching contactMatchingcontact4Matchingcontact5Matchingcontact 6Matching contact 7Matching contact 8Matching contact 9root@docker_lamp_1:/home/jiminny# php artisan jiminny:debugMatching contact 0-zshβ’ 84|ffmpegβ’$5-zshβ΄6Jiminny \Exceptions \RateLimitExceptionHubspot returned 429at app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php:206202'retry_after' =SretryAfter,203"reason"204= Se->getMessage(),205β 206throw new RateLimitException('Hubspot returned 429', SretryAfter, $e);207208} else 1throw $e;209}210+14 vendor frames15DEVapp/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php:166SevenShores\Hubspot\Http\Client:: request("POST", "[URL_WITH_CREDENTIALS] ]...
|
PhpStorm
|
faVsco.js β RateLimitException.php
|
NULL
|
4325
|
|
4324
|
Project: faVsco.js, menu
master, menu
Start Listen Project: faVsco.js, menu
master, menu
Start Listening for PHP Debug Connections
AskJiminnyReportActivityServiceTest
Run 'AskJiminnyReportActivityServiceTest'
Debug 'AskJiminnyReportActivityServiceTest'
More Actions
JetBrains AI
Search Everywhere
IDE and Project Settings
Sync Changes
Hide This Notification
Code changed:
Hide
286
Previous Highlighted Error
Next Highlighted Error
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Fetching token {"socialAccountId":1499,"provider":"hubspot"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Token needs refreshing {"socialAccountId":1499,"provider":"hubspot"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":1499,"provider":"hubspot","refreshToken":"96f94c623a404e02ebdbf07f1b75707bb6cdbf848cbf45d418baf608c41a8d86","state":"connected"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountObserver] Saving model {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountObserver] Access token was modified, encrypting {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [SocialAccountService] Token refreshed {"socialAccountId":1499,"provider":"hubspot","state":"connected"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [CrmOwnerResolver] Integration owner matched as CRM Owner {"crm_provider":"hubspot","crm_owner":148,"team_id":2} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [Hubspot] Received 429 from API {"team_id":2,"config_id":2,"retry_after":10,"reason":"Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.ERROR: Hubspot returned 429 {"exception":"[object] (Jiminny\\Exceptions\\RateLimitException(code: 0): Hubspot returned 429 at /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php:206)
[stacktrace]
#0 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#1 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#2 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#3 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#4 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#5 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#6 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#7 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#8 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#9 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#10 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#11 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#12 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#13 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#14 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#15 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#16 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#17 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#18 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#19 {main}
[previous exception] [object] (SevenShores\\Hubspot\\Exceptions\\BadRequest(code: 429): Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
at /home/jiminny/vendor/hubspot/hubspot-php/src/Exceptions/HubspotException.php:24)
[stacktrace]
#0 /home/jiminny/vendor/hubspot/hubspot-php/src/Http/Client.php(125): SevenShores\\Hubspot\\Exceptions\\HubspotException::create(Object(GuzzleHttp\\Exception\\ClientException))
#1 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(166): SevenShores\\Hubspot\\Http\\Client->request('POST', 'https://api.hub...', Array)
#2 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#3 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#4 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#5 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#6 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#7 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#8 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#9 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#10 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#11 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#12 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#13 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#14 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#15 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#16 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#17 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#18 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#19 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#20 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#21 {main}
[previous exception] [object] (GuzzleHttp\\Exception\\ClientException(code: 429): Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
at /home/jiminny/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:111)
[stacktrace]
#0 /home/jiminny/vendor/guzzlehttp/guzzle/src/Middleware.php(72): GuzzleHttp\\Exception\\RequestException::create(Object(GuzzleHttp\\Psr7\\Request), Object(GuzzleHttp\\Psr7\\Response), NULL, Array, NULL)
#1 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(209): GuzzleHttp\\Middleware::GuzzleHttp\\{closure}(Object(GuzzleHttp\\Psr7\\Response))
#2 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(158): GuzzleHttp\\Promise\\Promise::callHandler(1, Object(GuzzleHttp\\Psr7\\Response), NULL)
#3 /home/jiminny/vendor/guzzlehttp/promises/src/TaskQueue.php(52): GuzzleHttp\\Promise\\Promise::GuzzleHttp\\Promise\\{closure}()
#4 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(251): GuzzleHttp\\Promise\\TaskQueue->run(true)
#5 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(227): GuzzleHttp\\Promise\\Promise->invokeWaitFn()
#6 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(272): GuzzleHttp\\Promise\\Promise->waitIfPending()
#7 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(229): GuzzleHttp\\Promise\\Promise->invokeWaitList()
#8 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(69): GuzzleHttp\\Promise\\Promise->waitIfPending()
#9 /home/jiminny/vendor/guzzlehttp/guzzle/src/Client.php(189): GuzzleHttp\\Promise\\Promise->wait()
#10 /home/jiminny/vendor/hubspot/hubspot-php/src/Http/Client.php(113): GuzzleHttp\\Client->request('POST', 'https://api.hub...', Array)
#11 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(166): SevenShores\\Hubspot\\Http\\Client->request('POST', 'https://api.hub...', Array)
#12 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#13 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#14 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#15 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#16 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#17 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#18 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#19 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#20 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#21 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#22 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#23 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#24 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#25 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#26 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#27 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#28 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#29 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#30 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#31 {main}
"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:13] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"076c3e6b-6a67-4774-8aa0-2a84fcf5e03c","trace_id":"284e571d-ab92-4e22-b09b-c151c2871cb4"}
[2026-05-07 13:22:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"076c3e6b-6a67-4774-8aa0-2a84fcf5e03c","trace_id":"284e571d-ab92-4e22-b09b-c151c2871cb4"}
[2026-05-07 13:22:19] local.NOTICE: Monitoring start {"correlation_id":"c41d4048-0465-4dcf-bb53-176287732e3e","trace_id":"9ce4a71c-a1a0-456e-843d-38fd15e5c798"}
[2026-05-07 13:22:19] local.NOTICE: Monitoring end {"correlation_id":"c41d4048-0465-4dcf-bb53-176287732e3e","trace_id":"9ce4a71c-a1a0-456e-843d-38fd15e5c798"}
[2026-05-07 13:22:30] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"934766d6-40c0-415c-bd51-d0b67a799c7c","trace_id":"d6c773e8-adf4-453b-8a17-077bf7bdf698"}
[2026-05-07 13:22:30] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"934766d6-40c0-415c-bd51-d0b67a799c7c","trace_id":"d6c773e8-adf4-453b-8a17-077bf7bdf698"}
[2026-05-07 13:22:35] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:41] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: Running conference:monitor:count command for activities in (2026-05-07 13:20:00, 2026-05-07 13:22:00] {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: [conference:monitor:count] No activities found in (2026-05-07 13:20:00, 2026-05-07 13:22:00] {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:create","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: [EmailSchedule] STARTING batch create {"host":"docker_lamp_1"} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: [EmailSchedule] FINISHED batch create {"host":"docker_lamp_1"} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:create","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:52] local.INFO: [Jiminny\Jobs\Mailbox\CreateBatches] processed 2 inboxes and created 0 batches {"userId":null,"batchSize":30,"maxBatches":1000} {"correlation_id":"13eed139-b218-43c9-b147-38ae92c45977","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:53] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:sync","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"cf9df816-4614-4a06-b853-4d6815fb85e1","trace_id":"ca6ed313-c21f-4683-8b5b-013a3ecd4081"}
[2026-05-07 13:22:53] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:sync","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"cf9df816-4614-4a06-b853-4d6815fb85e1","trace_id":"ca6ed313-c21f-4683-8b5b-013a3ecd4081"}
[2026-05-07 13:22:57] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"twilio:recover-tracks","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"93d3bd4f-fe02-4d22-aab9-00c74309e94c","trace_id":"356db0f7-0c25-4739-8c8b-a55ba28e1df0"}
[2026-05-07 13:22:57] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"twilio:recover-tracks","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"93d3bd4f-fe02-4d22-aab9-00c74309e94c","trace_id":"356db0f7-0c25-4739-8c8b-a55ba28e1df0"}
[2026-05-07 13:23:00] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:sync-users","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"connect-and-sell"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Start user synchronisation {"provider":"justcall","teams_count":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Synchronising team {"provider":"justcall","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.WARNING: [Salesforce] Account not connected for user {"userId":"cdf9285a-8ded-4a8b-bd7d-ec68c398f2f9","account":{"Jiminny\\Models\\SocialAccount":{"id":1367,"sociable_id":1071,"provider_user_id":"005O4000003s5c7IAA","expires":null,"refresh_token_expires":null,"provider":"salesforce","state":"full-refresh","auth_scope":"refresh_token web api","retry_after":null,"created_at":"2024-09-10 07:05:21","updated_at":"2026-01-14 07:00:58"}}} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] Integration owner is not connected, attempting team members {"crm_provider":"salesforce","crm_owner":1071,"team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] No team members found with active crm connection {"crm_provider":"salesforce","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] No team member found with active crm connection {"crm_provider":"salesforce","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.WARNING: Failed to sync external users {"message":"Your Salesforce account has become disconnected. Please login to Jiminny to reconnect.","provider":"justcall","team_id":1,"team":"jiminny"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"ringcentral"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"avaya"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"telus"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"salesloft"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"talkdesk"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"vonage"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Done {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:sync-users","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:24:05] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:05] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:05] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:07] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"a2d53fd0-ef62-42d7-bf03-2b78fe690081","trace_id":"ccc71cd2-62d3-4641-bbef-d3ac924250df"}
[2026-05-07 13:24:07] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"a2d53fd0-ef62-42d7-bf03-2b78fe690081","trace_id":"ccc71cd2-62d3-4641-bbef-d3ac924250df"}
[2026-05-07 13:24:09] local.NOTICE: Monitoring start {"correlation_id":"550636b7-858f-4d9a-a78c-1a4464ffe5d6","trace_id":"3a5f8440-816e-420f-a5a4-40ad67ca1542"}
[2026-05-07 13:24:09] local.NOTICE: Monitoring end {"correlation_id":"550636b7-858f-4d9a-a78c-1a4464ffe5d6","trace_id":"3a5f8440-816e-420f-a5a4-40ad67ca1542"}
[2026-05-07 13:24:10] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"97b9a580-2259-4931-82fd-86db94dccd2f","trace_id":"1809cb02-fcd4-4cf7-b426-2fe2cf347fb0"}
[2026-05-07 13:24:11] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"97b9a580-2259-4931-82fd-86db94dccd2f","trace_id":"1809cb02-fcd4-4cf7-b426-2fe2cf347fb0"}
[2026-05-07 13:24:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: Running conference:monitor:count command for activities in (2026-05-07 13:22:00, 2026-05-07 13:24:00] {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: [conference:monitor:count] No activities found in (2026-05-07 13:22:00, 2026-05-07 13:24:00] {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:aircall:check-and-renew","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [SocialAccountService] Fetching token {"socialAccountId":1496,"provider":"aircall"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [SocialAccountService] Token retrieved {"socialAccountId":1496,"provider":"aircall"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.ERROR: [Aircall] Re-activating webhooks failed {"team_id":1,"reason":"{\"message\":\"Forbidden\"}"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:aircall:check-and-renew","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:19] local.INFO: [RetryFailedDownloads] Starting {"options":{"from":null,"to":null,"help":false,"silent":false,"quiet":false,"verbose":false,"version":false,"ansi":null,"no-interaction":false,"env":null}} {"correlation_id":"df682399-d6b7-464b-9aea-85a4d7b10c27","trace_id":"532cf674-cebb-4b99-9190-d3020576b5db"}
[2026-05-07 13:25:06] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:06] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:06] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:08] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"846be41a-5d95-4144-ad3c-273defc37bea","trace_id":"8e158a4b-31e7-4161-af5e-d83f2ad2f3b5"}
[2026-05-07 13:25:08] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"846be41a-5d95-4144-ad3c-273defc37bea","trace_id":"8e158a4b-31e7-4161-af5e-d83f2ad2f3b5"}
[2026-05-07 13:25:11] local.NOTICE: Monitoring start {"correlation_id":"779be55d-57e0-4a33-8d13-cb3fda9c8ce5","trace_id":"4eaf7c2a-5a99-4c32-9fb9-b1377cacdebb"}
[2026-05-07 13:25:11] local.NOTICE: Monitoring end {"correlation_id":"779be55d-57e0-4a33-8d13-cb3fda9c8ce5","trace_id":"4eaf7c2a-5a99-4c32-9fb9-b1377cacdebb"}
[2026-05-07 13:25:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"75ba5939-1152-41ac-bed9-e3c203b981c3","trace_id":"f8537beb-7cb8-4f02-ab66-07754746b812"}
[2026-05-07 13:25:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"75ba5939-1152-41ac-bed9-e3c203b981c3","trace_id":"f8537beb-7cb8-4f02-ab66-07754746b812"}
[2026-05-07 13:25:19] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:21] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:purge-stale","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"3c03ff8f-9391-46b3-9001-5d3e3f364d29","trace_id":"5c5f2a08-7eb1-4eb3-9754-cde3f0425216"}
[2026-05-07 13:25:21] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:purge-stale","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"3c03ff8f-9391-46b3-9001-5d3e3f364d29","trace_id":"5c5f2a08-7eb1-4eb3-9754-cde3f0425216"}
[2026-05-07 13:25:23] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:text-relay:sync","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"640405cd-fddb-4ae4-ab6b-0da9052b22fa","trace_id":"0f39ab5c-c1aa-4aa1-a71c-b62823493c4e"}
[2026-05-07 13:25:23] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:text-relay:sync","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"640405cd-fddb-4ae4-ab6b-0da9052b22fa","trace_id":"0f39ab5c-c1aa-4aa1-a71c-b62823493c4e"}
[2026-05-07 13:25:26] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:pre-meeting-notification","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:26] local.INFO: Running pre-meeting notification command {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:26] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:pre-meeting-notification","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:29] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:start","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: Running conference:monitor:start command for activities in (2026-05-07 13:15:00, 2026-05-07 13:20:00] {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: [conference:monitor:start] No activities found in (2026-05-07 13:15:00, 2026-05-07 13:20:00] {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:start","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:37] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:end","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: conference:monitor:end:Jiminny\Console\Commands\Activities\MonitorMeetingEndCommand::logActivitiesEnded {"from":"13:20","to":"13:25"} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: conference:monitor:end:Jiminny\Console\Commands\Activities\MonitorMeetingEndCommand::logActivitiesWithUnfinishedSession {"from":"03:15","to":"03:20"} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:end","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:41] local.NOTICE: Repairing HubSpot tokens start {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: Trying to refresh HubSpot token {"account_id":59,"updated_at":"2025-10-03 09:32:05"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":59,"provider":"hubspot","refreshToken":"97b78f6e2cc49965c00c2492b602b02708b1392551e6b3f113fbaa48992af90b","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.ERROR: Failed to refresh HubSpot token {"account_id":59,"updated_at":"2025-10-03 09:32:05","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: Trying to refresh HubSpot token {"account_id":306,"updated_at":"2023-11-27 09:30:03"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":306,"provider":"hubspot","refreshToken":"6fa6aa8cc641d131231acc3470f5c03cb3b07b2e580fb18f8acb3b1dbb72549b","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.ERROR: Failed to refresh HubSpot token {"account_id":306,"updated_at":"2023-11-27 09:30:03","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: Trying to refresh HubSpot token {"account_id":1372,"updated_at":"2025-10-02 14:47:06"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":1372,"provider":"hubspot","refreshToken":"9aa73948c761da29dce46c177cf9aee1fde483a44169ca38723f9f0597d7a8c4","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.ERROR: Failed to refresh HubSpot token {"account_id":1372,"updated_at":"2025-10-02 14:47:06","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.NOTICE: Repairing HubSpot tokens end {"total":3,"fixed":0,"failed":3} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:pre-meeting-reminder","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"2775b4f9-6dce-40a2-84ad-fb7f3a2729ed","trace_id":"89eb011f-145e-44f2-a376-0c57cf42c11d"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"crm:bullhorn:ping","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"1b0300f0-a82f-4bf2-b5dc-24e9d04babab","trace_id":"af7b7ef6-7376-48fe-b7b9-a5ad41237fa4"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"crm:bullhorn:ping","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id...
|
PhpStorm
|
faVsco.js β RateLimitException.php
|
NULL
|
4324
|
|
4323
|
Search
\Tests\Unit\Component\AiActivityType\Servic Search
\Tests\Unit\Component\AiActivityType\Services
\Tests\Unit\Jobs\Crm
\Tests\Unit\Jobs\Crm
\Tests\Unit\Jobs\Crm
\Tests\Unit\Jobs\Crm
\Tests\Unit\Jobs\Crm
ActivityLanguageCodeMissingException \Jiminny\Component\ProphetAi\Exceptions
\Tests\Unit\Jobs\Crm
ActivityProviderException \Jiminny\Exceptions
ActivityProviderException \Jiminny\Exceptions
ApiException \Jiminny\Exceptions
ApiException \Jiminny\Exceptions
ApiException \Jiminny\Services\Activity\Vonage\Exception
ApiException \Jiminny\Services\Activity\Vonage\Exception
ApiResponseException \Jiminny\Exceptions
ApiResponseException \Jiminny\Exceptions
ApplicationException \Jiminny\Exceptions
ApplicationException \Jiminny\Exceptions
AskJiminnyException \Jiminny\Component\AskJiminnyAi\Exceptions
AskJiminnyException \Jiminny\Component\AskJiminnyAi\Exceptions
AsyncElasticSearchUpdateChunkFailed \Jiminny\Exceptions
AsyncElasticSearchUpdateChunkFailed \Jiminny\Exceptions
BadKeywordsQueryException \Jiminny\Exceptions
BadKeywordsQueryException \Jiminny\Exceptions
BadResponseException \Jiminny\Services\Activity\Talkdesk\Exception
BadResponseException \Jiminny\Services\Activity\Talkdesk\Exception
BadResponseException \Jiminny\Services\Activity\Vonage\Exception
BadResponseException \Jiminny\Services\Activity\Vonage\Exception
CalculateSilenceException \Jiminny\Component\Encoding\Exceptions
CalculateSilenceException \Jiminny\Component\Encoding\Exceptions
CloseException \Jiminny\Services\Crm\Close
CloseException \Jiminny\Services\Crm\Close
ConfigurationException \Jiminny\Component\BillingManagement\Exception
ConfigurationException \Jiminny\Component\BillingManagement\Exception
ConfigurationException \Jiminny\Exceptions
ConfigurationException \Jiminny\Exceptions
ContentLengthNotFoundInResponseException \Jiminny\Component\Uploader\Exceptions
ContentLengthNotFoundInResponseException \Jiminny\Component\Uploader\Exceptions
CopperException \Jiminny\Services\Crm\Copper\Exception
CopperException \Jiminny\Services\Crm\Copper\Exception
CrmConnectionExpired \Jiminny\Component\Twilio\Exception
CrmConnectionExpired \Jiminny\Component\Twilio\Exception
CrmException \Jiminny\Exceptions
CrmException \Jiminny\Exceptions
CrmUpdateException \Jiminny\Exceptions
CrmUpdateException \Jiminny\Exceptions
DatabaseException \Jiminny\Exceptions
DatabaseException \Jiminny\Exceptions
DateTimeException \Jiminny\Component\BillingManagement\Exception
DateTimeException \Jiminny\Component\BillingManagement\Exception
DealRisksException \Jiminny\Exceptions
DealRisksException \Jiminny\Exceptions
DomainException \Jiminny\Exceptions
DomainException \Jiminny\Exceptions
DownloadRecordingException \Jiminny\Services\Activity\JustCall
DownloadRecordingException \Jiminny\Services\Activity\JustCall
DuplicateUploadException \Jiminny\Component\Uploader\Exceptions
DuplicateUploadException \Jiminny\Component\Uploader\Exceptions
EmailActivityImportException \Jiminny\Exceptions
EmailActivityImportException \Jiminny\Exceptions
EnvironmentMismatchException \Jiminny\Http\AccessTokenProvider
EnvironmentMismatchException \Jiminny\Http\AccessTokenProvider
ErrorDownloadingEmptyFileException \Jiminny\Exceptions
ErrorDownloadingEmptyFileException \Jiminny\Exceptions
ErrorDownloadingFileException \Jiminny\Exceptions
ErrorDownloadingFileException \Jiminny\Exceptions
FFMpegException \Jiminny\Component\FFMpeg\Exceptions
FFMpegException \Jiminny\Component\FFMpeg\Exceptions
FFProbeException \Jiminny\Component\FFMpeg\Exceptions
FFProbeException \Jiminny\Component\FFMpeg\Exceptions
FailedToDownloadRecordingException \Jiminny\Services\Activity\Outreach\Recordings
FailedToDownloadRecordingException \Jiminny\Services\Activity\Outreach\Recordings
FileNotFoundException \Jiminny\Exceptions
FileNotFoundException \Jiminny\Exceptions
FileSystemException \Jiminny\Exceptions
FileSystemException \Jiminny\Exceptions
FileUrlLocationNotFoundInResponseException \Jiminny\Component\Uploader\Exceptions
FileUrlLocationNotFoundInResponseException \Jiminny\Component\Uploader\Exceptions
FlipParticipantsDoNotBelongToActivityException \Jiminny\Component\ParticipantSpeech\Exceptions
FlipParticipantsDoNotBelongToActivityException \Jiminny\Component\ParticipantSpeech\Exceptions
GeneralActivityComponentException \Jiminny\Component\Activity\Exceptions
GeneralActivityComponentException \Jiminny\Component\Activity\Exceptions
GenericAiAutomationException \Jiminny\Component\AiAutomation\Exceptions
GenericAiAutomationException \Jiminny\Component\AiAutomation\Exceptions
GenericParticipantSpeechException \Jiminny\Component\ParticipantSpeech\Exceptions
GenericParticipantSpeechException \Jiminny\Component\ParticipantSpeech\Exceptions
GenericSlackErrorException \Jiminny\Component\Slack\Exceptions
GenericSlackErrorException \Jiminny\Component\Slack\Exceptions
GenericUploaderException \Jiminny\Component\Uploader\Exceptions
GenericUploaderException \Jiminny\Component\Uploader\Exceptions
GladiaException \Jiminny\Component\Transcription\TranscriptionProcessor\Gladia\Exceptions
GladiaException \Jiminny\Component\Transcription\TranscriptionProcessor\Gladia\Exceptions
HttpBadRequestException \Jiminny\Exceptions
HttpBadRequestException \Jiminny\Exceptions
HttpBadRequestWithErrorReasonException \Jiminny\Exceptions
HttpBadRequestWithErrorReasonException \Jiminny\Exceptions
HttpException \Jiminny\Component\BillingManagement\Exception
HttpException \Jiminny\Component\BillingManagement\Exception
HttpForbiddenException \Jiminny\Exceptions
HttpForbiddenException \Jiminny\Exceptions
HttpMethodNotAllowedException \Jiminny\Exceptions
HttpMethodNotAllowedException \Jiminny\Exceptions
HttpNotFoundException \Jiminny\Exceptions
HttpNotFoundException \Jiminny\Exceptions
HttpSessionExpiredException \Jiminny\Exceptions
HttpSessionExpiredException \Jiminny\Exceptions
HttpUnauthorizedException \Jiminny\Exceptions...
|
PhpStorm
|
|
NULL
|
4323
|
|
4322
|
Project: faVsco.js, menu
master, menu
Start Listen Project: faVsco.js, menu
master, menu
Start Listening for PHP Debug Connections
AskJiminnyReportActivityServiceTest
Run 'AskJiminnyReportActivityServiceTest'
Debug 'AskJiminnyReportActivityServiceTest'
More Actions
JetBrains AI
Search Everywhere
IDE and Project Settings
Sync Changes
Hide This Notification
Code changed:
Hide
286
Previous Highlighted Error
Next Highlighted Error
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Fetching token {"socialAccountId":1499,"provider":"hubspot"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Token needs refreshing {"socialAccountId":1499,"provider":"hubspot"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":1499,"provider":"hubspot","refreshToken":"96f94c623a404e02ebdbf07f1b75707bb6cdbf848cbf45d418baf608c41a8d86","state":"connected"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountObserver] Saving model {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:12] local.INFO: [SocialAccountObserver] Access token was modified, encrypting {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [SocialAccountService] Token refreshed {"socialAccountId":1499,"provider":"hubspot","state":"connected"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [CrmOwnerResolver] Integration owner matched as CRM Owner {"crm_provider":"hubspot","crm_owner":148,"team_id":2} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: [Hubspot] Received 429 from API {"team_id":2,"config_id":2,"retry_after":10,"reason":"Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.ERROR: Hubspot returned 429 {"exception":"[object] (Jiminny\\Exceptions\\RateLimitException(code: 0): Hubspot returned 429 at /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php:206)
[stacktrace]
#0 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#1 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#2 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#3 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#4 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#5 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#6 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#7 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#8 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#9 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#10 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#11 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#12 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#13 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#14 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#15 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#16 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#17 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#18 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#19 {main}
[previous exception] [object] (SevenShores\\Hubspot\\Exceptions\\BadRequest(code: 429): Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
at /home/jiminny/vendor/hubspot/hubspot-php/src/Exceptions/HubspotException.php:24)
[stacktrace]
#0 /home/jiminny/vendor/hubspot/hubspot-php/src/Http/Client.php(125): SevenShores\\Hubspot\\Exceptions\\HubspotException::create(Object(GuzzleHttp\\Exception\\ClientException))
#1 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(166): SevenShores\\Hubspot\\Http\\Client->request('POST', 'https://api.hub...', Array)
#2 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#3 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#4 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#5 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#6 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#7 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#8 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#9 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#10 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#11 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#12 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#13 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#14 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#15 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#16 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#17 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#18 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#19 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#20 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#21 {main}
[previous exception] [object] (GuzzleHttp\\Exception\\ClientException(code: 429): Client error: `POST https://api.hubapi.com/crm/v3/objects/contact/search` resulted in a `429 Too Many Requests` response:
{\"status\":\"error\",\"message\":\"You have reached your secondly limit.\",\"errorType\":\"RATE_LIMIT\",\"correlationId\":\"019e029a-6 (truncated...)
at /home/jiminny/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:111)
[stacktrace]
#0 /home/jiminny/vendor/guzzlehttp/guzzle/src/Middleware.php(72): GuzzleHttp\\Exception\\RequestException::create(Object(GuzzleHttp\\Psr7\\Request), Object(GuzzleHttp\\Psr7\\Response), NULL, Array, NULL)
#1 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(209): GuzzleHttp\\Middleware::GuzzleHttp\\{closure}(Object(GuzzleHttp\\Psr7\\Response))
#2 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(158): GuzzleHttp\\Promise\\Promise::callHandler(1, Object(GuzzleHttp\\Psr7\\Response), NULL)
#3 /home/jiminny/vendor/guzzlehttp/promises/src/TaskQueue.php(52): GuzzleHttp\\Promise\\Promise::GuzzleHttp\\Promise\\{closure}()
#4 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(251): GuzzleHttp\\Promise\\TaskQueue->run(true)
#5 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(227): GuzzleHttp\\Promise\\Promise->invokeWaitFn()
#6 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(272): GuzzleHttp\\Promise\\Promise->waitIfPending()
#7 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(229): GuzzleHttp\\Promise\\Promise->invokeWaitList()
#8 /home/jiminny/vendor/guzzlehttp/promises/src/Promise.php(69): GuzzleHttp\\Promise\\Promise->waitIfPending()
#9 /home/jiminny/vendor/guzzlehttp/guzzle/src/Client.php(189): GuzzleHttp\\Promise\\Promise->wait()
#10 /home/jiminny/vendor/hubspot/hubspot-php/src/Http/Client.php(113): GuzzleHttp\\Client->request('POST', 'https://api.hub...', Array)
#11 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(166): SevenShores\\Hubspot\\Http\\Client->request('POST', 'https://api.hub...', Array)
#12 /home/jiminny/app/Services/Crm/Hubspot/Pagination/HubspotPaginationService.php(52): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->executeSearchRequest(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), 'https://api.hub...', Array, Object(Jiminny\\Services\\Crm\\Hubspot\\Pagination\\PaginationState))
#13 /home/jiminny/app/Services/Crm/Hubspot/Client.php(176): Jiminny\\Services\\Crm\\Hubspot\\Pagination\\HubspotPaginationService->getPaginatedDataGenerator(Object(Jiminny\\Services\\Crm\\Hubspot\\Client), Array, 'contact', 0, 0, NULL)
#14 /home/jiminny/app/Services/Crm/Hubspot/Service.php(1203): Jiminny\\Services\\Crm\\Hubspot\\Client->getPaginatedData(Array, 'contact')
#15 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(353): Jiminny\\Services\\Crm\\Hubspot\\Service->matchByName('Robot')
#16 /home/jiminny/app/Console/Commands/JiminnyDebugCommand.php(44): Jiminny\\Console\\Commands\\JiminnyDebugCommand->rateLimit()
#17 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Jiminny\\Console\\Commands\\JiminnyDebugCommand->handle(Object(Jiminny\\Jobs\\JobDispatcher), Object(Jiminny\\Services\\Kiosk\\AutomatedReports\\AutomatedReportsService), Object(Jiminny\\Repositories\\AutomatedReportsRepository), Object(Jiminny\\Services\\UserPilot\\UserPilotClient))
#18 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#19 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#20 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#21 /home/jiminny/vendor/laravel/framework/src/Illuminate/Container/Container.php(799): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#22 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(211): Illuminate\\Container\\Container->call(Array)
#23 /home/jiminny/vendor/symfony/console/Command/Command.php(341): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#24 /home/jiminny/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#25 /home/jiminny/vendor/symfony/console/Application.php(1117): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#26 /home/jiminny/vendor/symfony/console/Application.php(356): Symfony\\Component\\Console\\Application->doRunCommand(Object(Jiminny\\Console\\Commands\\JiminnyDebugCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#27 /home/jiminny/vendor/symfony/console/Application.php(195): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#28 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#29 /home/jiminny/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1235): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#30 /home/jiminny/artisan(13): Illuminate\\Foundation\\Application->handleCommand(Object(Symfony\\Component\\Console\\Input\\ArgvInput))
#31 {main}
"} {"correlation_id":"343f341d-028f-4c8c-9578-252fcde6e04c","trace_id":"41071c00-9712-46eb-8acf-d5c4298fea69"}
[2026-05-07 13:22:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:13] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"42c3d939-2b42-4fa8-9f57-cbdc5bb1457c","trace_id":"b9aec736-45fd-47fc-9482-fd558ed6227a"}
[2026-05-07 13:22:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"076c3e6b-6a67-4774-8aa0-2a84fcf5e03c","trace_id":"284e571d-ab92-4e22-b09b-c151c2871cb4"}
[2026-05-07 13:22:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"076c3e6b-6a67-4774-8aa0-2a84fcf5e03c","trace_id":"284e571d-ab92-4e22-b09b-c151c2871cb4"}
[2026-05-07 13:22:19] local.NOTICE: Monitoring start {"correlation_id":"c41d4048-0465-4dcf-bb53-176287732e3e","trace_id":"9ce4a71c-a1a0-456e-843d-38fd15e5c798"}
[2026-05-07 13:22:19] local.NOTICE: Monitoring end {"correlation_id":"c41d4048-0465-4dcf-bb53-176287732e3e","trace_id":"9ce4a71c-a1a0-456e-843d-38fd15e5c798"}
[2026-05-07 13:22:30] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"934766d6-40c0-415c-bd51-d0b67a799c7c","trace_id":"d6c773e8-adf4-453b-8a17-077bf7bdf698"}
[2026-05-07 13:22:30] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"934766d6-40c0-415c-bd51-d0b67a799c7c","trace_id":"d6c773e8-adf4-453b-8a17-077bf7bdf698"}
[2026-05-07 13:22:35] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:35] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"b99dafc3-0e7f-4cb3-9469-9a18bd4d8a72","trace_id":"3ca2e911-32f2-4c22-89ba-aae5e8342c8d"}
[2026-05-07 13:22:41] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: Running conference:monitor:count command for activities in (2026-05-07 13:20:00, 2026-05-07 13:22:00] {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: [conference:monitor:count] No activities found in (2026-05-07 13:20:00, 2026-05-07 13:22:00] {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:41] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"b8b1efaa-e359-4aa1-942d-2dc8ca6c048b","trace_id":"897fc576-4657-4534-ac78-73f6c44cbeef"}
[2026-05-07 13:22:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:create","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: [EmailSchedule] STARTING batch create {"host":"docker_lamp_1"} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: [EmailSchedule] FINISHED batch create {"host":"docker_lamp_1"} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:create","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"08dc0025-4642-4d21-a351-c0dee099d6fc","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:52] local.INFO: [Jiminny\Jobs\Mailbox\CreateBatches] processed 2 inboxes and created 0 batches {"userId":null,"batchSize":30,"maxBatches":1000} {"correlation_id":"13eed139-b218-43c9-b147-38ae92c45977","trace_id":"b0e009f0-3c67-4281-87ce-4ccdc1ab3055"}
[2026-05-07 13:22:53] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:sync","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"cf9df816-4614-4a06-b853-4d6815fb85e1","trace_id":"ca6ed313-c21f-4683-8b5b-013a3ecd4081"}
[2026-05-07 13:22:53] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:sync","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"cf9df816-4614-4a06-b853-4d6815fb85e1","trace_id":"ca6ed313-c21f-4683-8b5b-013a3ecd4081"}
[2026-05-07 13:22:57] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"twilio:recover-tracks","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"93d3bd4f-fe02-4d22-aab9-00c74309e94c","trace_id":"356db0f7-0c25-4739-8c8b-a55ba28e1df0"}
[2026-05-07 13:22:57] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"twilio:recover-tracks","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"93d3bd4f-fe02-4d22-aab9-00c74309e94c","trace_id":"356db0f7-0c25-4739-8c8b-a55ba28e1df0"}
[2026-05-07 13:23:00] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:sync-users","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"connect-and-sell"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Start user synchronisation {"provider":"justcall","teams_count":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Synchronising team {"provider":"justcall","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.WARNING: [Salesforce] Account not connected for user {"userId":"cdf9285a-8ded-4a8b-bd7d-ec68c398f2f9","account":{"Jiminny\\Models\\SocialAccount":{"id":1367,"sociable_id":1071,"provider_user_id":"005O4000003s5c7IAA","expires":null,"refresh_token_expires":null,"provider":"salesforce","state":"full-refresh","auth_scope":"refresh_token web api","retry_after":null,"created_at":"2024-09-10 07:05:21","updated_at":"2026-01-14 07:00:58"}}} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] Integration owner is not connected, attempting team members {"crm_provider":"salesforce","crm_owner":1071,"team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] No team members found with active crm connection {"crm_provider":"salesforce","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: [CrmOwnerResolver] No team member found with active crm connection {"crm_provider":"salesforce","team_id":1} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.WARNING: Failed to sync external users {"message":"Your Salesforce account has become disconnected. Please login to Jiminny to reconnect.","provider":"justcall","team_id":1,"team":"jiminny"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"ringcentral"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"avaya"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"telus"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"salesloft"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"talkdesk"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Skip provider synchronisation, no teams found {"provider":"vonage"} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Done {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:23:00] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:sync-users","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"fb2297ef-3768-4c39-a39d-8d56cc5f19fd","trace_id":"f5f44e82-383e-4e36-b898-5e6a6bb73621"}
[2026-05-07 13:24:05] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:05] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:05] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"e4823ff8-4b94-4b35-81dd-b4b0c6c33224","trace_id":"3927c06e-924a-4ccf-aec1-7527a88db4b7"}
[2026-05-07 13:24:07] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"a2d53fd0-ef62-42d7-bf03-2b78fe690081","trace_id":"ccc71cd2-62d3-4641-bbef-d3ac924250df"}
[2026-05-07 13:24:07] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"a2d53fd0-ef62-42d7-bf03-2b78fe690081","trace_id":"ccc71cd2-62d3-4641-bbef-d3ac924250df"}
[2026-05-07 13:24:09] local.NOTICE: Monitoring start {"correlation_id":"550636b7-858f-4d9a-a78c-1a4464ffe5d6","trace_id":"3a5f8440-816e-420f-a5a4-40ad67ca1542"}
[2026-05-07 13:24:09] local.NOTICE: Monitoring end {"correlation_id":"550636b7-858f-4d9a-a78c-1a4464ffe5d6","trace_id":"3a5f8440-816e-420f-a5a4-40ad67ca1542"}
[2026-05-07 13:24:10] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"97b9a580-2259-4931-82fd-86db94dccd2f","trace_id":"1809cb02-fcd4-4cf7-b426-2fe2cf347fb0"}
[2026-05-07 13:24:11] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"97b9a580-2259-4931-82fd-86db94dccd2f","trace_id":"1809cb02-fcd4-4cf7-b426-2fe2cf347fb0"}
[2026-05-07 13:24:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:13] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"3b0ce230-1556-40b0-86c2-adcd640e0031","trace_id":"daaa38cb-2236-485a-bce0-2903bea27543"}
[2026-05-07 13:24:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: Running conference:monitor:count command for activities in (2026-05-07 13:22:00, 2026-05-07 13:24:00] {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: [conference:monitor:count] No activities found in (2026-05-07 13:22:00, 2026-05-07 13:24:00] {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:count","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"5e954d31-bae9-402a-8d1a-69ed8656bcaf","trace_id":"3a651475-e65f-4f45-bfc6-dc2a321794ca"}
[2026-05-07 13:24:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:aircall:check-and-renew","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [SocialAccountService] Fetching token {"socialAccountId":1496,"provider":"aircall"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [SocialAccountService] Token retrieved {"socialAccountId":1496,"provider":"aircall"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.ERROR: [Aircall] Re-activating webhooks failed {"team_id":1,"reason":"{\"message\":\"Forbidden\"}"} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:17] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:aircall:check-and-renew","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"64fdf422-e2d7-4ca1-9b11-1f11bd7a7cbb","trace_id":"da669f79-4ec8-4092-bf4c-0c4bfd80a23e"}
[2026-05-07 13:24:19] local.INFO: [RetryFailedDownloads] Starting {"options":{"from":null,"to":null,"help":false,"silent":false,"quiet":false,"verbose":false,"version":false,"ansi":null,"no-interaction":false,"env":null}} {"correlation_id":"df682399-d6b7-464b-9aea-85a4d7b10c27","trace_id":"532cf674-cebb-4b99-9190-d3020576b5db"}
[2026-05-07 13:25:06] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:06] local.INFO: [ScheduleBotCommand] Number of activities to be captured: 0 {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:06] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"meeting-bot:schedule-bot","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"aca15380-d0fd-443c-ac7e-ec11c07c82ab","trace_id":"d281a9be-34bb-452d-9a26-acd05f2fa5fb"}
[2026-05-07 13:25:08] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"846be41a-5d95-4144-ad3c-273defc37bea","trace_id":"8e158a4b-31e7-4161-af5e-d83f2ad2f3b5"}
[2026-05-07 13:25:08] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"dialers:monitor-activities","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"846be41a-5d95-4144-ad3c-273defc37bea","trace_id":"8e158a4b-31e7-4161-af5e-d83f2ad2f3b5"}
[2026-05-07 13:25:11] local.NOTICE: Monitoring start {"correlation_id":"779be55d-57e0-4a33-8d13-cb3fda9c8ce5","trace_id":"4eaf7c2a-5a99-4c32-9fb9-b1377cacdebb"}
[2026-05-07 13:25:11] local.NOTICE: Monitoring end {"correlation_id":"779be55d-57e0-4a33-8d13-cb3fda9c8ce5","trace_id":"4eaf7c2a-5a99-4c32-9fb9-b1377cacdebb"}
[2026-05-07 13:25:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"75ba5939-1152-41ac-bed9-e3c203b981c3","trace_id":"f8537beb-7cb8-4f02-ab66-07754746b812"}
[2026-05-07 13:25:15] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:skip-lists:refresh","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"75ba5939-1152-41ac-bed9-e3c203b981c3","trace_id":"f8537beb-7cb8-4f02-ab66-07754746b812"}
[2026-05-07 13:25:19] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: [EmailSchedule] STARTING batch process {"host":"docker_lamp_1"} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: [EmailSchedule] FINISHED batch process {"host":"docker_lamp_1","processed":0} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:19] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:batch:process","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"35858849-c9e7-44d7-ac0f-c7b3eecd1a3a","trace_id":"1b5d36d1-4a99-49e1-8ef3-9085383ae098"}
[2026-05-07 13:25:21] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"activity:purge-stale","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"3c03ff8f-9391-46b3-9001-5d3e3f364d29","trace_id":"5c5f2a08-7eb1-4eb3-9754-cde3f0425216"}
[2026-05-07 13:25:21] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"activity:purge-stale","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"3c03ff8f-9391-46b3-9001-5d3e3f364d29","trace_id":"5c5f2a08-7eb1-4eb3-9754-cde3f0425216"}
[2026-05-07 13:25:23] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"mailbox:text-relay:sync","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"640405cd-fddb-4ae4-ab6b-0da9052b22fa","trace_id":"0f39ab5c-c1aa-4aa1-a71c-b62823493c4e"}
[2026-05-07 13:25:23] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"mailbox:text-relay:sync","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"640405cd-fddb-4ae4-ab6b-0da9052b22fa","trace_id":"0f39ab5c-c1aa-4aa1-a71c-b62823493c4e"}
[2026-05-07 13:25:26] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:pre-meeting-notification","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:26] local.INFO: Running pre-meeting notification command {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:26] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:pre-meeting-notification","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"26ef1aeb-f591-43d4-ab0c-4fa8dd165273","trace_id":"d8d3e856-4c59-4dc5-b4d7-0e9fc2f8b9d4"}
[2026-05-07 13:25:29] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:start","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: Running conference:monitor:start command for activities in (2026-05-07 13:15:00, 2026-05-07 13:20:00] {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: [conference:monitor:start] No activities found in (2026-05-07 13:15:00, 2026-05-07 13:20:00] {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:29] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:start","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"52732df6-3bc1-4401-a830-66f07383aa16","trace_id":"0f0c7d16-ddae-47c4-b32c-f46c6b2d9496"}
[2026-05-07 13:25:37] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:monitor:end","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: conference:monitor:end:Jiminny\Console\Commands\Activities\MonitorMeetingEndCommand::logActivitiesEnded {"from":"13:20","to":"13:25"} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: conference:monitor:end:Jiminny\Console\Commands\Activities\MonitorMeetingEndCommand::logActivitiesWithUnfinishedSession {"from":"03:15","to":"03:20"} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:37] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"conference:monitor:end","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id":"5e8ebebd-f953-4c7f-92eb-0c9ccb91769b","trace_id":"647ac71c-b02e-42a2-80c4-a004eecd1f05"}
[2026-05-07 13:25:41] local.NOTICE: Repairing HubSpot tokens start {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: Trying to refresh HubSpot token {"account_id":59,"updated_at":"2025-10-03 09:32:05"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":59,"provider":"hubspot","refreshToken":"97b78f6e2cc49965c00c2492b602b02708b1392551e6b3f113fbaa48992af90b","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.ERROR: Failed to refresh HubSpot token {"account_id":59,"updated_at":"2025-10-03 09:32:05","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: Trying to refresh HubSpot token {"account_id":306,"updated_at":"2023-11-27 09:30:03"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:41] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":306,"provider":"hubspot","refreshToken":"6fa6aa8cc641d131231acc3470f5c03cb3b07b2e580fb18f8acb3b1dbb72549b","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.ERROR: Failed to refresh HubSpot token {"account_id":306,"updated_at":"2023-11-27 09:30:03","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: Trying to refresh HubSpot token {"account_id":1372,"updated_at":"2025-10-02 14:47:06"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: [EncryptedTokenManager] Generating access token. {"mode":"legacy"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.INFO: [SocialAccountService] Refreshing token from provider {"socialAccountId":1372,"provider":"hubspot","refreshToken":"9aa73948c761da29dce46c177cf9aee1fde483a44169ca38723f9f0597d7a8c4","state":"full-refresh"} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.ERROR: Failed to refresh HubSpot token {"account_id":1372,"updated_at":"2025-10-02 14:47:06","reason":"missing or invalid refresh token","previous":""} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:42] local.NOTICE: Repairing HubSpot tokens end {"total":3,"fixed":0,"failed":3} {"correlation_id":"6ec66e54-ca2e-4f58-a47d-b72ed5fbb13f","trace_id":"e6017fa4-1986-4c9e-9e8d-2f9baa13d9c6"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"conference:pre-meeting-reminder","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"2775b4f9-6dce-40a2-84ad-fb7f3a2729ed","trace_id":"89eb011f-145e-44f2-a376-0c57cf42c11d"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage before starting command {"command":"crm:bullhorn:ping","memoryBeforeCommandInMb":62.0,"memoryPeakBeforeCommandInMb":99.727} {"correlation_id":"1b0300f0-a82f-4bf2-b5dc-24e9d04babab","trace_id":"af7b7ef6-7376-48fe-b7b9-a5ad41237fa4"}
[2026-05-07 13:25:49] local.INFO: Jiminny\Console\Commands\Command::run Memory usage for command {"command":"crm:bullhorn:ping","memoryBeforeCommandInMb":62.0,"memoryAfterCommandInMB":62.0,"memoryPeakBeforeCommandInMb":99.727,"memoryPeakAfterCommandInMB":99.727} {"correlation_id...
|
PhpStorm
|
faVsco.js β Client.php
|
NULL
|
4322
|