Public API

Overview

This guide walks you through the Public API Settings screen in Shift Left Studio exactly as it appears, so you can expose (or disable) the Public API, tune rate limits and token expiry, and restrict access by role. The Public API is the REST interface CI/CD pipelines use to trigger test packs and read results (log in, run a pack, poll status).

Explore the capability at api keys. Where to find everything: Administration Settings.

Availability: Professional and Enterprise. The unauthenticated /api/v1/health check is always available regardless of edition.

Before you begin

• You must be an administrator. Navigate to Settings → Integrations → Public API.
• The subtitle reads "Configure external API access for CI/CD integration and automation."
• Two buttons sit at the top of the screen: Reset to Defaults (restores default values after a confirmation) and Save Settings (persists your changes — nothing is saved until you click it).

Step 1 — Copy the documentation URLs

At the top, the API Documentation banner gives two copyable links (host and port depend on your deployment):

Copying either shows "Copied to clipboard!"

Step 2 — General settings

In the General Settings card:

Step 3 — Rate limiting

In the Rate Limiting card:

Tighten these in production; raise them only with evidence of legitimate throughput needs.

Step 4 — Authentication

In the Authentication card:

A login attempt from a role that isn't in Allowed Roles is rejected with "Your role (…) is not allowed to access the Public API" (HTTP 403).

Step 5 — CORS

In the CORS (Cross-Origin Resource Sharing) card (with a Security Warning that allowing all origins is convenient but less secure):

Step 6 — Save

Click Save Settings (it shows Saving... while working). On success you'll see "Public API settings saved successfully." To restore defaults, click Reset to Defaults, then confirm in the Reset Public API Settings dialog (this cannot be undone).

The CI/CD login → run → poll flow

The Available Endpoints section lists all 8 endpoints. A typical pipeline uses them in this order:

1. POST /api/v1/login — authenticate with email + password to receive a JWT. Send it as Authorization: Bearer <token> on every later call. (Login events are audited as cicd_login.)
2. GET /api/v1/test-packs — list available packs (optionally filter by projectName or environment) to find the packId.
3. POST /api/v1/test-packs/{packId}/run — trigger execution. Returns an executionId and status: RUNNING; the run is asynchronous. (Audited as cicd_execute.)
4. GET /api/v1/test-packs/{packId}/status — poll for completion; returns the pack status and a pass/fail summary with successRate.
5. GET /api/v1/test-packs/{packId}/results — fetch per-test-case results (status, duration, error).

Other endpoints: GET /api/v1/test-packs/{packId} (pack details), GET /api/v1/test-packs/{packId}/history (recent executions), and GET /api/v1/health (always available, no auth).

Using API keys instead of username/password

Rather than logging in with a user's email and password, you can issue a scoped, rotatable API key and send it on API requests. Keys are safer for automation because they carry only the scopes you grant, can expire, and can be rotated or revoked without touching a user account. See API keys.

Best practices

• Keep the API disabled until you have an integration owner and monitoring.
• Store tokens and API keys in a secret manager, never in repos.
• Revoke unused tokens/keys and review Allowed Roles after org changes.

Related articles

• API keys
• Role Permissions
• Audit Logs
• Configuration fundamentals