Send sensor readings, get back a structured diagnosis — root cause, the part to replace, a local Philippine supplier who stocks it, and a repair procedure. Server-to-server; authenticate with the X-API-Key header.
Endpoint
Request
curl
curl — with history (enables predictive trend alerts)
Response fields
| diagnosis | Root-cause analysis + the part to replace + repair SOP. |
| suppliers[] | Local PH suppliers stocking the part — business, city, contact, items with price + stock. |
| parts_links[] | Distributor links (Lazada / Shopee / Mouser / DigiKey). |
| predictive_alerts[] | Trend warnings when a sensor is moving toward a documented limit (e.g. discharge temp climbing toward the HVAC reference ceiling). Present only when you send sensor_history. Each item: {sensor, alert}. |
| confidence | high / medium / low — how well your device is covered by the knowledge base. |
| kb_grounded | true when the diagnosis is backed by enough KB content for this device. |
| kb_chunk_count | How many KB documents matched this device type. |
| caution | Present when coverage is thin — see "Handle uncovered devices" below. |
| request_id | Echoed back; use it to make retries idempotent. |
Handle uncovered devices
The API always returns a diagnosis, but it tells you when it's on thin ice. Check kb_grounded: when it's false (or confidence is low), route that device to a human technician instead of acting on the result automatically. That's how you keep automated decisions safe.
Continuous monitoring (predictive)
For predictive maintenance, have your monitoring platform POST readings on a schedule (e.g. every few minutes) and include sensor_history — the recent readings for each sensor, oldest first. The API then returns predictive_alerts flagging a sensor that is trending toward a known limit before it trips, so you can schedule service proactively rather than reacting to a failure. These alerts reference general published limits (e.g. HVAC discharge-temperature and ANSI voltage bands) — always verify against the specific unit's nameplate/spec. A statistical remaining-useful-life forecast tier is on the roadmap; today's alerts are rule-based and grounded in cited limits.
Rate limits & quota
Your per-minute rate limit and monthly call quota are shown on the My Key tab. Exceeding the rate limit returns 429; passing your monthly quota returns 403.
Expected latency — set your timeout to 120s
Diagnosis is AI-generated and takes 20–40 seconds typically (log forensics: 40–70s). The first request after a server deploy can add ~10s. Set your HTTP client timeout to 120 seconds — a 30s default timeout will abort calls that are working normally.
Field names must match exactly
Unknown JSON fields are accepted and silently ignored (so extra fields never break your integration). The flip side: a misspelled field is dropped without error — send sensors (not readings) and notes (not symptoms). If a valid-looking call returns a diagnosis asking you for data you already sent, check your field names first.
Close the loop: confirm outcomes (recommended)
Every diagnosis returns an outcome_token. After the repair, tell us whether the diagnosis was right:
POST /api/iot/feedback
{"outcome_token":"oc_...", "was_correct":true, "actual_fix":"replaced run capacitor 45uF"}
Write-once: a second submission for the same token returns 409. Confirmed outcomes improve diagnosis quality for your device types over time.
Log forensics
POST /api/iot/forensics with {"log_text":"...", "device_type":"...", "context":"..."} (up to 20KB) returns a structured root-cause report from a raw device log. API keys, emails, IPs and other secrets are redacted before analysis. Slower than diagnose — allow up to 70s.