API Versioning as a Translation Layer
API versioning as an architecture: requests enter through a version header, pass through a chain of reversible version changes, and reach controllers that only ever see the latest model.
Loading…
Topic
REST APIs
80 posts about REST APIs. Every summary links to the original.
- 80 posts
- 18 companies
- 1 explainer
See the idea
REST APIs explainers
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
Posts
Growing A Platform: Introducing API Versioning In Intercom
Intercom introduced API versioning for their REST and Messenger Framework APIs, using their open-source Requisite library, enabling safe, frequent updates without breaking existing integrations. Previously, API changes required advance notice and coordinated migrations, which was unreliable and hindered iteration, so they conducted user research to identify friction points. The versioning system uses ‘version changes’ — single transformations that roll back a model change to a previous version, such as renaming user_id to customer_id, allowing controllers to always operate on the latest version and chain multiple changes. Developers can test isolated requests using a specific header and upgrade through the Developer Hub, with the ability to roll back immediately if something goes wrong. This design, inspired by Stripe’s approach, allows Intercom to ship changes more frequently and safely across REST API, Messenger Framework, and webhooks.
Read Restrictions and Catalog Labels: Unifying governance across engines and catalogs
The Apache Iceberg community has adopted two additions to the Iceberg REST Catalog — read restrictions and catalog labels — each addressing distinct governance challenges. Read restrictions standardize delegated enforcement: a catalog evaluates policy for a principal and returns column-projection actions and row-filter expressions from a bounded vocabulary for a trusted engine to enforce. Catalog labels enable portable governance by allowing catalogs to exchange opaque key-value metadata at table and column level, so a consuming catalog applies native policies without per-user calls to the source. Read restrictions suit engine-to-catalog access where the source catalog trusts the engine and policies fit the standard vocabulary, whereas catalog labels fit federation between heterogeneous catalogs needing scalable governance and independent audit trails. These building blocks, along with centralized enforcement via cross-engine ABAC, advance the vision of unified governance across the open lakehouse.
How to Connect Your Twilio Agent to External APIs
This tutorial shows how to connect a Twilio voice agent to an external REST API so it can retrieve live information during a conversation. It uses C# .NET 9, Twilio Conversation Relay, WebSockets, OpenAI tool calling, and the authentication-free Cat Facts API as a demonstration. An ASP.NET Core application exposes a /voice webhook, connects calls to a /ws endpoint, maintains conversation messages, streams model responses, and executes get_cat_fact by requesting and parsing JSON from the Cat Facts service. The guide also covers environment variables, NuGet dependencies, ngrok tunneling, Twilio number configuration, and troubleshooting for webhook URLs and API keys. After setup, callers can ask for a cat fact and receive one from the external service, illustrating how function tools can give voice agents real-time data and perform API-backed work.
How to Connect Your Twilio Agent to External APIs in Node.js
Voice agents can converse, but they need external APIs to retrieve live information or take actions such as checking inventory or booking appointments. This tutorial builds a Node.js voice agent with Twilio Conversation Relay, Express, WebSockets, and the OpenAI Node.js SDK. A Conversation Relay WebSocket handler collects voice prompts, maintains conversation messages, streams model output back to the call, and defines a get_cat_fact tool that fetches JSON from the unauthenticated Cat Facts REST API. The service returns the fetched fact or an error message, while TwiML connects Twilio's voice-capable number to the WebSocket endpoint. Testing uses Node.js 18+, an OpenAI API key, ngrok, and a POST /voice webhook; the stated result is that callers can ask for a cat fact and hear the API response.
How to Confirm Phone Number Ownership with Lookup Identity Match in PHP
The post presents a PHP signup flow that uses Twilio Lookup Identity Match to confirm whether submitted identity details correspond to a phone number and to reduce signup fraud. Identity Match performs a zero-knowledge match against authoritative sources such as mobile carrier records, using supplied fields including names, addresses, national IDs, or dates of birth. The implementation builds on a Slim PHP project, adds Twig form handling and the Twilio REST client, then sends the phone number, first name, and last name through the Lookup API. Registration succeeds only when the number is valid and both names return exact_match or high_partial_match; otherwise, the form displays an instruction to provide information for a phone number the user owns.
Supercharge Auth with Signals and the New Okta Angular SDK
The updated Okta Angular SDK introduces fully standalone architecture, eliminating NgModules and wrapper functions in favor of standalone providers and functional guards. In an Angular v22 sample project, authentication is configured with the provideOktaAuth function without requiring a custom backend. Route security utilizes functional guards, while user and group data fetch flows are handled using rxResource alongside signal inputs. To support dynamic environments without requiring rebuilds or redeployments, the setup implements runtime configuration loading via provideAppInitializer and OktaAuthConfigService. Security is further bolstered by binding access tokens to browser key pairs using Demonstrating Proof of Possession alongside OAuth 2.1 and OpenID Connect protocols.
Wire It, Run It, Deploy It: AI Workflows in Gradio
AI applications are presented as pipelines that chain image, text, audio, and dataset operations, with intermediate values otherwise investigated through print-debugging. gr.Workflow turns these pipelines into graphs of typed nodes, served as a drag-and-drop canvas where each node runs independently and its result remains visible. Operators can be Python functions, Hugging Face Inference Providers models, Gradio Spaces, Hub dataset rows, or GPU-backed functions using ZeroGPU, while fan-out connections run multiple analyses or generations in parallel. The same workflow also exposes labeled outputs as REST endpoints callable through the Gradio client or curl, and can be deployed to Hugging Face Spaces with one command.
Add Cross App Access to Your OIDC Resource Application
Cross App Access allows applications such as AI agents to access resource APIs on behalf of OpenID Connect federated users. The specification relies on an Identity Assertion Authorization Grant, which is a short-lived JSON Web Token issued by the customer Identity Provider. Resource authorization servers validate this token, resolve user identities using combined issuer and subject claims, and issue locally scoped access tokens without altering single sign-on flows. Implementations must bind issuers to registered connections before verifying signatures to prevent forgery attacks. In addition, servers should not issue refresh tokens, as clients instead resubmit the grant upon access token expiration.
Add Cross App Access to Your OIDC Requesting Application
OpenID Connect federated applications connecting to third-party services can implement Cross App Access using the Identity Assertion Authorization Grant specification. When a user authenticates via the standard authorization code flow, the requesting application retains the issued refresh token. The application exchanges this refresh token at Okta's token endpoint via RFC 8693 token exchange to receive a short-lived Identity Assertion Authorization Grant JSON Web Token. Next, the application presents this assertion to the third-party resource authorization server using the RFC 7523 JWT bearer grant to obtain a final access token. Developers can configure an AI Agent and application integrations in Okta to validate the entire end-to-end request flow against test endpoints on xaa.dev.
Enterprise-Managed Authorization for your MCP server: Setting Up and Testing XAA in Auth0
Connecting AI agents to enterprise APIs and MCP servers creates governance challenges when relying on traditional OAuth consent prompts. Cross App Access shifts authorization decisions to the enterprise identity provider, allowing IT administrators to manage agent permissions centrally. In this architecture, an identity provider like Okta authenticates the user and issues an Identity Assertion JWT Authorization Grant based on administrative policy. The requesting AI agent presents this assertion to Auth0, which validates the signature and exchanges it for a standard access token via a JWT-bearer grant. Protected APIs can then validate the final token normally without requiring code changes or direct user consent interactions.
Device Authorization Flow for a Rust CLI and an Axum API
Command-line tools lack browser redirect capabilities, preventing standard OAuth login flows. To resolve this limitation, the OAuth 2.0 Device Authorization Flow issues a temporary device code, presents a verification URL to the user, and waits for authentication in an external browser. A Rust workspace demonstrates this end-to-end pattern across a CLI, an Axum web API, and a shared authentication library. The shared library relies on jsonwebtoken and reqwest to fetch JSON Web Key Sets and validate token signatures, issuers, and audiences against typed claims. Axum secures protected routes through custom FromRequestParts extractors that decode Bearer headers, enabling verified CLI access.
Unifying Workers AI and AI Gateway into a single AI control plane
Workers AI and AI Gateway are converging into a unified AI control plane to simplify model access, billing, and observability. Developers can now access both services through a single entrypoint using unified Workers bindings and the /ai/ REST endpoint. Specifying a default gateway automatically instruments requests with payload logging, token tracking, and cost attribution without manual dashboard setup. Cloudflare has also rolled out unified prepaid billing, allowing teams to spend AI Gateway credits on Workers AI models while unlocking higher rate limits. Planned future features include model-first routing for automated provider failover and smart routing powered by task classifiers on Workers AI.
The next generation of MCP
Model Context Protocol previously required stateful connections between clients and remote servers, creating operational complexity around sticky sessions, message replay, and open streams. The newly released MCP 2026-07-28 specification transitions MCP to a fully stateless protocol alongside updated SDKs across TypeScript, Python, Go, and C#. The protocol eliminates mandatory handshakes and session identifiers from core request paths while enabling servers to run on request-scoped infrastructure like Cloudflare Workers. Interactive elicitation is restructured through Multi Round-Trip Requests, which allow servers to return input requirements without sustaining persistent connections. Standardized headers for method names and improved OAuth authorization mechanisms further enable standard web infrastructure to inspect and manage MCP traffic efficiently.
Your trusted knowledge layer: Introducing Stack Internal's new platform experience
Organizations face growing challenges managing fragmented institutional data as AI agents and human workers operate across disparate tools. When agents consume stale or conflicting information, they produce confident errors that require costly human verification. Stack Internal has introduced an AI-native knowledge platform that ingests raw data across sources—including Google Docs, Slack, and Stack Internal communities—and evaluates it for trust, freshness, and authority. The updated platform adds a chat interface featuring response-level confidence labels and provenance cards, along with API and MCP server integrations that enforce identity-aware permission boundaries for AI agents. Engineering leaders can also track internal knowledge usage and high-traffic dependencies across versions via new Swagger API v3 endpoints.
Build a Flask App with Okta for Secure OIDC Login and Authorized API Calls
Flask web applications require dedicated mechanisms to authenticate users securely and authorize access to downstream services. Developers can address this by integrating Okta as an OpenID Connect identity provider using the Authlib library. Authlib registers Okta as a remote provider and automates the Authorization Code flow using Proof Key for Code Exchange with SHA-256 code challenge verification. After logging in through Okta and completing the callback route, the Flask web application uses the acquired OAuth 2.0 access token to query a protected backend resource server. This architecture ensures that user credentials remain managed by Okta while client requests to backend API endpoints carry valid, scoped authorization tokens.
Enable Your SAML Requesting App for Cross App Access
Cross App Access allows enterprise applications federated with Security Assertion Markup Language to interact with third-party resource APIs without migrating to OpenID Connect. The flow adapts the Identity Assertion Authorization Grant specification to SAML by adding three token exchange steps following the standard single sign-on handshake. First, the application exchanges the validated SAML assertion for an OAuth refresh token using Okta's token endpoint and a private key JSON Web Token. The application then uses the refresh token to request a short-lived Identity Assertion Authorization Grant token from Okta. Finally, the application presents the Identity Assertion Authorization Grant token to the third-party authorization server to obtain an OAuth access token.
Your AI shipped a backend that boots. That is the whole problem.
Backend security vulnerabilities often emerge from permissive default settings in web frameworks, a risk amplified when AI agents generate code focused solely on passing tests. Common failure points include unmetered request body parsing, unvalidated schemas, prototype pollution, and wildcard cross-origin resource sharing policies. To eliminate these foot-guns, the TypeScript framework DaloyJS enforces secure-by-default behavior across its entire routing and middleware model. It provides built-in request timeouts, streamed body size caps, prototype-stripping JSON revivers, and unified Zod schemas that simultaneously validate payloads and generate OpenAPI contracts. While secure defaults lower the risk of common infrastructure exploits, developers still remain responsible for application-level authorization and business logic correctness.
Agentic Resource Discovery: Let agents search
Agentic Resource Discovery (ARD) is a draft, open specification for discovering agent capabilities at runtime, addressing a model in which users and developers must pre-install, integrate, and maintain each MCP tool, skill, or A2A agent. It defines a static ai-catalog.json manifest and a dynamic POST /search registry API, using indexed signals such as publisher identity, representative queries, compliance attestations, and tags to move capability selection outside the LLM. Hugging Face's Discover Tool adapts Hub semantic search into ARD catalog entries for running Spaces, exposing skills, MCP servers, or raw Space metadata according to the requested media type and wrapping agents.md files into installable SKILL.md artifacts. The tool is available through the hf CLI, REST, and MCP, while planned work includes federation modes and Hub support for profile-level manifests.
You can't whisper at an AI agent
Stripe engineers ran roughly a dozen experiments to determine how to get AI agents to use current API versions, follow integration best practices, and load the Stripe skill. Passive hints, including SDK files, AGENTS.md guidance, and API warning responses, were largely ignored, while active prompts and distribution mechanisms performed better. A modular, progressively disclosed skill structure outperformed a monolithic file by roughly 10% and reduced token usage; a CLI login prompt led 30–35% of viewers to copy its install command, and explicit compatibility-mode errors prompted agents to correct version mismatches. The results suggest that agent-facing developer experience is primarily a distribution problem, with hard steering through errors and loaded instructions more reliable than soft hints agents may never encounter.
From SSH to REST: A Security-Driven Modernization of Slack’s EMR Data Pipelines
Slack's data platform accumulated over 700 SSH-based Airflow operators executing jobs directly on AWS Elastic MapReduce clusters, creating broad security surfaces and operational instability. Stateful SSH connections frequently failed when Kubernetes pods restarted, leaving orphaned zombie processes and preventing infrastructure modernization such as migrating EMR clusters to child accounts. To eliminate SSH access, Slack adopted a REST-based architecture using Quarry, a gateway providing unified REST APIs and token authentication across compute engines. For non-Hadoop CLI workloads, Slack leveraged YARN Distributed Shell to execute arbitrary shell scripts stored in Amazon S3 within managed, isolated YARN containers. The phased migration achieved zero downtime across eight data regions, unlocking reliable monitoring, simplified onboarding, and future initiatives like Spark on Kubernetes.
Related topics
All topics →Weekly digest
The best engineering reads, once a week.