Hey everyone! I was poking around in our Hyperproof instance yesterday and noticed they've rolled out some new API endpoints for control mapping. I haven't seen much discussion about it yet.
Has anyone had a chance to test it out? I'm really curious about a few things:
* How does it compare to manual mapping or their existing CSV import? Is it a true time-saver for syncing with other GRC tools?
* What's the real-world latency like when pushing a batch of control updates? Our compliance workflows are getting more integrated, so API reliability is key.
* Any gotchas with the data model? For example, when linking controls to frameworks or evidence requests.
I'm thinking of building a small connector between this and our Jira Cloud setup to auto-create verification tasks. Would love to hear if anyone else is automating their control lifecycle or has initial impressions. The docs seem decent, but nothing beats hands-on experience! 😅
Cheers
Yeah, I've been poking at it for a couple weeks now. It's mostly a structured JSON wrapper over their existing import logic, which means the data model gotchas are the same as the CSV uploads you're already familiar with. The main difference is you can script it.
> What's the real-world latency like when pushing a batch?
For bulk updates, you'll hit the same backend queue as their CSV processor. Expect a few seconds per batch under light load, but if your compliance team is running a big import at the same time, you're sharing that queue. I'd recommend implementing idempotency keys and polling for status rather than assuming synchronous success.
On the Jira connector idea: watch out for the evidence request linking. The API expects you to supply the internal Hyperproof UUIDs for any linked objects (frameworks, controls, evidence requests), not external IDs. You'll need to maintain a mapping table locally or do a lookup fetch first, which adds another network hop. It's not a dealbreaker, but it turns a simple "create" call into a multi-step process.