Developers

No API key, no authentication, no SDK. Every endpoint answers plain HTTPS GET requests with JSON:

# Discover the API
curl https://www.pungrumpy.com/api/v1

# Fetch every blog post
curl https://www.pungrumpy.com/api/v1/posts

# Fetch one post with full Markdown content
curl https://www.pungrumpy.com/api/v1/posts/{slug}

Errors are structured JSON too — every non-2xx response carries an error object with a stable code, a message, and a hint on where to look next.

• GET /api/v1API index — every endpoint, described
• GET /api/v1/siteProfile, contact, and site links
• GET /api/v1/postsAll blog posts, newest first
• GET /api/v1/posts/{slug}One post, with full Markdown content
• GET /api/v1/showcaseAll showcase projects
• GET /api/v1/achievementsCertifications and programs

The full contract — operation IDs, typed parameters, and response schemas compatible with LLM function calling — lives in the OpenAPI specification.

Prefer Markdown over scraping HTML. Requests to the homepage or any blog post with an Accept: text/markdown header return Markdown from the same URL, and appending .md to a post URL serves the raw file:

curl -H "Accept: text/markdown" https://www.pungrumpy.com/
curl https://www.pungrumpy.com/blog/{slug}.md

• /openapi.jsonOpenAPI 3.1 spec for the API
• /llms.txtComplete site context as Markdown
• /agents.mdAgent-ready profile and discovery map
• /sitemap.mdSemantic page map in Markdown
• /.well-known/api-catalogRFC 9727 machine-readable API catalog
• /.well-known/agent-skills/index.jsonAgent skills for consuming this site

The API is read-only and public, so there are no keys, tokens, or sandbox environments to manage — production is the sandbox. Responses are cached at the CDN and refresh when content is published. Please keep request rates reasonable; content usage preferences are declared via Content-Signal in robots.txt.

Every API response carries the RFC rate-limit headers — RateLimit and RateLimit-Policy, plus the legacy RateLimit-Limit, RateLimit-Remaining, and RateLimit-Reset — describing the fair-use envelope of 60 requests per minute per client. The headers are advisory (responses are CDN-cached, so they are not a live counter); a request that is actually throttled receives HTTP 429 with a Retry-After header naming the seconds to back off before retrying.

The API version is pinned in the URL path — /api/v1 is current, and additive changes (new fields, new endpoints) ship into it without notice. Breaking changes never do: they ship as a new /api/v{n} version alongside the old one.

When a version is slated for removal, its responses announce it with a Deprecation header (RFC 9745) and a Sunset header (RFC 8594) naming the removal date at least six months in advance, and the timeline is published on this page. v1 has no planned sunset.

Questions, integrations, or something broken? Get in touch or email hello@pungrumpy.com.