Render APIrender.com ↗
Access Render's live platform status, incident history with component timelines, and product changelog entries via 3 structured JSON endpoints.
What is the Render API?
This API exposes 3 endpoints covering Render's platform health and release history. get_status returns the current operational state of every infrastructure component grouped by region, get_incidents delivers a paginated history of past incidents with per-update timelines, and get_changelog surfaces the 10 most recent product releases with full HTML descriptions and category tags — no authentication required.
No input parameters required.
curl -X GET 'https://api.parse.bot/scraper/919c1254-1c96-4fc3-b4ff-c927434317a3/get_status' \ -H 'X-API-Key: $PARSE_API_KEY'
Typed, relational, agent-ready
A generated client with real types, enums, and the links between objects — the structure a flat JSON response can't carry. Autocompletes in your editor and reads cleanly to coding agents.
- Fully typed · autocompletes
- Objects link to objects
- Typed errors & pagination
Typed Python client. Set up the SDK in your uv project, then pull this API’s typed client:
uv add parse-sdk uv run parse init uv run parse add --marketplace render-com-api
uv run parse add --marketplace pulls a pinned snapshot of this canonical API — it won’t change underneath you. To customize it, subscribe and swap to your own copy.
"""Walkthrough: Render platform status SDK — bounded, re-runnable."""
from parse_apis.render_com_api import Render, InvalidPage
client = Render()
# Check overall platform health and list component statuses.
status = client.status.get()
print(f"Platform: {status.status_description} ({status.status_indicator})")
print(f"Page last updated: {status.page.updated_at}")
for comp in status.components[:5]:
print(f" {comp.name}: {comp.status}")
# Browse recent incidents with their update timelines.
try:
for incident in client.incidents.list(limit=3):
print(f"\n[{incident.impact}] {incident.name} — {incident.status}")
print(f" Created: {incident.created_at}, Resolved: {incident.resolved_at}")
for update in incident.updates[:2]:
print(f" {update.status}: {update.body[:80]}")
except InvalidPage as e:
print(f"Invalid page requested: {e.message}")
# List recent changelog entries for product updates.
for entry in client.changelog_entries.list(limit=5):
print(f"{entry.category}: {entry.title} ({entry.published_at})")
print("\nexercised: status.get / incidents.list / changelog_entries.list")
Returns the current operational status of Render's platform, including the overall status indicator and the status of each infrastructure component (grouped by region). One API call, no pagination.
No input parameters required.
{
"type": "object",
"fields": {
"page": "Object with page name, url, and updated_at timestamp",
"components": "Array of component objects with id, name, status, description, group_id, group flag, and updated_at",
"status_indicator": "Overall health indicator (none, minor, major, critical)",
"status_description": "Human-readable status summary (e.g. 'All Systems Operational')"
},
"sample": {
"data": {
"page": {
"url": "https://status.render.com",
"name": "Render",
"updated_at": "2026-08-22T20:44:25.857Z"
},
"components": [
{
"id": "j45c7rjc3n51",
"name": "Render Dashboard",
"group": false,
"status": "operational",
"group_id": null,
"updated_at": "2026-07-27T20:18:38.326Z",
"description": "dashboard.render.com"
}
],
"status_indicator": "none",
"status_description": "All Systems Operational"
},
"status": "success"
}
}About the Render API
Platform Status
The get_status endpoint returns a snapshot of Render's infrastructure health with no inputs required. The response includes a status_indicator field (none, minor, major, or critical) and a status_description string such as All Systems Operational. The components array breaks down status at the individual service level, with each entry carrying id, name, status, group_id, a group boolean, and an updated_at timestamp. This lets you distinguish top-level component groups from their child services.
Incident History
get_incidents returns up to 50 incidents per page. Pass an integer page parameter to walk through older incidents. Each incident object includes id, name, status, impact, shortlink, creation and resolution timestamps, and an updates array. The updates array is where you find the incident's timeline: each entry records what changed, when it changed, and which components were affected and what state transitions they went through. This is useful for reconstructing the full arc of any outage.
Product Changelog
get_changelog fetches Render's product changelog in a single call with no pagination. The response includes a total count and an entries array. Each entry exposes title, url, published_at, an HTML description with the full release notes body, and a category tag identifying whether the entry is a feature, improvement, or fix. The feed typically carries the 10 most recent entries, so it reflects recent release activity rather than full historical coverage.
The Render API is a managed, monitored endpoint for render.com — not a raw scraper you maintain. Every endpoint is automatically health-checked on a schedule, and when render.com changes and a check fails, the API is automatically queued for repair and re-verified. It is built to keep working as the site underneath it changes.
This isn't an official render.com API — it's an independent, maintained REST wrapper over public data. Where the source has no official API (or only a limited one), Parse gives you a stable contract over a source that never promised one, and keeps it current. Need a new endpoint or field? You can revise it yourself in plain English and the agent rebuilds it against the live site in minutes — contributing the change back to the shared API is free.
Will this API break when the source site changes?+
Is this an official API from the source site?+
Can I fix or extend this API myself if I need a new endpoint or field?+
What happens if I call an endpoint that has an issue?+
- Display a live Render health badge in an internal dashboard using
status_indicatorfromget_status - Alert on-call engineers when any component's
statusfield inget_statuschanges from its last-known value - Build a deployment gate that blocks releases when
status_indicatorismajororcritical - Aggregate incident
impactand resolution times fromget_incidentsto calculate Render's historical uptime - Surface the incident
updatestimeline in a postmortem tool to reconstruct the sequence of component state changes - Feed
get_changelogentries into a Slack channel or RSS-to-webhook pipeline to track new Render features and fixes - Correlate
get_changelogpublished_atdates with incident data to identify whether new releases preceded outages
| Tier | Price | Credits/month | Rate limit |
|---|---|---|---|
| Free | $0/mo | 200 | 5 req/min |
| Hobby | $30/mo | 1,000 | 20 req/min |
| Developer | $100/mo | 5,000 | 100 req/min |
| Team | $300/mo | 20,000 | 300 req/min |
| Company | $1,000/mo | 100,000 | 500 req/min |
Each endpoint has a fixed posted price per successful call — most fall between 1 and 10 credits — shown on this API's page before you run it. Exceeding the rate limit returns a 429 response. Authenticate with the X-API-Key header.
Does Render have an official developer API for platform status?+
What does `get_incidents` return, and how do I retrieve older incidents?+
id, name, status, impact, a shortlink, timestamps, and an updates array that logs each status change with the affected components. Pass the integer page parameter to retrieve older pages; each page holds up to 50 incidents.How far back does the changelog history go?+
get_changelog endpoint returns only the 10 most recent entries from Render's RSS feed. It does not cover the full historical archive of releases. You can fork this API on Parse and revise it to add pagination or archiving logic if deeper history is required.Can I get metrics like uptime percentages or response time data from these endpoints?+
Do the component entries in `get_status` identify which Render region they belong to?+
group_id and a group boolean flag. Top-level entries with group: true represent regional or functional groupings, and child components reference them via group_id. The name field on each component typically includes the region or service label.