API Reference
AISEC uses a service-oriented API surface. The web app consumes these APIs with a shared auth context, and most services expect the same tenant-scoped request pattern. This page is meant to help developers orient quickly, not replace formal OpenAPI output.
8001
AI orchestrator local port
8002-8006
Core service port range
3
Shared auth headers commonly used
Authentication
Shared request contract
The frontend attaches auth context from cookies and sends the same headers across services for tenant-safe access.
- Authorization: Bearer <token> is attached by the shared axios client for authenticated requests.
- X-Tenant-ID scopes requests to the active tenant and is required by multiple backend services for row-level enforcement.
- X-User-ID is also forwarded so downstream services can attribute actions and apply user scope where needed.
- Most services return a standard envelope shaped like { success, data }, which the web client unwraps automatically.
Service Map
Core service domains and notable endpoints
These paths come directly from the service controllers and route modules in the repo.
Auth service
Local default port 8006. Handles account lifecycle, profile, tenant logo, team management, MFA, SAML SSO, and SCIM provisioning.
- POST /api/v1/auth/login
- POST /api/v1/auth/signup
- GET /api/v1/auth/profile
- GET /api/v1/auth/saml/metadata
- GET /api/v1/auth/scim/v2/Users
Policy service
Local default port 8002. Owns policies, controls, and AI system records used by the main application.
- GET /api/v1/policies
- POST /api/v1/policies/generate
- POST /api/v1/policies/finalize
- POST /api/v1/policies/:id/approve
- GET /api/v1/controls
Risk and monitoring
Risk engine runs on 8003 and monitoring service on 8005, covering register workflows, summaries, alerts, and rules.
- GET /api/v1/risks
- GET /api/v1/risks/summary
- GET /api/v1/monitoring/alerts
- POST /api/v1/monitoring/alerts/:id/acknowledge
- POST /api/v1/monitoring/rules
AI and Evidence
Async jobs, streaming, and evidence collection
The AI and evidence services have their own patterns that are worth understanding before you integrate against them.
AI orchestrator
Runs on port 8001. It provides async generation, gap analysis jobs, job-status polling, and streaming chat responses.
- POST /api/v1/generate/policy
- POST /api/v1/generate/gap-analysis
- POST /api/v1/generate/risk-controls
- GET /api/v1/jobs/:jobId
- POST /api/v1/chat with text/event-stream responses
Evidence collector
Runs on port 8004. It handles evidence listing, upload, download, review, integrations, and collection triggers.
- GET /api/v1/evidence
- POST /api/v1/evidence/upload
- GET /api/v1/integrations
- POST /api/v1/collect/trigger
- Health endpoints at /health and /ready
Operational Notes
Patterns to design around
A few API traits shape how the web app and any integrations should behave.
- Policy generation is intentionally asynchronous; queue the job, poll job status, then finalise into a draft record.
- Chat responses stream over server-sent events, so clients should render partial output rather than waiting for a full payload.
- Monitoring routes enforce tenant context and can reject requests that omit or mismatch X-Tenant-ID.
- Evidence upload enforces content validation and size limits, so preflight checks are worth doing client-side.
Related
Keep exploring
Want the product context behind these APIs?
Use the product and docs pages to understand how operators experience these endpoints in the UI and workflow model.