RAPID AI as an API Product

Chapter 32 — RAPID AI as an API Product

The previous chapters described what RAPID AI does: 451+ physics-based rules, SEDL entropy analysis, AESF stability states, FRETTLSM causal taxonomy, CDE contradiction detection, RUL estimation, RCM decision logic, and an agentic copilot that orchestrates it all through natural language. This chapter describes how that intelligence reaches the outside world. RAPID AI is not a dashboard with an API bolted on. It is an API with a dashboard built on top. The API is the product. Everything else — the SvelteKit Explorer, the copilot, the fleet dashboard — is a consumer of that API, identical in status to any enterprise customer’s CMMS integration or analytics pipeline.

This is the API-first philosophy: design the intelligence as a service, expose it through stable contracts, and let every consumer — internal or external — access it through the same interface. The alternative (building a monolithic application where the UI and the intelligence are entangled) makes the platform unsellable to enterprises that need to integrate diagnostic intelligence into their existing operational technology stack.

---

32.1 Why API-First?

Industrial enterprises do not rip out their operational technology to adopt a new tool. They have CMMS systems (SAP PM, Maximo, Fiix) that manage work orders. They have SCADA/DCS systems that collect sensor data. They have ERP systems that track costs, spare parts, and procurement. They have historians (OSIsoft PI, Honeywell PHD, Aveva) that store time-series data. They have analytics platforms (Seeq, TrendMiner, Power BI) that their engineers already know how to use.

RAPID AI’s value proposition is not “replace all of that.” It is “feed your sensor data into our diagnostic engine, receive physics-grounded failure diagnoses and maintenance recommendations, and push those results into whatever system your team already uses.” That value proposition requires an API.

The API-first approach delivers four strategic advantages:

1. Integration without migration. A customer with SAP PM can call POST /api/v1/diagnostics/run from their existing workflow automation, receive a diagnostic result, and create a work order in SAP PM with the recommended maintenance task. They never log into a RAPID AI dashboard. They never change their process. They get better diagnoses.

2. Channel flexibility. The same API serves the SvelteKit Explorer (for customers who want a standalone dashboard), a mobile app (for field technicians), a chatbot (for the copilot), a Slack integration (for alert notifications), and a Power BI connector (for management reporting). One engine, many surfaces.

3. Metered monetization. API calls are countable, auditable, and tier-able. A free-tier customer making 100 diagnoses per month costs a known amount in compute. An enterprise customer making 100,000 diagnoses per month pays proportionally. This is cleaner than seat-based pricing for industrial software where one engineer might manage 500 assets.

4. Ecosystem creation. When the API is stable and well-documented, third-party developers build integrations that RAPID AI’s own team would never prioritize. A vibration analysis vendor builds a plugin that sends their data to RAPID AI. A reliability consulting firm builds a custom dashboard for their clients. These integrations expand the platform’s reach without expanding the team.

---

32.2 API Product Tiers

RAPID AI’s API is offered in three tiers designed for different stages of customer adoption. The tiers differ in volume, capability, and deployment model — not in API surface. Every tier uses the same endpoints, the same request/response schemas, and the same authentication mechanism. The difference is what happens when the customer exceeds their tier’s limits or requests a capability reserved for a higher tier.

Tier Summary

Dimension	Free	Professional	Enterprise
Diagnoses per month	100	10,000	Unlimited
Assets	5	Unlimited	Unlimited
Rule library	Basic (50 rules)	Full (451+ rules)	Full + custom rules
Modules	A, B (fault detection)	A through G (full pipeline)	A through G + custom modules
RUL estimation	Not included	Included (F001-F003)	Included + custom models
CDE analysis	Not included	Included	Included + design recommendation
Causal analysis	Not included	FRETTLSM (88 factors)	FRETTLSM + customer taxonomy overlay
RCM workbook	Not included	Standard	Customizable per asset class
Copilot API	Not included	Included (100 queries/month)	Unlimited
Data retention	30 days	1 year	Configurable (1-10 years)
Deployment	Cloud (shared)	Cloud (dedicated tenant)	Cloud, hybrid, or on-premise
SLA	Best effort	99.5% uptime	99.9% uptime, 4-hour response
Support	Community / docs	Email, 48-hour response	Dedicated engineer, 4-hour response
Rate limit	10 req/min	100 req/min	Custom (up to 1,000 req/min)
Price	$0	$2,500/month	Custom quote

Free Tier Purpose

The free tier exists for evaluation, not production. It gives a reliability engineer enough access to diagnose a handful of assets, see the quality of RAPID AI’s physics-based reasoning, and compare it against their existing tools. The 50-rule subset covers the most common failure modes for pumps, motors, and gearboxes — enough to demonstrate value without exposing the full intellectual property.

Professional Tier

The professional tier is the standard production offering. It unlocks the complete A-through-G diagnostic pipeline, the full 451+ rule library, RUL estimation, CDE contradiction analysis, FRETTLSM causal mapping, and the copilot API. Most industrial customers with 50-500 assets operate comfortably at this tier.

Enterprise Tier

The enterprise tier adds capabilities that require custom engineering: on-premise deployment (the customer’s infrastructure, RAPID AI’s software), custom rule libraries (rules specific to the customer’s equipment or process), custom ML models trained on the customer’s failure history, and SLA guarantees backed by a dedicated support engineer. This tier is priced per engagement because the deployment and customization effort varies significantly.

---

32.3 Core API Endpoints

The RAPID AI API exposes 35+ endpoints organized by domain. All endpoints are prefixed with /api/v1/ and require authentication via Bearer token or API key. Request and response bodies are JSON. The API follows pragmatic REST conventions: resources are nouns, actions that do not map cleanly to CRUD use POST with a verb path segment.

Asset Management

Method	Endpoint	Description	Tier
GET	/assets	List all assets for the authenticated tenant	All
GET	/assets/{asset_id}	Get asset configuration, metadata, and sensor map	All
POST	/assets	Create a new asset with equipment type and subsystem map	All
PUT	/assets/{asset_id}	Update asset configuration (thresholds, baselines)	All
DELETE	/assets/{asset_id}	Decommission an asset (soft delete, preserves history)	Pro+
GET	/assets/{asset_id}/dependencies	Get upstream/downstream asset relationships	Pro+
GET	/assets/{asset_id}/sensor-map	Get sensor assignments and measurement points	All

Diagnostics

Method	Endpoint	Description	Tier
POST	/diagnostics/run	Run full diagnostic pipeline for an asset	All
POST	/diagnostics/batch	Submit multiple assets for batch diagnosis (async)	Pro+
GET	/diagnostics/{diagnostic_id}	Retrieve a completed diagnostic result	All
GET	/diagnostics/{diagnostic_id}/stream	SSE stream of pipeline progress and partial results	Pro+
GET	/assets/{asset_id}/diagnostics	Diagnostic history for an asset (paginated)	All
GET	/assets/{asset_id}/diagnostics/latest	Most recent diagnostic result	All
GET	/assets/{asset_id}/failure-modes	Active failure mode hypotheses with confidence scores	All

Prognostics (RUL)

Method	Endpoint	Description	Tier
POST	/assets/{asset_id}/rul/predict	Estimate remaining useful life using current state	Pro+
GET	/assets/{asset_id}/rul/history	RUL estimates over time (trending)	Pro+
POST	/rul/compare	Compare RUL across multiple assets (fleet prioritization)	Pro+

RCM (Reliability-Centered Maintenance)

Method	Endpoint	Description	Tier
POST	/assets/{asset_id}/rcm/evaluate	Run RCM decision logic for detected failure modes	Pro+
GET	/assets/{asset_id}/rcm/workbook	Generate RCM workbook for the asset	Pro+
POST	/rcm/optimize	Optimize maintenance strategy across a fleet	Enterprise

Causal Analysis

Method	Endpoint	Description	Tier
POST	/assets/{asset_id}/causal/analyze	Map failure evidence to FRETTLSM taxonomy	Pro+
GET	/assets/{asset_id}/causal/chain	Get root cause chain (initiators, accelerators, retarders)	Pro+
POST	/causal/frettlsm	Direct FRETTLSM factor evaluation (no asset context)	Pro+

CDE (Contradiction-Driven Engineering)

Method	Endpoint	Description	Tier
POST	/assets/{asset_id}/cde/detect	Detect engineering contradictions from failure history	Pro+
POST	/assets/{asset_id}/cde/resolve	Generate resolution pathways using Altshuller principles	Enterprise
GET	/assets/{asset_id}/contradictions	List detected contradictions for an asset	Pro+

Confidence and Entropy

Method	Endpoint	Description	Tier
GET	/diagnostics/{diagnostic_id}/confidence	Detailed confidence breakdown by module	Pro+
POST	/confidence/calibrate	Submit ground-truth outcome for confidence calibration	Enterprise
POST	/assets/{asset_id}/entropy/analyze	SEDL entropy analysis (SE, TE, DE, SI)	Pro+
GET	/assets/{asset_id}/entropy/history	Entropy trending over time	Pro+

Dashboard and Reporting

Method	Endpoint	Description	Tier
GET	/dashboard/assets/{asset_id}/health-card	UI-ready health card payload	All
GET	/dashboard/plant-overview	Plant-level summary with priorities and worst-first ranking	Pro+
GET	/dashboard/fleet-summary	Fleet health aggregate (healthy/warning/critical counts)	Pro+

Copilot

Method	Endpoint	Description	Tier
POST	/copilot/query	Natural language diagnostic query	Pro+
GET	/copilot/sessions/{session_id}	Retrieve conversation history	Pro+
POST	/copilot/query/stream	Streaming copilot response (SSE)	Pro+

Administration

Method	Endpoint	Description	Tier
POST	/admin/schema/reload	Reload rule libraries and configuration tables	Pro+
GET	/admin/usage	API usage statistics for the current billing period	All
GET	/admin/health	Service health check (database, cache, LLM connectivity)	All
GET	/reference/failure-modes	Browse the failure mode library	All
GET	/reference/maintenance-tasks	Browse the maintenance task catalog	All

The single most important endpoint is POST /assets/{asset_id}/end-to-end-evaluate. This endpoint runs the complete RAPID AI chain — diagnosis, RCM decision, maintenance planning, and dashboard formatting — in a single call. A customer who only ever calls this one endpoint still gets the full value of the platform. The complexity of 451 rules, 88 causal factors, 7 pipeline stages, and 4 engineering frameworks is collapsed into one request and one response.

---

32.4 Integration Patterns

Enterprises integrate with RAPID AI in four patterns. The choice depends on the customer’s operational technology stack, latency requirements, and engineering workflow.

Pattern 1: Webhook-Based (Push)

RAPID AI pushes diagnostic alerts to the customer’s endpoint when conditions change. The customer registers a webhook URL and specifies trigger conditions.

Customer registers:
  POST /api/v1/webhooks
  {
    "url": "https://customer.example.com/rapid-ai/alerts",
    "events": ["diagnostic.critical", "diagnostic.warning", "rul.threshold"],
    "secret": "hmac-shared-secret-for-verification"
  }

RAPID AI pushes:
  POST https://customer.example.com/rapid-ai/alerts
  {
    "event": "diagnostic.critical",
    "asset_id": "P-101",
    "aesf_state": "S4",
    "priority_score": 92,
    "failure_mode": "AFB09 -- Bearing outer race defect",
    "recommended_action": "ACT005 -- Bearing replacement (emergency)",
    "timestamp": "2026-03-17T08:45:00Z"
  }
  X-Webhook-Signature: sha256=<hmac of body>

The customer’s CMMS receives this webhook, auto-creates a work order, assigns a maintenance team, and reserves spare parts. No human needed to bridge the gap between diagnosis and action. Webhook delivery uses retry with exponential backoff (3 attempts over 15 minutes) and logs delivery status for the customer to audit.

Pattern 2: Polling

The customer queries RAPID AI on a schedule. This is the simplest integration pattern and requires no inbound network access on the customer’s side.

Every 15 minutes, customer's scheduler runs:
  GET /api/v1/assets/{asset_id}/diagnostics/latest
  -> If state changed since last poll, trigger internal workflow

Polling is appropriate for customers who cannot accept inbound webhooks (common in air-gapped or heavily firewalled industrial environments). The trade-off is latency: a critical alert detected at minute 1 is not seen until minute 15. For most condition monitoring use cases this is acceptable — machinery degradation occurs over hours and days, not seconds.

Pattern 3: Streaming (Real-Time)

For customers with real-time monitoring requirements, RAPID AI provides Server-Sent Events (SSE) for one-way push and WebSocket for bidirectional communication.

SSE connection:
  GET /api/v1/events?assets=P-101,P-102,CW-SYSTEM
  Accept: text/event-stream

  data: {"event":"diagnostic.completed","asset_id":"P-101","state":"S2","ssi":0.72}
  data: {"event":"sensor.threshold","asset_id":"P-102","sensor":"DE-VIB-H","value":4.8}
  data: {"event":"rul.updated","asset_id":"P-101","rul_days":42,"change":-3}

Streaming is used by customers who build their own real-time dashboards or feed RAPID AI results into control room displays. The SSE endpoint filters events to only the assets the authenticated user is authorized to see (tenant isolation applies at the event stream level, not just at the request level). WebSocket is reserved for the copilot, where bidirectional communication is required (the engineer sends messages, the LLM streams responses token by token).

Pattern 4: Batch

For customers who process data in bulk — overnight sensor data dumps, weekly maintenance reviews, or fleet-wide health assessments — RAPID AI accepts batch submissions.

Submit batch:
  POST /api/v1/diagnostics/batch
  {
    "assets": ["P-101", "P-102", "P-103", ..., "P-147"],
    "sensor_data_source": "s3://customer-bucket/weekly-export/2026-03-17.csv",
    "callback_url": "https://customer.example.com/rapid-ai/batch-results"
  }

Response (immediate):
  { "batch_id": "batch_20260317_001", "status": "accepted", "asset_count": 47 }

Callback (when complete):
  POST https://customer.example.com/rapid-ai/batch-results
  {
    "batch_id": "batch_20260317_001",
    "status": "completed",
    "results_url": "/api/v1/diagnostics/batch/batch_20260317_001/results",
    "summary": { "total": 47, "critical": 3, "warning": 11, "healthy": 33 }
  }

Batch jobs run on a dedicated queue with lower priority than real-time requests but without rate limiting applied per-request. A 500-asset batch counts as a single operation against the customer’s monthly diagnosis quota (not 500 separate diagnoses), making it economical for fleet-wide assessments.

---

32.5 SDK and Developer Experience

An API is only as good as the developer experience around it. RAPID AI provides SDKs, documentation, and tooling that reduce integration time from weeks to hours.

Python SDK

from rapid_ai import RapidAIClient

client = RapidAIClient(
    api_key="sk-rapid-...",
    base_url="https://api.rapid-ai.com/api/v1"
)

# Run a diagnosis
result = client.diagnostics.run(
    asset_id="P-101",
    sensor_data={
        "DE-VIB-H": 4.2, "DE-VIB-V": 3.1, "DE-VIB-A": 2.8,
        "NDE-VIB-H": 2.1, "bearing_temp": 72.5
    }
)

print(result.aesf_state)          # "S3"
print(result.priority_score)      # 73
print(result.failure_modes[0].id) # "AFB09"
print(result.recommended_actions) # [Action(code="ACT005", window="7 days")]

# Estimate RUL
rul = client.rul.predict(asset_id="P-101")
print(f"Estimated {rul.rul_days} days remaining (+/-{rul.uncertainty_days} days)")

# Stream events
for event in client.events.stream(assets=["P-101", "P-102"]):
    if event.type == "diagnostic.critical":
        trigger_work_order(event)

The Python SDK is published as rapid-ai-client on PyPI. It wraps the REST API with typed dataclasses, handles authentication, retries transient failures, and provides both synchronous and async interfaces (RapidAIClient for sync, AsyncRapidAIClient for use with asyncio).

TypeScript SDK

import { RapidAI } from '@rapid-ai/client';

const client = new RapidAI({
  apiKey: process.env.RAPID_AI_KEY,
  baseUrl: 'https://api.rapid-ai.com/api/v1'
});

const result = await client.diagnostics.run({
  assetId: 'P-101',
  sensorData: {
    'DE-VIB-H': 4.2, 'DE-VIB-V': 3.1, 'DE-VIB-A': 2.8,
    'NDE-VIB-H': 2.1, 'bearing_temp': 72.5
  }
});

console.log(result.aesfState);    // "S3"
console.log(result.priorityScore); // 73

The TypeScript SDK is published as @rapid-ai/client on npm. It provides full type definitions generated from the OpenAPI spec, enabling autocomplete and compile-time validation in IDEs.

OpenAPI Specification

The OpenAPI 3.1 spec is the single source of truth for the API contract. It is auto-generated from the FastAPI backend’s Pydantic models (every endpoint’s request body, response body, and error schema is defined in Python, and FastAPI generates the OpenAPI spec at build time). The spec is published at:

• /api/v1/openapi.json — machine-readable spec for code generation
• /api/v1/docs — Swagger UI for interactive exploration
• /api/v1/redoc — ReDoc for reference-style documentation

Both SDKs are generated from this spec using openapi-generator, ensuring that the SDKs always match the backend’s actual behavior. When the API changes, the spec updates, the SDKs regenerate, and type errors surface at build time in customer integrations.

Code Examples for Common Workflows

The developer documentation includes worked examples for the five most common integration scenarios:

1. CMMS integration: Receive webhook alerts, create work orders in SAP PM via RFC, attach diagnostic report as PDF.
2. SCADA data ingestion: Read OPC-UA tags, format as RAPID AI sensor data payload, submit for diagnosis on a schedule.
3. Fleet health dashboard: Poll all assets daily, aggregate results, render in Power BI using the REST connector.
4. Predictive spare parts: Use RUL estimates to forecast bearing replacements 90 days out, feed into procurement planning.
5. Copilot chatbot: Embed the copilot API in a Microsoft Teams bot so engineers can ask diagnostic questions from their existing communication tool.

Each example includes complete source code in both Python and TypeScript, expected request/response payloads, and error handling patterns.

---

32.6 Data Privacy and Compliance

Multi-Tenant Isolation

Every API request is tenant-scoped. Tenant isolation is enforced at the database level using PostgreSQL Row-Level Security (RLS):

• Every table with tenant-scoped data includes a tenant_id column.
• RLS policies ensure that queries can only see rows belonging to the authenticated tenant.
• Even if application code has a bug that omits a WHERE tenant_id = ... clause, the database rejects the query or returns an empty result.

This means tenant A’s diagnostic data, asset configurations, rule customizations, and copilot conversations are invisible to tenant B — not just at the API layer, but at the storage layer. There is no application-level filtering that could be bypassed.

Data Residency

Enterprise customers can specify data residency requirements:

Region	Data Location	API Endpoint
EU	Frankfurt (eu-central-1)	https://eu.api.rapid-ai.com
US	Virginia (us-east-1)	https://us.api.rapid-ai.com
APAC	Mumbai (ap-south-1)	https://ap.api.rapid-ai.com
On-premise	Customer’s network	Customer-configured

Data residency is configured at the tenant level. A multinational customer can have their European plants on the EU endpoint and their North American plants on the US endpoint, with no cross-region data transfer.

GDPR Considerations

Diagnostic data is primarily machine data (sensor readings, equipment conditions, maintenance records), not personal data. However, GDPR applies in two areas:

1. User accounts: Engineer names, email addresses, and role assignments are personal data. These are stored in the identity service, subject to the customer’s data retention policy, and deletable on request (right to erasure).
2. Copilot conversations: If an engineer mentions a colleague by name in a copilot session, that conversation contains personal data. Copilot transcripts are retained per the customer’s configured retention period and can be purged on request.

Machine data (sensor readings, diagnostic results, failure mode scores) does not constitute personal data under GDPR and is retained for the full configured period without restriction.

ISO 27001 Alignment

RAPID AI’s security controls align with ISO 27001 Annex A:

Control Area	Implementation
A.9 Access control	RBAC, API key scoping, tenant isolation
A.10 Cryptography	TLS 1.3 in transit, AES-256 at rest
A.12 Operations security	Audit logging, secret rotation, vulnerability scanning
A.13 Communications security	Network segmentation, internal mTLS option
A.14 System development	OpenAPI-driven development, Pydantic/Zod validation
A.18 Compliance	Data residency options, retention policies, right to erasure

Audit Logging

Every API call is logged with:

• Request timestamp, request ID, tenant ID, user ID
• Endpoint called, HTTP method, response status code
• Processing time (total and per-module breakdown)
• IP address and user agent

Audit logs are immutable (append-only), retained for 2 years (configurable for enterprise), and exportable in JSON or CSV format via GET /api/v1/admin/audit-log. Customers can feed these logs into their own SIEM systems for security monitoring.

---

32.7 Versioning and Lifecycle

Versioning Strategy

The API uses URL-based versioning: /api/v1/, /api/v2/. Semantic versioning applies within each major version:

• Patch changes (backward-compatible bug fixes): No version change. Deployed transparently.
• Minor changes (backward-compatible additions): No version change. New fields appear in responses; existing fields remain unchanged. New endpoints appear; existing endpoints remain unchanged.
• Major changes (breaking changes): New version prefix (v2). The previous version continues to operate during the deprecation period.

What Constitutes a Breaking Change

Change Type	Breaking?	Example
Add a new optional response field	No	Adding entropy_trend to diagnostic result
Add a new endpoint	No	Adding GET /assets/{id}/entropy/history
Add a new optional request parameter	No	Adding depth parameter to /diagnostics/run
Remove a response field	Yes	Removing legacy_score from diagnostic result
Rename a response field	Yes	Renaming priority_score to risk_score
Change a field’s type	Yes	Changing rul_days from integer to float
Remove an endpoint	Yes	Removing GET /dashboard/legacy-view
Change authentication mechanism	Yes	Requiring OAuth where API key was sufficient

Deprecation Policy

When a breaking change is necessary:

1. 6 months before: Announce deprecation via changelog, email to all API key holders, and Deprecation header on affected endpoints.
2. 3 months before: Publish migration guide with before/after code examples for both SDKs.
3. 1 month before: Add Sunset header with the removal date. Affected endpoints return a Warning header on every response.
4. Removal date: Old version returns 410 Gone with a redirect to the migration guide. Enterprise customers with active SLAs receive an additional 3-month grace period.

Migration Guides

Each major version bump is accompanied by a migration guide that includes:

• A summary of every breaking change with rationale
• Before/after code examples in Python and TypeScript
• SDK upgrade instructions (pip install rapid-ai-client>=2.0 / npm install @rapid-ai/client@^2.0)
• A compatibility mode flag (X-API-Compat: v1) that maps v1 field names to v2 responses for a transitional period
• A machine-readable changelog at GET /api/v1/changelog documenting every addition and removal with dates

---

32.8 Rate Limiting and Fair Use

Per-Tier Rate Limits

Tier	Sustained Rate	Burst Allowance	Monthly Quota
Free	10 req/min	20 req in 10 sec	100 diagnoses
Professional	100 req/min	200 req in 10 sec	10,000 diagnoses
Enterprise	Custom (up to 1,000 req/min)	Custom	Unlimited

Rate limits apply per API key. A customer with multiple API keys gets independent limits per key. Rate limit status is communicated via response headers on every request:

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 73
X-RateLimit-Reset: 1710662400
X-Monthly-Quota-Remaining: 8547

429 Response Handling

When a rate limit is exceeded, the API returns 429 Too Many Requests with a Retry-After header:

{
  "error": "rate_limit_exceeded",
  "message": "Rate limit of 100 requests per minute exceeded. Retry after 12 seconds.",
  "retry_after_seconds": 12,
  "tier": "professional",
  "upgrade_url": "https://rapid-ai.com/pricing"
}

Both SDKs implement automatic retry with exponential backoff when receiving a 429 response. The Python SDK waits for the Retry-After duration, then retries up to 3 times. The TypeScript SDK does the same. Customer code using the SDKs never needs to handle rate limiting manually.

Priority Queuing

Enterprise-tier requests are routed to a priority queue that is processed ahead of professional and free-tier requests. During peak load:

• Enterprise requests: processed immediately (dedicated compute allocation)
• Professional requests: queued with a target latency of less than 5 seconds
• Free requests: queued with a target latency of less than 30 seconds

This ensures that paying enterprise customers with SLA guarantees are never delayed by free-tier evaluation traffic.

Endpoint-Specific Cost Weighting

Not all endpoints consume equal compute. Rate limits use a weighted model:

Endpoint Category	Weight	Rationale
Read operations (GET /assets, /health)	1x	Simple database reads, cached
Diagnostic (/diagnostics/run, /end-to-end-evaluate)	3x	Full pipeline execution across modules A-E
Copilot (/copilot/query)	5x	LLM inference cost
Reference data (/reference/*)	1x	Cached, low compute
Batch (/diagnostics/batch)	1x per batch	Not per-asset; encourages batch over individual calls

A professional-tier customer with a 100 req/min limit can make 100 reference queries per minute, or 33 diagnostic calls per minute, or 20 copilot queries per minute. The weighted model prevents a copilot-heavy integration from starving diagnostic capacity.

Fair Use Policy

Beyond the hard rate limits, RAPID AI enforces a fair use policy for behaviors that degrade the system for other tenants:

• Excessive polling: Customers polling the same endpoint more than once per second are rate-limited to 1 request per 5 seconds for that endpoint.
• Large batch abuse: Batch requests with more than 1,000 assets are rejected with a 413 Payload Too Large response and a recommendation to split into multiple batches.
• Unused asset slots: Free-tier customers who register 5 assets but never run a diagnosis within 90 days have their assets archived (restorable on request).

---

32.9 Error Handling

The API uses standard HTTP status codes with structured error bodies that include enough information for programmatic handling and human debugging.

Error Response Schema

{
  "error": "validation_error",
  "message": "Sensor data for asset P-101 is missing required field 'DE-VIB-H'.",
  "details": [
    {
      "field": "sensor_data.DE-VIB-H",
      "issue": "required",
      "message": "Horizontal vibration at drive end is required for pump diagnostics."
    }
  ],
  "request_id": "req_7f3a2b1c",
  "documentation_url": "https://docs.rapid-ai.com/errors/validation_error"
}

Status Code Reference

Code	Meaning	When Returned
200	Success	Synchronous request completed
202	Accepted	Async request queued (batch, long-running diagnosis)
400	Bad Request	Validation error in request body
401	Unauthorized	Missing or invalid API key/token
403	Forbidden	Valid auth but insufficient tier or role
404	Not Found	Asset, diagnostic, or resource does not exist
409	Conflict	Concurrent modification (e.g., two simultaneous asset updates)
410	Gone	Deprecated endpoint past its sunset date
413	Payload Too Large	Batch request exceeds maximum size
422	Unprocessable Entity	Sensor data is syntactically valid but physically implausible
429	Too Many Requests	Rate limit or monthly quota exceeded
500	Internal Server Error	Unexpected backend failure (logged, alerted, investigated)
503	Service Unavailable	Diagnostic engine temporarily overloaded or in maintenance

The 422 status deserves special mention. RAPID AI validates sensor data not just syntactically (is it a number?) but physically (is a bearing temperature of 850 degrees Celsius plausible?). Implausible data is rejected before it enters the diagnostic pipeline, preventing garbage-in-garbage-out diagnoses. The error message explains which reading is suspect and what the expected range is for the asset’s equipment type.

---

32.10 What This Architecture Enables

RAPID AI as an API product means that the diagnostic intelligence built over the preceding 31 chapters is not locked inside a single application. It is a service that any system can consume. A SAP PM workflow can call it. A mobile app can call it. A Power BI report can call it. A customer’s home-grown analytics platform can call it. The SvelteKit Explorer is merely the first consumer — and because it uses the same API as everyone else, it proves that the API is sufficient for building a complete user experience.

The API-first architecture also means that RAPID AI’s business model scales with value delivered, not with seats licensed. A customer who diagnoses 10,000 assets per month pays for 10,000 diagnoses. A customer who diagnoses 100 pays for 100. The physics-based intelligence is the same at both scales; only the volume changes. That is the economics of an API product, and it is the right model for an engineering intelligence platform that aspires to serve every rotating machine on Earth.

---

Standards Alignment

Standard	Relevance to This Chapter
ISO 13374 — Condition monitoring and diagnostics of machines	The API product exposes ISO 13374’s complete processing chain as consumable REST endpoints, enabling enterprise customers to integrate standards-compliant diagnostic intelligence into their existing operational technology stack.
MIMOSA OSA-CBM — Open System Architecture for CBM	The API-first architecture directly implements OSA-CBM’s interoperability vision by providing standardized interfaces that connect RAPID AI’s diagnostic intelligence with CMMS, SCADA, historians, and analytics platforms.
OWASP Top 10 — Web application security	The API product tiers implement OWASP-compliant security practices including API key authentication, rate limiting, input validation, and audit logging across all access levels.
IEC 62443 — Industrial cybersecurity	The on-premise deployment option and metered API access model support IEC 62443’s requirements for controlled, auditable access to industrial diagnostic systems with appropriate security boundaries.

Changelog

Version	Date	Author	Changes
2.1.0	2026-03-17	Rick D	Added standards alignment, living doc metadata, changelog
2.0.0	2026-03-17	Rick D	Enriched with production codebase content
1.0.0	2026-03-17	Rick D	Initial chapter creation