Where API Conversations Happen

Last reviewed on 4 May 2026.

A curated list of the standards bodies, working groups, mailing lists, conferences, and online spaces where serious discussion of web API design and practice happens. We don't run a community of our own — we point at the ones worth your time.

Standards bodies and working groups

Most of what's interesting about web APIs in 2026 traces back to a handful of standards bodies. If you want to follow how the protocols are evolving (or contribute), these are the rooms.

  • IETF — the Internet Engineering Task Force. Owns HTTP, TLS, OAuth, and most of the protocols web APIs sit on top of. RFCs are the primary output. Working groups meet in public; mailing lists are open.
  • HTTP Working Group — the IETF group that owns the HTTP specifications. Active discussions on mailing list, especially around HTTP/3, structured fields, and ongoing protocol evolution.
  • OAuth Working Group — the IETF group that owns OAuth 2.0, OAuth 2.1, and related drafts. Where you'd watch if you wanted to know what's coming for delegated authorization.
  • W3C — owns specs that affect browser-side API consumption: Fetch, WebSockets (jointly with IETF), CORS, Web Crypto.
  • GraphQL Foundation — the home of the GraphQL spec under the Linux Foundation. Working groups for the spec, federation, GraphQL-over-HTTP, and related topics.

Mailing lists worth subscribing to

  • ietf-http-wg — the HTTP working group's mailing list. Public archives. Where decisions about HTTP itself get debated.
  • OAuth WG list — same for OAuth.
  • OpenAPI Initiative — working groups around the OpenAPI specification. Where you'd contribute if you have opinions about API description formats.

For most readers, "subscribe and skim subjects" is the right intensity. Substantive technical decisions you depend on tend to surface in these threads months before they appear in vendor documentation.

Q&A and discussion

  • Stack Overflow tags — rest, graphql, oauth-2.0, api. Most "how do I" questions have already been answered. The voted-up answers are usually accurate; the edge cases live in comments.
  • Hacker News — broad rather than deep, but new API tools, post-mortems, and design articles surface here first. The comment threads on technical posts often have the actual experts weighing in.
  • Lobsters — narrower audience than HN, higher signal-to-noise on programming topics. Tag-based filtering helps.

Conferences and talks

  • APIDays — the largest API-focused conference series, held in multiple cities each year. Talks recorded; the archive is a useful catalog of what API teams are working on.
  • GraphQLConf — annual conference under the GraphQL Foundation. Best signal on where the GraphQL ecosystem is heading.
  • API Specifications Conference — focused on OpenAPI, AsyncAPI, JSON Schema, and related description formats.
  • QCon and Strange Loop — broader than APIs, but consistently feature deep talks on API and distributed-systems topics. Both have publicly available recordings of past sessions.

Reading lists

The texts that come up over and over in serious API discussions:

  • Roy Fielding's REST dissertation — the original. The "REST" you actually meet in practice is a small subset of what the dissertation describes; reading it is the only way to understand what the constraints were originally about.
  • RFC 9110 and 9111 — the modern HTTP semantics and HTTP caching specs. These superseded RFC 7230-7235. Worth reading once if you build APIs; worth keeping handy for reference.
  • RFC 7807 — Problem Details for HTTP APIs. The standard the field has converged on for error envelopes. Short and worth reading directly.
  • OAuth 2.0 Threat Model and Security Considerations (RFC 6819) — what can go wrong with OAuth and how to defend against it.
  • The OWASP API Security Top 10 — the recurring API security failure modes. Updated periodically; worth re-reading each time.

Why we don't run our own community

The honest answer: communities take dedicated work to keep alive, and the existing ones above are doing the job well. Adding another forum or chat would dilute attention rather than add value. We'd rather spend the effort on better content here and point readers at the rooms where real discussion already happens.

If you want to talk to us specifically — about a correction, a topic suggestion, or something the site got wrong — the contact page has the address.