Before you debug, find out whether it is even yours
The Service Status & Incident API returns live up/down status and incident data for hundreds of vendors as clean JSON.
7 active endpoints. Every call is 1 credit.
- POST/status-intel/v1/status
- POST/status-intel/v1/incidents
- POST/status-intel/v1/components
- POST/status-intel/v1/summary
- POST/status-intel/v1/check_multi
- POST/status-intel/v1/batch
- POST/status-intel/v1/list_vendors
What Service Status & Incident endpoints does ReefAPI ship?
7 live read endpoints. Read-only data API: no writes, no account actions, no dashboard access on the target site.
Service Status & Incident API
3 of 7 endpoints, ready to run
One vendor's current state: the indicator, the human description, whether it is operational, the active incident count and when the page last updated.
{ "ok": true, "meta": { "api": "status-intel", "endpoint": "status", "mode": "live", "latency_ms": 692.1, "record_count": 1, "cache_hit": false }, "data": { "vendor": "github", "name": "GitHub", "kind": "statuspage", "platform": "statuspage", "generic": false, "category": "dev-tools", "indicator": "operational", "raw_indicator": "none", "description": "All Systems Operational", "is_operational": true, "updated_at": "2026-08-29T13:58:52.463Z", "active_incident_count": 0, "source_url": "https://www.githubstatus.com/api/v2/summary.json" } }
How the Service Status & Incident API works
Service Status & Incident is a normal ReefAPI surface — the same four rules that hold for every other engine on the key.
No OAuth app, no request signing, no per-site account. One key covers all 184 engines.
Every route is a POST with a JSON body. Parameters are validated against the published schema before anything is charged.
Credits, not seats. Failed and blocked calls are never charged, and cache hits cost nothing.
One envelope everywhere. meta carries latency_ms, record_count and the endpoint that answered.
The first thing an on-call engineer should check
Half of all pages at three in the morning are somebody else's outage. The check takes one call and it is the cheapest possible way to not spend an hour in your own logs.
{"vendors": ["github", "openai", "cloudflare"]}One call covering your whole dependency list. Returns an all-operational boolean plus the degraded vendors named.
{"vendor": "openai", "active_only": true}For whichever one came back degraded — the open incident with its current status and update history.
The multi-check answered three vendors in about a second and correctly reported one of them as degraded while the other two were clean.
curl -X POST https://api.reefapi.com/status-intel/v1/status \
-H "x-api-key: $REEF_KEY" \
-H "content-type: application/json" \
-d '{"vendor":"github"}'{
"ok": true,
"data": { … },
"meta": {
"api": "status-intel",
"endpoint": "status",
"mode": "live",
"latency_ms": …,
"record_count": …
},
"error": null
}Statuspage /api/v2/*.json paths, and the action that replaces each one
If you have been hitting status.<vendor>.com/api/v2/... directly, this is the mapping. Those paths work, but only for vendors hosted on Atlassian Statuspage, only if you already know each vendor's status host, and every vendor is a separate integration. One action here covers all of them and returns the same answer in a normalized shape.
| Statuspage JSON path | Call this instead | What comes back |
|---|---|---|
| /api/v2/status.json | status | One normalized indicator — operational, degraded, partial_outage, major_outage or maintenance — plus an is_operational boolean and the vendor's own description. |
| /api/v2/incidents/unresolved.json | incidents with active_only true | Only the incidents happening right now. This is the is-it-down-this-minute call. |
| /api/v2/incidents.json | incidents | Recent incident history, most recent first: title, impact, status, the full update timeline and affected components. limit defaults to 25, cap 100. |
| /api/v2/components.json | components | Per-component health, so you can see that it is the API that is degraded and not the dashboard. |
| /api/v2/summary.json | summary | Status, components and active incidents rolled into one response. |
| no equivalent | check_multi | Up to 25 vendors in a single call, each resolved to its real status page. One item failing never fails the call. |
Not every vendor runs on Statuspage. Five vendors are handled with their own readers and list_vendors marks them kind=special: AWS, Microsoft Azure, Google Cloud, Slack and Stripe. Measured 2026-08-27: list_vendors returns 91 vendors, 86 kind=statuspage and 5 kind=special, and the unsupported map is empty — every listed vendor is currently readable.
Where the answers come from, and where the list ends
Measured across the supported vendor list. The last row is the honest boundary.
Each answer names the source URL it read and the platform the page runs on. This is not an independent probe of the service — it is the vendor's own published state, normalised into one shape so ninety-one of them can be read the same way.
The supported list is itself callable, with each vendor's key, display name, category and status host. You can validate a dependency list against it at build time rather than discovering an unsupported name in production.
Passing a list back gets the operational count, the degraded vendors named and a single boolean. That is the shape a health dashboard or an on-call bot wants — one call for the whole dependency graph rather than one per vendor.
Vendors use different vocabularies for the same states. The response returns both our normalised indicator and the vendor's own raw value, so you can build on the normalised form without losing the original wording when someone asks what the page actually said.
Status pages are updated by humans, often late, and a partial outage frequently shows green for the first twenty minutes. Reading one tells you whether the vendor has admitted a problem, which is genuinely useful and is not the same as whether there is one.
What people build with Service Status & Incident
The jobs this data is most often used for.
endpoints
credit per call
Monitoring dashboards call check_multi to show the live status of every SaaS a company depends on.
Incident tooling uses incidents to alert when a critical vendor reports an outage.
Reliability teams use summary and components to track a vendor's uptime history over time.
What Service Status & Incident data costs
The cheapest call here is 1 credit, so $15/mo (Pro) buys 10,000 of them — $1.50 per 1,000 credits. Credits roll over and never expire, and failed or blocked calls are not charged.
Full pricing →- 1,000 free credits on signup, no card
- One key, all 184 APIs, one credit pool
- Failed and blocked calls are never charged
- Credits roll over and never expire
Call it in two lines
Sign up, get 1,000 credits and one key that works on every engine. Then this is the whole protocol.
curl -X POST https://api.reefapi.com/status-intel/v1/status \
-H "x-api-key: $REEF_KEY" \
-H "content-type: application/json" \
-d '{"vendor":"github"}'import requests
r = requests.post(
"https://api.reefapi.com/status-intel/v1/status",
headers={"x-api-key": REEF_KEY},
json={
"vendor": "github"
},
)
print(r.json()["data"])Have a question? We got answers.
The questions people actually ask before wiring up Service Status & Incident.
Get a free key →What does status.stripe.com/api/v2/incidents/unresolved.json return?▾
That is Atlassian Statuspage's public v2 JSON feed, and the unresolved path returns just the incidents that are open right now for that one vendor — an empty list when nothing is wrong. It is fine for a single vendor, but it only exists for Statuspage-hosted vendors, you have to know each vendor's exact status host, and every vendor you add is another endpoint to maintain. The incidents action with active_only true gives you the same answer for any vendor and finds the status host itself. Measured on 2026-08-26, asking for Stripe returned zero active incidents.
Can I check a vendor that is not on your list?▾
Yes. vendor takes a curated key (github, openai, aws, stripe) or any status-page host or URL you hand it — status.example.com works even if we have never seen that vendor. The curated set is a convenience, not a wall. list_vendors returned 91 curated vendors on 2026-08-26, each with its key, display name, kind, category, status host and homepage, across ai, cloud, dev-tools, observability, fintech, email, productivity, search and analytics.
How do I check my whole stack in one request?▾
check_multi is the dashboard call. Hand it up to 25 items — curated keys, bare brand names, plain domains or status hosts, as a JSON array or a comma-separated string — and each one is resolved to its real status page and read live. Per-item errors are reported per item and never fail the whole response, so one unreachable vendor does not blank your dashboard.
Do AWS, GCP and Slack work? They do not use Statuspage.▾
They work. Statuspage and Instatus pages are parsed generically, and AWS, GCP, Slack and Stripe have dedicated readers — list_vendors flags those as kind=special. The output shape is the same either way, so your code does not branch on which platform a vendor happens to use. If a vendor ever becomes unreadable it is listed in unsupported with the reason rather than reported as healthy; that map was empty when we last measured it on 2026-08-27.
How do I tell which specific product is down, not just the vendor?▾
Call components. A vendor-level indicator only tells you something is wrong somewhere; components returns per-sub-service health, which is how you find out that the REST API is degraded while the web dashboard is fine. Pair it with incidents for the write-up and the timeline of updates.
What is the Service Status & Incident API?▾
Service Status & Incident API is a ReefAPI endpoint group for service status & incident It returns live JSON through POST requests under /status-intel/v1.
Is the Service Status & Incident API free to try?▾
Yes. ReefAPI starts with 1,000 free credits, no card required. Service Status & Incident calls use the same shared credit balance as every other ReefAPI engine.
Do I need a Service Status & Incident login or account?▾
No login to Service Status & Incident is needed for the API response. You call ReefAPI with your x-api-key header, and the playground can run live examples before you create a production key.
How fresh is the Service Status & Incident data?▾
The page example is captured from a live status call, and production requests fetch live data through ReefAPI rather than a static sample.
How many credits does the Service Status & Incident API use?▾
Service Status & Incident actions currently cost 1 credit per successful call. Failed or blocked calls are free, and all APIs draw from one credit pool.
Can I call Service Status & Incident from an AI assistant or MCP client?▾
Yes. Connect ReefAPI once through MCP and your assistant can call status-intel actions with the same key, credit pool and JSON envelope used by normal REST requests.
Is the Service Status & Incident API a Service Status & Incident scraper?▾
It is the managed alternative to a DIY Service Status & Incident scraper. Instead of building and maintaining your own scraper — proxies, headless browsers, captcha and constant breakage — you call one ReefAPI endpoint and get the same service status & incident back as clean JSON.
Why does my Service Status & Incident scraper keep getting blocked?▾
Most Service Status & Incident scrapers break on anti-bot defenses, rate limits and IP bans that need rotating residential proxies and browser fingerprinting to clear. ReefAPI handles all of that for you — no proxies, no captchas, no maintenance — and returns live JSON. Blocked or failed calls are free.
18 Developer Tools APIs on the same key
One key, one credit pool, one response envelope. If you are pulling Service Status & Incident, you are one call away from the rest of the category — no second contract, no second integration.
Need something this API does not do?
Name the endpoint, the field, or a source we do not carry yet. We ship new APIs every week and you would be first to get the key. Real people read every message and reply the same day.
Try it on your own data before you pay anything
The call above is the real endpoint, not a recording. A free key gives you 1,000 credits, the other 183 APIs, and the same envelope everywhere.
Endpoints, parameters and credit costs on this page are read from the live catalog and cannot drift from what the API accepts. Field notes were captured on 2026-08-30.