Loading workspace...
Auroranexis documentation
The Auroranexis REST API lets your workspace integrate with external systems, automate operational workflows, and receive event notifications. Manage keys and webhook endpoints in Settings → API. For endpoint-level details, use the interactive OpenAPI reference at /api/docs.
The Auroranexis API is a RESTful, organization-scoped interface. Every request is authenticated with an API key that carries explicit scopes limiting what the key can read or write. The API follows standard HTTP conventions — JSON request and response bodies, appropriate status codes, and TLS encryption for all traffic.
API access availability and rate limits depend on your subscription plan. Plan-gated features such as AI execution and predictive analytics require both the appropriate scope and an eligible plan tier.
All key management — creation, scope selection, revocation, and webhook registration — happens in Settings → API. The OpenAPI reference at /api/docs is the authoritative source for endpoint paths, request schemas, and response formats.
Agencies use the API to synchronize client data with CRM systems, trigger automations from external events, publish reports programmatically, and build custom internal tools on top of Auroranexis operational data. Webhooks complement the API by pushing event notifications to your endpoints when platform events occur.
The API is designed for server-to-server integration. Keys should be treated as sensitive credentials with the same care as passwords or integration secrets. Never embed keys in client-side JavaScript, mobile applications, or public repositories.
Rate limits protect platform stability for all customers. Monitor usage in Settings → API and Settings → Usage, and implement backoff strategies in your integration code when limits are approached.
Contact support@auroranexis.com for onboarding support, billing questions, or product guidance. Include your workspace name, the module you are working in, and a brief description of your goal so we can respond efficiently.
Grant only the scopes your integration requires. Each scope pair follows a resource.action pattern. Keys with write scopes can modify data — apply least privilege.
A marketing agency registers https://integrations.example.com/auroranexis/events as a webhook endpoint with events for report.published and incident.created. When a report is published, Auroranexis sends an HTTPS POST with a JSON payload. The receiver validates the request, processes the event idempotently, and returns HTTP 200. Failed deliveries appear in webhook logs for investigation.
An automation agency connects a workflow engine to Auroranexis using scoped API keys. The admin creates a key with clients.read and incidents.write scopes so failed automation runs can open incidents automatically. POST requests include client ID, severity, and a description referencing the workflow run ID. Write scopes are limited to incidents — report and billing endpoints remain unreachable from the integration service account.
An MSP syncs client names and status to ConnectWise nightly. The admin creates a key named CRM Sync in Settings → API with only the clients.read scope. The integration sends GET /api/v1/clients with Authorization: Bearer ax_live_example_key_abc123. The response JSON array is parsed and upserted into the CRM. No write scopes are granted because the sync is one-directional.
A small consultancy builds an internal dashboard showing subscription usage against plan limits. The owner creates a read-only key with billing.read scope in Settings → API. A nightly script fetches usage summaries and displays them alongside client counts from a separate clients.read key. Write scopes are intentionally excluded from both keys.
An MSSP's monitoring stack auto-creates incidents when thresholds are breached across eighty enterprise clients. The admin creates a dedicated key with incidents.write scope and documents rate-limit headroom in Settings → Enterprise before enabling production traffic. POST requests to /api/v1/incidents include title, severity, client ID, and description fields. A 201 response returns the new incident ID for tracking in the external monitoring dashboard.
Common API issues
| Problem | Cause | Solution |
|---|---|---|
| 401 Unauthorized on API request | Key revoked, malformed, or missing from Authorization header | Verify the Bearer token format and confirm the key is active in Settings → API. |
| 403 Forbidden on API request | Key lacks required scope or plan does not include the feature | Create a new key with the needed scope or upgrade your plan if the feature is plan-gated. |
| 404 Not Found for resource | Incorrect resource ID or endpoint path | Verify the path and ID against /api/docs; confirm the resource exists in your workspace. |
| 429 Too Many Requests | Request rate exceeds plan limit | Implement exponential backoff, reduce call frequency, and review usage in Settings → Usage. |
| Webhook deliveries failing |
| Endpoint unreachable or returning non-2xx responses |
| Confirm the endpoint accepts HTTPS POST and returns 2xx; check webhook logs for error details. |
| API key not visible after creation | Keys are shown only once at creation | Revoke the lost key and create a new one with the same scopes. |
| Empty results despite data existing | Query parameters filtering results or wrong organization scope | Keys only access your workspace data; review query parameters and pagination in /api/docs. |
