Integration Builder
Request a new integration and Strike Graph will automatically research, build, and ship it for you
Written By Micah
What is Integration Builder?
Strike Graph's integration catalog covers many of the systems that compliance teams collect evidence from, but your tech stack may include a tool that isn't listed yet. Integration Builder lets you request a new integration directly from the Integrations Manager, and Strike Graph's Integration Builder takes it from there: researching the vendor's API, writing the connection and evidence-collection code, and delivering a working integration for our team to review and ship.
The result is a fully supported Bridge integration, complete with both direct API requests and Script Runner support, that works the same as any other integration in your Integrations Manager.
To check availability or enable Integration Builder for your organization, contact your Customer Success Manager.
How It Works
The process has three stages:
You submit a request describing the system you need, a link to its API documentation, the evidence you expect to collect, and how the system authenticates. The form never asks for any credential values.
Integration Builder researches the request automatically, verifying the vendor's API, determining how authentication works, and assessing feasibility. This stage runs without human intervention.
The integration is built and reviewed. Integration Builder generates the connection code and evidence-collection scripts, then our engineering team reviews and ships the integration. Your Customer Success contact will follow up with the outcome.
The entire pipeline is designed to minimize turnaround. Once the build is reviewed and approved, the integration appears in your Integrations Manager like any other.
Submitting a Request
Who can submit
Users with Manager or Contributor roles can submit integration requests.
Where to find it
Navigate to Integrations in the main Strike Graph menu. If your organization has Integration Builder enabled, you'll see an Automated Integrations card with a Request an integration button.
The request form
The form captures everything Integration Builder needs to assess and build your integration. Fields marked with an asterisk are required.
System name*: the name of the system you want to connect (for example, "Datadog" or "Freshservice").
API or developer documentation link*: a direct link to the vendor's public API or developer documentation. This must be a publicly accessible https:// URL. Do not include any credentials, tokens, or API keys in the link.
Evidence you expect to collect*: describe the data you need for compliance purposes. Be specific about the types of records you're looking for (for example, "a list of monitors with their alert history" or "change management tickets closed in the last 90 days").
How you would use it*: explain the compliance context (for example, "prove alerting coverage for SOC 2 CC7.2 without screenshots").
How do you connect to its API?: select the authentication method the vendor uses:
Sign in with the vendor (OAuth consent screen)
Paste credentials from the vendor's admin console
A single API key
Not sure
If you select a credential-based option, an additional field appears asking for the names of the credential fields the vendor shows (for example, "API key, Application key"). Only names, never actual values.
Region, data center or site: if the vendor has regional endpoints or per-organization subdomains, note them here (for example, "EU" or "acme.atlassian.net").
Does API access depend on your plan with the vendor?: let us know whether the vendor restricts API access to certain plan tiers.
Could we get a test account to verify against?: whether a free trial, a customer-supplied account, or a sales-provisioned account is available for testing.
Selecting "Not sure" for any optional question is fine: Integration Builder will research the answer during the feasibility stage.
After you submit
You'll see a confirmation that your request has been received. Your Customer Success contact will follow up with the outcome once the integration has been assessed. If feasibility research surfaces any questions, your CS contact will reach out.
A few things to keep in mind:
Only one open request per system is allowed at a time. If you've already submitted a request for a system, you'll see a message letting you know.
Requests are rate-limited to prevent accidental duplicates.
What Gets Built
A completed integration request produces a standard Bridge integration with:
A connection card in the Integrations Manager, with your vendor credentials stored securely
Direct API request support for calling the vendor's endpoints
Script Runner scripts for common evidence-collection scenarios
Automated Collection compatibility, so evidence stays current on a schedule
Once shipped, the integration works identically to any other Bridge integration: connect it, attach evidence to your evidence objects, and optionally configure Automated Collection to keep your evidence fresh.
Security Considerations
Integration Builder uses automation to research vendor APIs and generate integration code, which raises a fair question: how do you know the resulting integration is safe?
Every integration is human-reviewed before it ships. Integration Builder produces merge requests that go through the same engineering review process as any other code change at Strike Graph. No generated code runs against your systems or touches your credentials until a Strike Graph engineer has reviewed and approved it.
You control your own credentials and permissions. When you connect a built integration, you provide your own API key or credentials through the same secure connect flow as every other Strike Graph integration. You determine the scope and permissions of that key in your vendor's admin console. Strike Graph does not deploy any agent or code inside your third-party systems.
Evidence collection is read-only. Built integrations are restricted to GET requests at the server level. Strike Graph will never create, modify, or delete data in your connected systems, regardless of what the key you provide is capable of. Using a read-only key or token is always recommended as an additional safeguard.
The request form never collects credentials. When you submit an integration request, the form asks for the names of credential fields (for example, "API key"), never the values themselves. It also rejects documentation links that contain tokens or keys in the URL.
Network access is scoped per provider. Evidence-collection scripts run in a sandboxed environment with outbound network access restricted to the specific API hosts required by that integration. A script built for one vendor cannot reach a different vendor's endpoints.
Need More Help?
If you have questions about Integration Builder or want to check on the status of a submitted request, reach out to your Customer Success Manager or contact our support team through the in-app messenger.
Was this helpful?
More in Integrations Guidance
Evidence APIScript Runner for IntegrationsStill need help? Share an idea