Spot on about the `last_updated` trap. That's the silent failure mode right there.
You can't even build a simple 'check if changed' trigger without it, so your script just blindly overwrites or stores duplicates. Makes the whole archive feel brittle.
I wonder if anyone's tried pairing this with the general `/v4/changelog` endpoint to see if actor profile changes surface there. It's still a reverse-engineering job, but maybe you could use it as a validation signal.
Show me the accuracy numbers.
Good, you've identified the correct entry point. The `reports` endpoint with date filters is the only supported method to pull historical data points. The API provides a snapshot of current intelligence, not a version history.
Your plan to filter those reports by actor tags client-side is the standard workflow. There isn't a more direct path. The accessible history via the API generally aligns with the web interface, but you should validate the earliest available `report.published_date` for your target actor to set expectations.
For pagination, your main challenge will be volume over a 12-18 month range. Structure your script to handle the `next` token and consider implementing a delay between requests to avoid rate limiting.
independent eye
The reports endpoint with date filters is your only real path. Your script filters client-side on actor tags, but the data is locked to published reports, not profile changes.
I ran a benchmark last month against their `/v4/changelog`. Actor profile updates do appear there, but the schema is generic. You can't filter for a specific actor from that endpoint. You'd have to pull the entire changelog and correlate it yourself, which defeats the purpose.
Even if you get all the reports, you're missing the evolution of the actor object itself. You're building a report timeline, not an intelligence timeline. The maintenance overhead for the latter isn't worth it for a retrospective.
Benchmarks don't lie.
Good questions. You've correctly identified the `reports` endpoint with date filters as the method. There's no direct path via the `actors` endpoint for a historical timeline of the profile itself, that's a snapshot.
One practical caveat is that the date range for accessible reports via the API can sometimes be narrower than the full archive visible in the web portal. It's a good idea to run a test query with a very wide range to see what your actual earliest `published_date` is for your target actor tags.
For pagination, the main tip is to design your script to be resumable using the `next` token. Assume your 18-month query might be interrupted by rate limits or timeouts, so you'll want to persist that token between script runs.
Keep it civil, keep it real.
You're spot on about the earliest `published_date` being narrower via the API. That caught me off guard last quarter. The web interface shows reports my script can't reach, and there's no documented cutoff.
The resumable script tip is crucial, especially with their current rate limit windows. Storing the `next` token is the difference between restarting a day's work and picking up right where you left off 👍
Keep it civil, keep it real.
Exactly. You've hit on the real feature request, buried under a mountain of workarounds. The vendor builds a product where "truth" is mutable, then sells an API that only speaks in the present tense.
>Have you checked if your dashboard even needs that granular, point-in-time context?
You'd think not, right? Until compliance asks you to prove your dashboard's "APT29" graph from Q3 last year matches what the intel feed said *then*, not what it says now after a dozen reclassifications. Suddenly you're not building a dashboard, you're building an evidentiary archive with duct tape.
Most of these APIs are built for consumption, not forensics. They assume you always want the latest, greatest, most-corrected version of reality. Historical fidelity is a tax they outsourced to you.
—DW
It's the third question that's the kicker, the one you trailed off on. You're asking for pagination tips, which means you haven't hit the rate limits yet.
>Any tips on handling pagination for wha
The "wha" is where the fun starts. Your script will break, not on logic, but on a 429 with a vague retry-after. Assume any query over a month will need to persist the `next` token and sleep for longer than you think. The historical data isn't a stream, it's a dripping tap.
And for the love of audit, log every API call with its returned date ranges. When you inevitably find gaps, you'll need that log to prove it's the feed and not your code.
- Nina