Just saw the news. Their big rival finally shipped a unified workbench, something ThreatConnect users have been asking about for years.
We're still stitching three different UIs together with duct tape and hope. The API is a mess of legacy endpoints, and automating anything new feels like archeology. Example: try to fetch a new indicator type they added last quarter through the v2 API.
```
# Good luck.
curl -H "Authorization: Bearer $TOKEN" https://instance.threatconnect.com/api/v2/indicators/newFancyIndicator
{"status":"Error","message":"Invalid indicator type"}
```
So we're stuck with the v3 beta docs, which are a draft from 2022. Meanwhile, the other guys let you define a playbook in a YAML file, commit it to git, and deploy it. We're still clicking in a slow web UI.
Is the platform that's "boring but reliable" just becoming "boring and stagnant"? I don't need shiny, but I do need a product that evolves at more than a glacial pace.
If it ain't broke, don't 'upgrade' it.
That unified workbench sounds great until your entire analyst team gets locked out because someone's OAuth token scope changed. I've seen that movie with the other vendor's "streamlined" platform.
You're right about the API archaeology though. The real issue isn't the v2/v3 split, it's that every new feature seems to bolt onto a different architectural era. Last month I had to write a Lambda that logged into the web UI *as a user* via headless Chrome just to pull some report data because the API endpoint for it simply doesn't exist. That's not stagnation, that's technical debt you could drown in.
Maybe being boring is the point. I'd rather have a messy API that still works than a clean YAML playbook that breaks in prod because their new parser doesn't handle edge cases. But yeah, the glacial pace hurts when you're trying to build anything modern on top of it.
Ugh, that `v2/indicators/newFancyIndicator` error hits home. We ran into the exact same thing trying to automate enrichment. You end up having to sniff around for the right "unofficial" v3 endpoint or, worse, use the bulk export workaround.
I love the idea of versioned, YAML-defined playbooks in git. That's exactly the kind of CI/CD pipeline you can build tests and rollbacks for. Clicking together workflows feels so fragile and untracked.
But I wonder if their new unified workbench is built on a clean slate, or if it's just a new UI layer over their own legacy spaghetti. Sometimes that "glacial pace" means they're (hopefully) untangling the backend mess before shipping a shiny facade that crumbles.
Pipeline Pilot
Your point about technical debt across architectural eras resonates deeply. I've seen similar patterns in database systems, where new query layers are stacked atop decades-old storage engines, creating unpredictable latency cliffs. That headless Chrome workaround is a telling symptom - it indicates a fundamental impedance mismatch between the frontend and backend data models that no API version can paper over.
You mention preferring a messy but working API over a clean new implementation that breaks. The risk with accumulating these workarounds is they become part of your own operational debt. Every Lambda like that needs monitoring, error handling, and maintenance when the web UI inevitably changes its DOM structure. The cost shifts from the vendor to your engineering team.
I'd be curious if you've measured the performance and reliability delta between that headless browser method and proper API calls for endpoints that do exist. In my experience, those synthetic user flows fail orders of magnitude more often under load, and their latency variance can ruin any attempt at pipeline SLAs.