Skip to content

Authentication

Every request to the Sable Integration API must be made on behalf of an issued integration client.

Warning

The Integration API is currently in beta and is only available to Pro and Enterprise subscribers.

Current model

  • Requests authenticate as an API client
  • The API exposes identity through GET /api/v1/me
  • The identity payload includes roles and scopes

Create an API key

Create your API key in the Vulnetic app before making Integration API requests.

Verify access

curl -sS "https://app.vulnetic.ai/api/v1/me" \
  -H "<AUTH_HEADER_NAME>: YOUR_API_CREDENTIAL"

Example response:

{
  "account_id": "4f0d0a7d-644d-4dad-b5a4-c8f455e6f6b8",
  "api_client_id": "d4c8f636-5fcd-486f-8b47-3f254eb5ac25",
  "client_name": "Acme Security Automation",
  "delegated_user_id": "ea0580a8-8df4-43f1-b28e-87f1dc1b3a90",
  "roles": ["integration"],
  "scopes": [
    "projects:read",
    "projects:write",
    "sessions:read",
    "sessions:write",
    "findings:read",
    "documents:write"
  ]
}

Scopes

Use /api/v1/me at startup to confirm that the credential has the scopes your integration expects. If your workflow needs to create sessions, transition findings, or create documents, fail fast when the required scope set is not present.

  • Use a dedicated integration client per environment
  • Keep credentials out of source control
  • Start each integration run by calling /api/v1/me
  • Request the smallest scope set that still supports your workflow
  • Rotate credentials whenever ownership or deployment boundaries change

OpenAPI gap

Warning

The current OpenAPI contract does not publish a securitySchemes block. That means the final public reference still needs one concrete auth scheme, one concrete header format, and clear credential lifecycle guidance.

Until that is published, these docs intentionally use placeholders such as <AUTH_HEADER_NAME> and YOUR_API_CREDENTIAL instead of claiming a header shape that the spec does not currently define.