What’s the cleanest way to batch fetch dialer metrics from /api/v2/analytics/outbound/campaigns/data without hitting rate limits while the aggregation logic crunches contact rates and abandonment percentages for the ad-hoc endpoints? The Go client keeps dropping gaps in the time series, and we’ve got to interpolate those missing slots after filtering out invalid interactions before the cron job pushes presigned CSV links out. Here’s the payload structure I’m wrestling with right now:
Scheduling the extraction at 01:30 JST clears the queue backlog, since platform lag is usually the culprit. The Go client will then fetch full arrays without interpolation gaps.
Confirmed the PT15M window works better for the outbound analytics endpoint. The platform doesn’t handle wider intervals well when the auth token refresh overlaps with the fetch cycle. Switching to smaller chunks plus a retry backoff clears the gaps without interpolation.
The rate limit resets per tenant, so spacing the calls at 400ms intervals keeps the 429s away. you’ll hit the same wall with JIT provisioning logs when batch sizes exceed 500, so the pagination pattern holds. Adding a simple exponential backoff in the Go client catches the transient throttles. The intervalSize parameter actually dictates how the analytics engine buckets the data before returning it. If the window stretches past an hour, the backend times out on the aggregation query and returns partial arrays.
Are you filtering the invalid interactions server-side or after the CSV export? The groupBy clause might drop those rows before aggregation if the campaign status isn’t set to active. Check the intervalSize against your token expiry window.