Run scans from your codebase

Create a key

Open API → API keys, give the integration a name, and select the permissions it needs. The default scopes allow account, workspace, scan and finding reads plus scan submission. Audit reads and deletion are separate choices.

Copy the key once into a secret manager or your CI secrets. It is shown only once, expires in 90 days by default, and can be revoked at any time. Expiration choices are 1 hour, 1 day, 7 days, 30 days, 90 days, 180 days or 1 year (365 days). There can be 10 active keys per account. Use one key per integration and rotate by replacing the integration's secret before revoking its previous key.

An API key is your secret credential. Bearer is the header scheme used to send it. They describe different parts of the same request:

Authorization: Bearer <api_key>

Use HTTPS. Keep the key out of URLs, source control, browser bundles, logs and shared Postman environments. A key grants its selected permissions to anyone holding it. Browser cookies cannot authenticate these API calls.

To gate every push in CI, follow Run a security scan in GitHub Actions. It has a ready workflow plus Bash, Python and JavaScript scripts.

Choose a workspace and run a scan

Set SENTRINT_API_KEY in your environment. Call GET /api/v1/workspaces to choose an owned workspace ID. Set it as WORKSPACE_ID, then submit your own repository:

curl --fail-with-body -X POST \
  "https://sentrint.com/api/v1/workspaces/$WORKSPACE_ID/scans" \
  -H "Authorization: Bearer $SENTRINT_API_KEY" \
  -H "Content-Type: application/json" \
  --data '{"repo_url":"https://github.com/your-org/your-repo","branch":"main","force":false}'

The 202 response gives you scan_id, status, status_url and reused. Poll the status URL every 5 to 10 seconds. An identical live scan is reused. A completed scan is reused unless you request force:true; a newly claimed attempt uses your allowance. Workspace locks, repository limits and the scan allowance still apply.

Private repositories use the owner's linked GitHub access, so connect GitHub with access to the repository first. The API accepts no personal access token field and uses no shared server credential for private access. The private-access checks have been tested with simulated GitHub responses; a live private-repository check has not been performed.

Fetch the results

After completion, fetch GET /api/v1/scans/{scan_id}/report, then GET /api/v1/findings?scan_id={scan_id}&severity=HIGH for a filtered list. Finding lists omit snippets and guidance; the finding-detail endpoint provides them only when your account's guidance is unlocked. Check guidance_locked in report and finding-detail responses.

Lists return data and next_cursor. Pass the opaque cursor unchanged with the same filters to continue; stop when it is null. Page size is 25 by default and can be set from 1 to 100. The API also exposes account summary, workspace details and retained audit events. Every ID and list is restricted to the key owner's account.

Handle limits and errors

Each request uses an action rate window and the shared account window. On a rate limit, wait for Retry-After seconds before retrying. quota_exhausted means scan allowance rather than a request window. Errors use problem JSON with code, detail and request_id; branch on code and save the request ID for support.

The dashboard's Rate limits has the current rate table. The API reference covers accepted filters, request and response schemas, error handling and curl, Python and JavaScript examples.

Delete a finished scan

Use a key with scans:delete to create a deletion request. Open its approval_url, confirm the owner's linked sign-in identity, and separately approve the deletion. The provider may reuse its existing login session; this does not guarantee a fresh password or MFA challenge. Email is a notification, not the authentication step.

After the request becomes approved, send DELETE /api/v1/scans/{scan_id} with the same key and X-Deletion-Approval: {request_id}. Approval is single-use, bound to the owner, key and scan, and expires 10 minutes after creation. Retrying or rescanning the scan invalidates earlier approvals. Success is 204 with no body. Findings are removed; the audit record remains. Read the full walkthrough.

Import into your API client

Download the Postman collection, OpenAPI JSON or OpenAPI YAML. Insomnia and other compatible clients can import the OpenAPI 3.1 files.

In Postman, set base_url and api_key locally. Fill workspace_id, scan_id, finding_id and deletion_request_id from your own responses as needed. Optional filter rows start disabled; enable only the ones you need. Never share a file with your real key populated.

Fast, durable submission

Use POST /api/v1/workspaces/{workspace_id}/submissions when you need an acknowledgement before GitHub validation. Send the same JSON body as the scan endpoint and an Idempotency-Key header containing 8-128 ASCII letters, digits, dashes, dots or underscores. Use one unique key per intended submission and reuse it when retrying that request. Reusing it with different input returns 409 idempotency_conflict.

The 202 response contains a committed submission id and status_url. Poll that URL with a key granting scans:read. States are accepted, validating, failed, and scan_ready. A ready submission includes scan_id and scan_status_url; poll the scan for execution progress and its report. A failed submission includes error_code and error_detail. Provider failure does not charge scan quota. A transient validation failure, including GitHub rate limiting, retries up to three attempts before becoming failed; a GitHub rate limit waits at least 60 seconds before the next attempt. A submission interrupted repeatedly by server restarts fails with submission_interrupted; submit it again with a new Idempotency-Key.

Submission needs scans:create. Rate limits and usage counters apply to each incoming request, including retries and polling. Only the owner's currently linked GitHub authorization is used; never send a GitHub token in JSON. Revoking the accepting key prevents unfinished validation from creating a scan.

The existing POST /api/v1/workspaces/{workspace_id}/scans response remains available and waits for GitHub validation. Clients choose the new submission endpoint to get the earlier acknowledgement. An idempotent replay returns the original submission, including terminal failures; use a new key for a new attempt after correcting a failure.