Postman APIpostman.com ↗
Access structured Postman app release notes from v6 to v12+. Query by version or major release line, get full Markdown notes and per-section breakdowns.
What is the Postman API?
The Postman Release Notes API exposes structured data from Postman's official app release history across two endpoints, covering versions from v6 through the current v12 line. The list_releases endpoint returns paginated release records — including version strings, publication dates, and headed sections — while get_release fetches the complete Markdown note and section breakdown for a single version in one call.
curl -X GET 'https://api.parse.bot/scraper/01db1eb3-9d07-4cce-9502-2796b9e3b777/list_releases?major_version=12' \ -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 postman-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: Postman App Release Notes — browse versions, drill into details."""
from parse_apis.postman_com_api import Postman, ReleaseNotFound
client = Postman()
# Browse the five most recent releases across all major versions.
for release in client.releases.list(limit=5):
print(release.version, release.release_date, len(release.sections), "sections")
# Grab the newest v12 release and inspect its section headings.
latest_v12 = client.releases.list(major_version="12", limit=1).first()
if latest_v12 is not None:
print(latest_v12.version, latest_v12.notes_markdown[:120])
for section in latest_v12.sections:
print(" -", section.heading)
# Point-lookup using the version discovered above.
detail = client.releases.get(version=latest_v12.version)
print(detail.version, detail.created_at, detail.major_version)
# Typed error handling for a version that doesn't exist.
try:
client.releases.get(version="99.0.0")
except ReleaseNotFound as exc:
print("not found:", exc.message)
print("exercised: releases.list / releases.get / ReleaseNotFound")
Lists Postman app releases, newest first, optionally restricted to one major version line. Each row is one release: its version string, major version number, publication date (release_date, ISO YYYY-MM-DD, parsed from the note header and null for older notes that carry no date line), the created_at timestamp from Postman's feed, the note split into headed sections (What's New, Improvements, Bug Fixes, etc.; empty for notes without headings), and the full note in Markdown. One round trip fetches the whole history; page and page_size slice it locally (page defaults to 1, page_size defaults to 50 and is capped at 100). total is the number of releases matching the filter, has_more says whether a later page exists. A major_version with no releases yields an empty page with total 0.
| Param | Type | Description |
|---|---|---|
| page | integer | 1-based page number over the filtered release list. |
| page_size | integer | Releases per page; values above 100 are clamped to 100. |
| major_version | string | Major version line to filter on, as a whole number string (e.g. 12). Omitted = all versions. Lines observed in the feed: 6, 7, 9, 10, 11, 12. |
{
"type": "object",
"fields": {
"page": "page number returned",
"total": "number of releases matching the major_version filter",
"has_more": "true when a later page exists",
"releases": "array of release records, newest first",
"page_size": "effective page size after clamping",
"major_version": "the applied major version filter as an integer, or null when unfiltered",
"releases[].version": "dotted release version string; pass unchanged to get_release",
"releases[].sections": "array of {heading, body_markdown} for each headed section of the note",
"releases[].created_at": "ISO-8601 UTC timestamp the note was created in Postman's feed",
"releases[].release_date": "ISO YYYY-MM-DD publication date from the note header, or null when the note has no date line",
"releases[].major_version": "integer major version line",
"releases[].notes_markdown": "full release note in Markdown"
},
"sample": {
"data": {
"page": 1,
"total": 395,
"has_more": true,
"releases": [
{
"version": "12.27.5",
"sections": [
{
"heading": "Bug Fixes",
"body_markdown": "Some critical bug fixes and enhancements were added in this release."
}
],
"created_at": "2026-09-10T07:57:44.000Z",
"release_date": "2026-09-10",
"major_version": 12,
"notes_markdown": "## Postman 12.27.5\nSeptember 10, 2026\n\n### Bug Fixes\nSome critical bug fixes and enhancements were added in this release."
}
],
"page_size": 3,
"major_version": null
},
"status": "success"
}
}About the Postman API
What the API covers
The API surfaces every Postman desktop and web app release note published on the official Postman release notes page, from legacy v6 entries through the current v12 line. Each release record includes a dotted version string (e.g. 12.27.1), an integer major_version, a release_date (ISO YYYY-MM-DD, derived from the note header — null for older entries that carry no date), and a created_at ISO-8601 UTC timestamp for when the note appeared in Postman's feed.
Endpoints and parameters
list_releases returns a paginated array of release records, newest first. Use the major_version parameter (a whole-number string like "12") to restrict results to one release line. page and page_size control pagination; page_size values above 100 are clamped to 100. The response includes total (count of matching releases), has_more (boolean for additional pages), and a releases array. Each element carries version, release_date, created_at, and a sections array of {heading, body_markdown} objects representing the headed sections within that note.
get_release takes a single required version string — exactly as returned by list_releases — and returns the full record: version, major_version, release_date, created_at, sections, and notes_markdown (the complete release note in Markdown). A valid version string that does not exist in Postman's release feed will return a not-found response rather than empty data.
Data shape and coverage notes
The sections array lets you isolate specific parts of a release note — for example, bug-fix sections versus feature announcements — without parsing the full Markdown yourself. release_date is null for older notes that did not include a date line in their header, so consumers should handle that nullable field explicitly. Version strings should be passed to get_release unchanged from list_releases output to avoid lookup failures.
The Postman API is a managed, monitored endpoint for postman.com — not a raw scraper you maintain. Every endpoint is automatically health-checked on a schedule, and when postman.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 postman.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?+
- Track when a specific Postman feature or fix shipped by searching
notes_markdownacross versions - Build a changelog digest that groups releases by
major_versionusing the filter parameter - Diff consecutive release notes by fetching adjacent records from
list_releasesand comparingsections - Alert engineering teams when a new Postman version is published by polling
list_releasespage 1 and comparingcreated_at - Extract only bug-fix sections from release notes using the
headingfield in eachsectionsentry - Audit which Postman major version line your team is running against and check release cadence by
release_date
| 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 Postman have an official developer API for its release notes?+
What does `get_release` return that `list_releases` does not?+
get_release returns the notes_markdown field — the complete release note as a Markdown string — which is not included in the list_releases array. Both endpoints return version, major_version, release_date, created_at, and the sections array.Why is `release_date` null for some releases?+
release_date field is explicitly null. The created_at field (the UTC timestamp when the note appeared in the feed) is populated for all records and can serve as a fallback ordering signal.Does the API cover pre-v6 release notes or Postman CLI/Newman changelogs?+
Can I retrieve release notes for a specific date range rather than by version?+
list_releases supports filtering by major_version and pagination, so you can fetch pages and filter client-side on release_date. You can fork this API on Parse and revise it to add server-side date filtering.