Skip to main content

API Reference

Automate governed builds with JWTs and API keys

The EVC Platform API provides programmatic access to builds, projects, prompts, Crucible sessions, and CIF analytics. Use JWTs for user-driven sessions and API keys for headless automation. The full interactive reference lives at /api/docs.

Authentication (JWT + API keys)

The API supports two authentication methods. Use the one that matches your integration pattern.

JWT authentication

Use JWT access tokens for browser sessions and interactive tooling. Tokens are obtained via the login endpoint and include user identity and organization context. Access tokens expire after 15 minutes; use refresh tokens to obtain new ones.

API keys for automation

Use scoped API keys for headless integrations. Keys are created in organization settings, scoped to specific permissions, and passed via the X-API-Key header. Keys do not expire but can be revoked at any time.

[Screenshot: API key management page showing active keys with scopes and creation dates — pending capture]

JWT authentication header

bash
curl -X POST "$API_URL/api/v1/orgs/$ORG_ID/builds" \  -H "Authorization: Bearer $ACCESS_TOKEN" \  -H "Content-Type: application/json" \  -d '{    "project_id": "$PROJECT_ID",    "prompt_text": "Generate an evidence-backed release checklist service",    "provider": "anthropic",    "model": "claude-sonnet-4-20250514",    "mode": "STANDARD"  }'

API key authentication header

bash
curl "$API_URL/api/v1/builds/$BUILD_ID" \  -H "X-API-Key: $API_KEY"
JWT tokens carry the user identity and permissions. API keys carry the organization context and configured scopes. Choose based on whether the caller represents a user or a system.

Base URL and versioning

The API uses URL-based versioning. All endpoints are prefixed with the API version.

The current API version is v1. The base URL for all API requests is:

https://your-domain.com/api/v1

When a new API version is released, the previous version remains available for a deprecation period. Version sunset notices are published in the changelog and communicated via email.

[Screenshot: Interactive API docs showing versioned endpoint structure — pending capture]

Error response format

All API errors follow a consistent JSON structure with a machine- readable code and a human-readable message.

Error response structure

json
{  "error": {    "code": "VALIDATION_ERROR",    "message": "The prompt_text field is required.",    "details": [      {        "field": "prompt_text",        "constraint": "required"      }    ]  }}

The code field contains a stable error identifier suitable for programmatic handling. The message field provides a human-readable explanation. The optional details array contains field-level validation errors when applicable.

Common error codes include:

  • VALIDATION_ERROR — request body failed validation
  • UNAUTHORIZED — missing or invalid authentication
  • FORBIDDEN — authenticated but insufficient permissions
  • NOT_FOUND — requested resource does not exist
  • RATE_LIMITED — request rate exceeded the limit
  • BUDGET_EXCEEDED — organization or project budget exhausted

[Screenshot: Interactive docs showing error response examples for different status codes — pending capture]

Rate limiting

The API enforces rate limits per authentication identity. Limits are communicated via standard HTTP headers on every response.

Rate limit headers included on every response:

  • X-RateLimit-Limit — maximum requests per window
  • X-RateLimit-Remaining — requests remaining in the current window
  • X-RateLimit-Reset — UTC epoch timestamp when the window resets

When the rate limit is exceeded, the API returns HTTP 429 with a Retry-After header indicating how many seconds to wait before retrying.

Rate limits vary by subscription tier. Higher tiers include higher rate limits. Contact support if your integration requires limits beyond your current tier.

[Screenshot: Rate limit headers shown in a response inspector — pending capture]

Common API operations

Examples of the most frequently used API operations for build automation.

Trigger a build

bash
curl -X POST "$API_URL/api/v1/orgs/$ORG_ID/builds" \  -H "Authorization: Bearer $ACCESS_TOKEN" \  -H "Content-Type: application/json" \  -d '{    "project_id": "$PROJECT_ID",    "prompt_text": "Generate an evidence-backed release checklist service",    "provider": "anthropic",    "model": "claude-sonnet-4-20250514",    "mode": "STANDARD"  }'

Check build status

bash
curl "$API_URL/api/v1/builds/$BUILD_ID" \  -H "Authorization: Bearer $ACCESS_TOKEN"

Download generated artifacts

bash
curl "$API_URL/api/v1/builds/$BUILD_ID/artifacts" \  -H "Authorization: Bearer $ACCESS_TOKEN" \  -o artifacts.json

Need the full schema?

Open the interactive Swagger surface to inspect request bodies, test public endpoints, and explore protected routes during integration.