Secure, tenant-scoped REST API for integrating Reliatic with CMMS, ERP, and other enterprise systems. Versioned endpoints with comprehensive authentication and rate limiting.
All API requests require authentication via an API key passed in the Authorization header. API keys are created and managed in the tenant administration panel under Settings > API Keys. Each key is scoped to a single tenant and cannot access data from other tenants, enforced at the database level through Row Level Security. Keys support two permission levels: read-only keys can perform GET requests against all endpoints but cannot create, update, or delete resources; read-write keys have full access to all CRUD operations. The authentication header format is: Authorization: Bearer rl_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxx. API keys use the prefix rl_live_ for identification. Keys can be revoked at any time from the admin panel, and revocation takes effect immediately. There is no expiration-based key rotation, but organizations can create multiple keys and rotate them on their own schedule. Invalid or revoked keys receive a 401 Unauthorized response with a JSON body: {"error": "invalid_api_key", "message": "The provided API key is invalid or has been revoked."}.
The API is organized around five primary resources, all under the /api/v1 namespace. Assets — GET /api/v1/assets returns a paginated list of assets in the tenant. Query parameters include: page (default 1), per_page (default 25, max 100), status (active, inactive, decommissioned), type (vessel, piping, tank, heat_exchanger, rotating), and search (text search across tag number and description). GET /api/v1/assets/:id returns a single asset with full metadata including current risk ranking, last inspection date, and remaining life. POST /api/v1/assets creates a new asset. Required fields: tag_number, name, asset_type. PUT /api/v1/assets/:id updates an existing asset. DELETE /api/v1/assets/:id performs a soft delete (sets status to decommissioned). Inspections — GET /api/v1/inspections returns inspection records with filtering by asset_id, inspection_type, date_from, and date_to. POST /api/v1/inspections creates a new inspection record. Required fields: asset_id, inspection_type, inspection_date, inspector_name. The response includes the computed inspection effectiveness level. Failure Modes — GET /api/v1/failure-modes returns FMEA records with filtering by asset_id and rpn_min/rpn_max thresholds. POST /api/v1/failure-modes creates a new failure mode. Required fields: asset_id, description, severity (1-10), occurrence (1-10), detection (1-10). The response includes the computed RPN and priority classification. Actions — GET /api/v1/actions returns corrective actions with filtering by status, priority, assignee_id, and asset_id. POST /api/v1/actions creates a new action. PUT /api/v1/actions/:id/status transitions the action to a new lifecycle state (subject to valid state transition rules). Risk Assessments — GET /api/v1/risk-assessments returns RBI assessments with filtering by asset_id and risk_ranking. POST /api/v1/risk-assessments creates a new assessment. Required fields: asset_id, probability_of_failure (1-5), consequence_of_failure (1-5).
All requests and responses use JSON (Content-Type: application/json). Successful responses return a consistent envelope: {"data": {...}, "meta": {"timestamp": "2026-04-01T12:00:00Z"}} for single resources, and {"data": [...], "meta": {"page": 1, "per_page": 25, "total": 142, "total_pages": 6}} for collections. Error responses use a consistent schema: {"error": "error_code", "message": "Human-readable description", "details": [...]}. Standard error codes include: validation_error (400) for invalid input with field-level details, unauthorized (401) for missing or invalid authentication, forbidden (403) for insufficient permissions, not_found (404) for non-existent resources, conflict (409) for state transition violations, rate_limited (429) for rate limit exceeded, and internal_error (500) for unexpected server errors. Dates are always in ISO 8601 format (UTC). Numeric fields use standard JSON numbers. Null fields are included in responses (not omitted) to maintain a stable schema.
API requests are rate-limited to protect platform stability and ensure fair usage across tenants. The default limit is 100 requests per minute per API key. Rate limit status is communicated via standard headers on every response: X-RateLimit-Limit (the maximum number of requests allowed in the current window), X-RateLimit-Remaining (the number of requests remaining in the current window), and X-RateLimit-Reset (the Unix timestamp when the current window resets). When the rate limit is exceeded, the API returns a 429 Too Many Requests response with a Retry-After header indicating the number of seconds to wait before retrying. Rate limits are applied per API key, not per IP address. Organizations with multiple integrations should use separate API keys for each integration to avoid one integration consuming the rate limit for others. Higher rate limits are available for Enterprise tier tenants upon request. Best practices for staying within rate limits: use pagination to retrieve large datasets in batches rather than requesting all records at once, implement exponential backoff on 429 responses, and use webhooks for event-driven workflows rather than polling.
Reliatic supports outbound webhooks for real-time event notifications. Webhooks eliminate the need for polling and enable immediate reaction to platform events in external systems. Webhook endpoints are configured in the tenant administration panel under Settings > Webhooks. Each webhook subscription specifies a target URL (HTTPS required), the event types to subscribe to, and an optional secret for signature verification. Supported event types include: asset.created, asset.updated, asset.decommissioned — triggered on asset lifecycle changes; inspection.completed — triggered when an inspection record is finalized; action.status_changed — triggered on any action lifecycle transition; risk_assessment.created — triggered when a new RBI assessment is computed; fmea.rpn_changed — triggered when a failure mode's RPN is updated; moc.status_changed — triggered on any MOC workflow transition; and alert.escalated — triggered when an SLA escalation occurs. Each webhook delivery includes a JSON payload with the event type, the timestamp, the resource ID, the before and after state (for updates), and a delivery ID for idempotency. Webhook deliveries include an X-Reliatic-Signature header containing an HMAC-SHA256 signature of the payload using the configured secret, allowing the receiver to verify authenticity. Failed deliveries (non-2xx response or timeout after 10 seconds) are retried with exponential backoff: 1 minute, 5 minutes, 30 minutes, and 2 hours. After 4 failed attempts, the delivery is marked as failed and appears in the webhook delivery log for manual investigation. The webhook log retains delivery history for 30 days.