JSON in. JSON out. Every endpoint documented.

NovexERP ships with a full OpenAPI 3.0.3 specification served at /docs/openapi.json. This machine-readable contract describes every available endpoint, request parameter, response schema, and authentication requirement. Interactive documentation is available through Swagger UI at /docs/ and ReDoc at /docs/redoc.html, allowing developers to explore endpoints, inspect schemas, and test API calls directly from the browser without writing any code.

Three authentication methods are supported, each designed for different use cases. JWT bearer tokens passed via the Authorization: Bearer header handle user sessions with short-lived credentials. Scoped API keys passed via the X-API-Key header serve integrations and automation scripts that need long-lived access. Admin tokens passed via the X-NOVEX-ADMIN-TOKEN header authenticate cron jobs and internal system operations. This layered approach ensures the right level of access control for every type of consumer.

API keys support granular scope arrays that limit access to specific modules and operations. For example, a key might be scoped to panel:orders and panel:orders.create, granting read and create access to orders while blocking access to everything else. Keys inherit the generating user's role for permission enforcement, support configurable expiration dates, and track last-used timestamps for security auditing. The key format uses a prefixed hash pattern (nk_abc123...) for easy identification in logs and configuration files.

Rate limiting is enforced via a Redis backend with file and APCu fallback options for environments without Redis. Limits are configured per-endpoint to match expected usage patterns — the login endpoint is restricted to 5 requests per 15 minutes to prevent brute-force attacks, the health check allows 100 requests per 60 seconds, AI polling endpoints support 600 requests per 60 seconds for responsive interfaces, and the default limit is 100 requests per 60 seconds for general API usage. Every response includes X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers so clients can self-throttle proactively. When limits are exceeded, a 429 response includes the Retry-After header indicating when the next request will be accepted.

Identifier priority for rate limiting follows a specific order: API key hash first, then authenticated user ID, then client IP address. This ensures that different API keys from the same IP are tracked independently, while unauthenticated requests fall back to IP-based tracking. All API responses follow a consistent JSON format. Errors return a structured object with error.code, error.message, and error.details fields, making client-side error handling predictable across every endpoint. Collection endpoints support pagination, filtering, and sorting parameters. For platform-level API architecture details, see API Architecture, and for event-driven integrations, see Webhooks.