Ask whether everything you can do in the interface can be done through an API, how rate limits work, whether webhooks exist, how service accounts authenticate, and what you can export. A tool that cannot be automated will end up as one more screen nobody checks.
Why this matters to engineering
Your teams already work in source control, CI, chat and a ticket tracker. A security tool that lives only in its own dashboard adds a place to look. A tool with a good API and integrations can put findings where work already happens.
Questions to ask
| Area | Question | What to listen for |
|---|---|---|
| API coverage | Can I do everything the UI does through the API? | Honest gaps, a published reference |
| Limits | What are the rate limits and how are they shown? | Clear numbers and headers, not "it depends" |
| Webhooks | Which events can trigger a webhook? | New finding, status change, scan complete |
| Authentication | How do service accounts authenticate? | Scoped tokens, rotation, no shared human logins |
| Permissions | Can tokens be limited to one project or action? | Least privilege options |
| Export | What formats can I export findings and inventory in? | Open, documented formats, not only PDFs |
| Versioning | How are API changes announced? | A deprecation policy with notice period |
| Source control | What permissions does the integration request? | Minimal scopes, read only where possible |
Look at the integration, not the logo list
A logo on a slide does not tell you how deep an integration goes. Ask to see a real pull request check, a real ticket created from a finding, and a real chat message. Check what happens when a ticket is closed in your tracker: does the finding update, or does it stay open?
Check the permissions the integration needs
An integration with source control often asks for broad access. Compare the requested permissions with what the feature needs. Ask whether read only operation is possible, and what happens to access when you remove the integration.
Test the API in the trial
Write a small script that lists findings for one project and posts a count to your chat. If you cannot do that in an afternoon, automation will be hard later. Check that error messages are useful and rate limit behavior matches the documentation.
Plan for leaving
Ask how you would export your data if you left. Findings history, suppressions and decisions have value, and losing them resets your program. Prefer open formats where they exist.
Quick check
Is a webhook better than polling the API?
Usually, for events like a new finding. Polling is fine for periodic reports. Use both where it makes sense.
Who should hold the integration credentials?
A service account owned by the tool owner team, with scoped permissions and a rotation plan, not a person's account.
Last reviewed: 19 October 2026.
