标签：#API

Runable says 60%–70% of its 1 trillion-plus token usage in the last 90 days came from paying customers.

If you're building or evaluating an AI agent that can shop and check out on its own, you've probably run into the new "agentic commerce" protocols: ACP (OpenAI + Stripe + Meta), AP2 (Google), and UCP. They define how an agent talks to a merchant to create a checkout session, apply a payment token, and get an order back. Stripe's own test mode covers the payment half fine — test cards, test API keys. But there's no hosted "fake merchant" you can point your agent at to verify the protocol half: does your agent correctly create a session, handle a 422 idempotency conflict, parse the order response, retry politely? You either mock it yourself from the spec, or risk finding out against a real merchant. So I built acp-sandbox — a small hosted mock merchant implementing the ACP checkout API, live at https://acp-sandbox.flo-voice1.com . What it does It implements the real checkout_sessions lifecycle from ACP's 2026-04-17 spec : create, retrieve, update, complete, cancel. Responses match the actual CheckoutSession / Order / Error schemas for the fields it supports — I pulled the OpenAPI spec directly rather than guessing field names. # get a test key, no signup curl -X POST https://acp-sandbox.flo-voice1.com/keys \ -H "Content-Type: application/json" -d '{"email":"you@example.com"}' # create a session against the demo catalog curl -X POST https://acp-sandbox.flo-voice1.com/checkout_sessions \ -H "Authorization: Bearer acps_test_..." \ -H "Content-Type: application/json" \ -d '{"line_items":[{"id":"item_demo_headphones","quantity":1}],"currency":"usd"}' Every request/response is logged per API key ( GET /logs ), so you can see exactly what your agent sent when something doesn't work. What it deliberately doesn't do (yet) No real payment processing — complete always succeeds once you send any payment_data . No OAuth delegate_authentication flow. No fulfillment options (shipping/pickup) — every session goes straight to ready_for_payment . Fixed demo catalog (4 items), not a rea

TL;DR An agentic RAG pipeline treats retrieval as a tool the AI agent can call, evaluate, and call again rather than as a fixed step. The pipeline can search an internal knowledge base first, then use real-time web search when the available evidence is missing, weak, or outdated. Internal documents and web results should be converted into a shared evidence format before the model generates an answer. A reliable system must preserve URLs, publication dates, document identifiers, and the claims supported by each source. Retrieval quality, web-search precision, citation correctness, latency, cost, and stopping behaviour should all be evaluated. A basic RAG pipeline works well until the answer is not in the knowledge base. Imagine an enterprise copilot that can answer questions about internal product documentation. It performs semantic search against a vector database, retrieves several relevant passages, and passes them to a language model. For questions covered by the indexed documents, the system may work remarkably well. Then a user asks about a release announced yesterday, a recently changed regulation, or how the company’s product compares with a new competitor. The vector database cannot retrieve information it has never indexed. A conventional pipeline may return no answer, but it may also produce a confident response from incomplete or outdated context. Adding a Web Search API helps solve the freshness problem, but it introduces another decision: when should the system trust its internal knowledge, and when should it search the open web? An agentic RAG pipeline places that decision inside the retrieval workflow. What Makes a RAG Pipeline Agentic? A traditional RAG pipeline usually follows a fixed path: transform the question into a search query, retrieve the most similar passages, add those passages to the prompt, and generate an answer. An agentic RAG pipeline allows the model to make decisions between those stages. Retrieval becomes a tool rather than a manda

Agents don't search like humans. They issue hundreds of queries per session, need structured extraction over snippet relevance, and care more about p95 latency than the perfect top result. Keenable built a search API around those constraints with a 100B+ page proprietary index, SQL-like query interface, and continuous benchmarking against agent-like workloads. The founders (Amazon AGI web grounding, Yandex search lead) are betting that wrapping existing search APIs won't cut it when agents become the primary consumers of web data. The architecture reveals what changes when you optimize for machine callers instead of human eyeballs. Why Agent Search Needs Different Plumbing Human search optimizes for the first three results and tolerates 500ms variance. Agent search runs in tight loops where every query blocks downstream tool calls. The contract shifts: Query volume : Agents issue 10-100x more queries per task than humans per session Latency budget : p95 matters because agents serialize tool calls; tail latency compounds across multi-step workflows Result consumption : Agents parse structured data, not blue links; relevance scoring for human click-through doesn't align with extraction success Query patterns : Agents use precise filters (date ranges, domain constraints, schema hints) that humans rarely specify Traditional search APIs built for human traffic handle agent workloads poorly. Rate limits assume sporadic queries. Pricing tiers penalize high-volume programmatic access. Relevance models optimize for engagement metrics that don't exist in agent contexts. The 100B-Page Index Decision Keenable maintains its own crawl and index instead of wrapping Google, Bing, or Brave. This is expensive but unlocks control over: Crawl strategy : Agents need fresh data on niche domains that human-centric crawlers deprioritize. A proprietary crawl can target high-churn sources (job boards, pricing pages, event listings) and re-crawl on agent-driven schedules rather than PageRank-

Nim doesn't have a lot of options for building HTTP APIs with the kind of batteries-included developer experience you get in frameworks like FastAPI or Express with Swagger middleware. mummy is a fast, solid HTTP/WebSocket server library for Nim (my fork with the additions below is at github.com/isaiahpeter/mummy ) — but out of the box, it doesn't generate OpenAPI specs, validate request bodies, or give you typed path parameters. So I forked it and added those. This post walks through what I built, why, and what I learned extending an existing Nim library instead of starting from scratch. Why mummy, and why OpenAPI I wanted a Nim backend for a few projects (a contact-form API, a todo API demo) and kept missing three things I'd take for granted in other ecosystems: Auto-generated API docs — a /docs endpoint you can actually hand to someone, generated from your routes instead of hand-written. Typed path parameters — pulling id out of /users/{id} as an int without manual parsing and error handling in every handler. Request validation — rejecting a bad JSON body before it reaches your handler logic, with a schema to back it up. mummy is fast and minimal by design, which is exactly why it was worth extending rather than replacing. What I added OpenAPI spec generation. I added openapi_schema.nim and openapi_router.nim , which let you wrap routes in an OpenApiRouter and attach a summary, tags, and a response schema via schemaOf . The router serves both /openapi.json and a browsable /docs page generated from your actual route definitions — so the docs can't drift out of sync with the code the way hand-written API docs do. Typed path parameters. pathParam[T](request, "id") pulls a path segment and parses it as the type you ask for, with a clean 400 response if parsing fails. One gotcha worth flagging if you try this yourself: in this Nim version, the generic dot-call form ( request.pathParam[int]("id") ) doesn't parse — you have to call it as pathParam[int](request, "id") in

X has sent cease-and-desist letters to Nitter, the open source project behind privacy-friendly X frontends, demanding its instances and code repository be taken down over alleged scraping.

Syntax highlighting for code blocks without the complicated markup, spans, classes, and bloated JavaScript, courtesy of Uncle Dave. MicroLighter: Syntax Highlighter originally handwritten and published with love on CSS-Tricks . You should really get the newsletter as well.

API documentation has a reliability problem. The code gets updated; the OpenAPI spec gets forgotten. The spec gets updated; the TypeScript client doesn't regenerate. By the time an enterprise client asks for your API contract, the document you hand them describes a system that no longer exists. Baklava, an open-source library by Iterators , solves this structurally: documentation is generated from the tests that verify your actual API behaviour, so it cannot drift. The problem Documentation drift is the default state of any API that lives long enough. The causes are well-understood: docs and code are maintained separately, documentation updates require extra discipline at every PR, and no automated check catches a route signature change that wasn't reflected in the OpenAPI file. The consequence is real. Clients building against a stale spec hit integration errors in production. Internal teams onboarding to a service spend hours reconciling the documented contract with actual behaviour. TypeScript front-ends break when an API response field changes without a corresponding client update. The problem compounds as the API grows. The solution Baklava integrates into your existing test suite. When routing tests run, baklava observes each request and response, infers the API surface, and generates documentation as a test output, not as a separate build step, not as a manually-maintained file. In baklava, the test is the documentation spec. Instead of a standard assertion block, each route is defined with path() , supports() , and onRequest() scenarios that both verify the API behaviour and describe it for documentation output: ​`// The test IS the documentation spec class UserApiSpec extends AnyFunSpec with BaklavaPekkoHttp[Unit, Unit, ScalatestAsExecution] with BaklavaScalatest[Route, ToEntityMarshaller, FromEntityUnmarshaller] { path("/users/{userId}")( supports( GET, pathParameters = p Long , summary = "Get user by ID" )( onRequest(pathParameters = 1L) .respondsWith Use

If you need a free AI app builder with backend to get a FastAPI microservice running today, you can do it with a handful of platforms that bundle hosting, a database, and auth for zero cost. The catch is that the free tiers have hard limits, and they expose the same failure modes you’ll hit in production if you’re not careful. Below I walk through the exact steps, show the code that works, compare the popular builders, and explain how to transition to a production-grade stack when the free tier starts to choke. What free AI app builder platforms include backend services? The short answer is: Cursor , Bolt , and Lovable all ship with a “one-click deploy” that creates a container, wires up a PostgreSQL instance, and adds optional OAuth. They are marketed as “no-code AI app builders,” but you can drop in any Dockerfile – including one that runs FastAPI – and they’ll handle the rest. Platform Backend offering Free tier limits Auth support Cursor Managed container + Postgres 13 500 MB RAM, 1 CPU, 100 k requests/mo Google, GitHub, email Bolt Container + SQLite (upgrade to Postgres) 256 MB RAM, 0.5 CPU, 50 k requests/mo Magic link, JWT Lovable Container + MySQL 5.7 300 MB RAM, 1 CPU, 75 k requests/mo Email/password, OAuth All three let you push a Git repo and they rebuild automatically. That’s the “free AI app builder with backend” you’re after – you get a place to run your FastAPI code without paying for a VM. How do I build a FastAPI AI microservice and deploy it with a free builder? The first thing most builders break on is the cold-start latency of a Python container that pulls a large model at import time. I’ve been bitten by this on Cursor: the first request took 30 seconds, then timed out because the free tier caps request time at 15 seconds. The fix is to load the model lazily or move it to a separate worker. Below is a minimal FastAPI app that calls Claude via the anthropic SDK. The code fits in a 30-line file and works on any of the three platforms. # main.py fro

On 30 September 2025, Imgur blocked the entire United Kingdom. No warning. No migration tool. No grace period. One day it worked, the next it didn't — and with it went millions of embedded images across forums, Discord servers, tutorials, Reddit threads, and personal blogs. Grey boxes everywhere. I'd been thinking about building a proper image hosting tool for a while. That was the push I needed. What I actually built DBimg is a free media hosting and sharing service. The pitch is simple: upload a file, get a permanent direct link, share it anywhere. Here's what that looks like in practice: No account required — anonymous uploads work out of the box No compression — files are served at original quality, always Permanent hosting — no expiry dates, no "inactive account" deletion Automatic EXIF stripping — GPS and metadata removed on every upload Instant embed codes — HTML, BBCode, and Markdown generated automatically REST API — API key support for developers who need programmatic access Global CDN — fast delivery wherever the link gets shared 75MB free / 250MB Pro — covers most real-world use cases without friction Supported formats: JPEG, PNG, GIF, WebP, AVIF, HEIC, BMP, TIFF, MP4, WebM, MOV, AVI, MP3, FLAC, WAV, and more. Why I built it this way Imgur was originally built by a Redditor, for Redditors. It was frictionless by design — drop an image, copy a link, done. No account needed, no compression, no nonsense. Then it got acquired. Then acquired again. Then the NSFW purge happened in 2023. Then anonymous uploads disappeared. Then compression got heavier. Then ads got more aggressive. Then the UK ban. Each decision made sense from a business perspective. None of them made sense from a user perspective. What frustrates me about this pattern is that image hosting isn't technically hard. Serving a file from a CDN is a solved problem. The thing that's hard is committing to doing it simply and not gradually enshittifying it in pursuit of growth metrics. That's what I w

Originally published on hexisteme notes . I built a YouTube upload stage for a video pipeline, and the flow looked clean enough on paper: start a resumable session, PUT the file, get back a video ID, verify the upload actually landed the way it was supposed to, then write a local record marking the episode as uploaded. Four steps, each one depending on the last. It was the dependency between the last two that turned out to be the problem. The sequence, and where it breaks Verification here means re-querying the video through videos.list after the upload finishes, to confirm the visibility wasn't silently demoted, the upload wasn't rejected, and the metadata actually propagated. That's a reasonable thing to check — YouTube's upload API can report success at the transport layer while the platform-side processing does something you didn't ask for. But if that verification call raises, the exception propagates straight up, and the local record — a JSON file I'll call upload.json — never gets written. Not "gets written with an error flag." Never written, period. By the time that exception fires, though, the video already exists on YouTube. The PUT succeeded. The video ID is real. There's a public (or not-quite-public) video sitting on the channel, and there is exactly nothing on disk that knows about it. Run the same command again after that, and the guard that's supposed to answer "have I already uploaded this?" — a check for whether upload.json exists — sails right through, because it doesn't exist. The result isn't a retry. It's a second, completely independent upload of the same video. What "retries don't duplicate" actually meant The module's docstring said retries don't create duplicate videos. That line wasn't wrong, exactly — it was scoped narrower than it read. It was true for retries inside the low-level file-PUT function, which reuses the same resumable session URI on retry, so transport-layer hiccups during the upload itself are genuinely safe to retry. What

Disclosure: I'm the founder of Popgot , which I use as the example below. The problem and the approach apply regardless of what you build on. Every price comparison project I've seen starts the same way: scrape a bunch of retailers, store the prices, sort ascending. And then it produces garbage rankings, because price is not a comparable field. Here's the classic failure. Three listings for AA batteries: Listing Price Count Brand A $5.99 16 Brand B $6.99 20 Brand C $11.94 40 Sort by price and Brand A "wins" at $5.99. Sort by cost per battery and the order flips completely: Brand C is ~29.9c per cell, Brand A is ~37.4c. The cheapest listing is the worst deal on the page. Why this is hard The naive fix is "just divide price by quantity." The problem is that quantity almost never exists as a clean number. It's buried in the title, and the title is written by whoever uploaded the listing: AA Batteries 24 Pack AA Alkaline Batteries, 1.5 Volts, 24 Count 48-Pack (2 x 24) Double A So you end up writing a title parser. Then you discover the same product needs a different unit depending on the category: per fluid ounce for detergent, per serving for protein powder, per 100g for coffee, per sheet for paper towels. Then you discover that some categories need a spec filter before unit price is even meaningful. A fish oil at 20c per serving isn't cheaper than one at 34c per serving if the first one has half the EPA+DHA. You're comparing two different products. That last part is the piece people underestimate. Normalization is only valid within a set of products that actually satisfy the same requirement, which means something has to read the label, not just the title. What a normalized record looks like This is the problem I ended up building Popgot around, so rather than describe it abstractly, here's the shape of the data. The developer API returns listings with the unit math already done: GET /api/developer-api/products?query=aa+batteries&limit=10 { "products" : [ { "display_t

We open-sourced 449 real equipment financing quotes so nobody has to trust our math Commercial equipment financing sites are almost always a black box: you land on a page, see a monthly payment, and have no way to check how that number was actually derived. The APR is picked out of thin air, the "starting at" price is aspirational, and the amortization math is never shown. We built Equipment Capital Index to do the opposite — every page shows the real per-machine price, the actual amortization schedule, and now we've published the whole underlying dataset so anyone can verify or build on it. What's actually in the dataset equipment-financing-rate-data is a CC BY 4.0 dataset of aggregate financing benchmarks computed from 449 individually priced, real machines — construction equipment, ag machinery, trucking fleet, power equipment, and material handling gear. No survey estimates, no fabricated averages. Current live snapshot: Category Machines tracked Avg APR Avg est. monthly payment Heavy Construction 222 8.25% $3,272 Agriculture 84 7.75% $4,411 Trucking Fleet 63 8.00% $2,501 Power Equipment 44 8.50% $957 Material Handling 36 8.50% $825 Site-wide average: 8.17% APR , $2,954/mo across all 449 machines. Why this exists A couple of principles drove the design: Every number traces back to a real machine. Each of the 449 rows has a sourced price (dealer listing, MSRP, or a documented class-typical estimate — and it's disclosed which one) and a real amortization calculation, not a rounded guess. The math is reproducible, not just displayed. The same aggregation logic that powers the /press page on the site also generates this dataset — one source of truth computed twice, so the numbers can't silently drift apart. It shouldn't require scraping a webpage. The data has three independent, permanent homes: A live JSON API: /api/rate-report.json ( OpenAPI spec ) A self-updating GitHub repo (regenerates from live data every 3 days via GitHub Actions) A permanent, versioned DOI o

Node.js Express vs. Python FastAPI: The Definitive Guide for Choosing Your Next Backend Choosing a backend framework used to be simple. If you liked JavaScript, you built with Express. If you liked Python, you went with Flask or Django. But the landscape has fundamentally shifted. With the explosion of AI, machine learning, and strict type safety, Python FastAPI has emerged as a powerhouse alternative to the traditional JavaScript runtime. Meanwhile, Node.js Express remains the unopinionated king of the enterprise web. If you are starting a new project today, which one should you choose? Let’s break down the technical trade-offs, developer experience, and code structures of both frameworks. 🚀 The Core Philosophy Node.js Express: The Minimalist Canvas Express is a minimalist, unopinionated framework. It doesn't care how you structure your folders, how you validate data, or how you handle errors. It gives you a robust set of HTTP tools and steps out of your way. The Catch: You have to build or install your own solutions for data validation, ORM mapping, and API documentation. Python FastAPI: The Automated Powerhouse FastAPI is built on modern Python 3.8+ features like type hints and asynchronous ASGI (asyncio). It is highly opinionated about data handling, leveraging Pydantic to automate input validation and schema serialization. The Catch: It forces you into a specific way of handling data types from day one, which can feel restrictive if you prefer absolute freedom. 📊 Feature Breakdown Feature Node.js Express Python FastAPI Language JavaScript / TypeScript Python Data Validation Manual / Third-Party (Zod, Joi) Native via Pydantic API Docs Manual Setup (Swagger UI plugin) Automatic (Interactive Swagger UI & ReDoc) Best For Real-time I/O, WebSockets, Full-stack JS AI/ML APIs, Data pipelines, Type-safe apps 🛠️ Code Comparison: Creating a Validated POST Route Let’s look at how both frameworks handle a common task: creating a POST endpoint that accepts an item, validates

Microsoft has outlined an AI governance architecture spanning nine governance domains and four functions: policy, control, visibility, and proof. The approach connects policies with runtime enforcement, continuous evaluation, observability, identity, security, and audit evidence to help organizations verify governance requirements as AI applications and agents operate in production. By Leela Kumili

Two audio players do not make a fair before-and-after test. If the second player restarts from zero or takes half a second to load, the user is no longer comparing two versions of the same moment. They are comparing two memories. That is a weak way to evaluate any audio effect. It is especially weak for AI processing. A denoiser can remove a fan while softening consonants. A de-reverb model can reduce the room tail while making the voice sound less natural. The output may be cleaner without being better. The preview therefore has one job: let the listener switch quickly enough to hear both the improvement and the damage. The rule I use is deliberately boring. Both versions should contain the same edit and play from the same position. Switching should not restart playback or create a pause. The interface should not hint that one version is supposed to win. Two independent <audio> elements fail surprisingly quickly. Each owns its playback state, buffering behavior, clock, and seek operation. The user ends up finding the same position twice and comparing one sound with a memory of another. A better interface has one transport and one version control: [ Play ] [ Original | Processed ] 00:18 ━━━━━━━ 00:42 The transport decides where playback happens. The segmented control decides which signal is audible. One transport, two signals For a short preview, I decode both files into AudioBuffer s, start them at the same AudioContext time and offset, and route each through its own GainNode . Both sources run; only one gain is open. decodeAudioData() decodes complete file data and resamples it to the context's sample rate. The decoded buffers can then share the same audio clock. See the MDN documentation for format and loading details. The core is small: const context = new AudioContext (); const originalGain = context . createGain (); const processedGain = context . createGain (); originalGain . connect ( context . destination ); processedGain . connect ( context . destination )

Building AI Agents with frameworks like CrewAI or LangChain often hits a bottleneck: heavy, slow web scraping that bloats context windows and increases LLM token costs. To solve this, I built Smart Scraper M2M — a lightweight, high-performance web scraper API designed specifically for machine-to-machine (M2M) communication. 🌟 Key Features ⚡ Ultra-fast: Returns clean structured JSON in ~30ms . 🧠 Context-optimized: Strips out useless HTML/CSS junk so your LLMs process only relevant data. 🤖 Agent-friendly: Built to integrate seamlessly into CrewAI, LangChain, or custom Node.js agents. 🚀 Quick Start You can test the API or check the full source code directly on GitHub: 🔗 GitHub Repository: https://github.com/MRIGL/smart-scraper-m2m 💬 Feedback & Community I’m actively improving the API and would love to hear your thoughts, feature requests, or contributions! Feel free to star the repo or leave a comment below.

If you invoice or onboard Polish companies, sooner or later you have to check two dull things that turn out to matter a lot: is this company actually a registered VAT payer, and is the bank account they gave you the one that's on the government's official white list ("Biała Lista")? Both of those affect whether you can deduct the cost and reclaim VAT, so it's not really optional. The annoying part is that the data lives in four different places: the Ministry of Finance, the KRS court register, GUS (the stats office), and the EU's VIES service. Each one has its own API and its own quirks. I got tired of gluing those together every time, so I wrapped them behind a few plain HTTP calls that return JSON. Full disclosure: skanfirmy.pl is mine. It's free, no key, no signup, and the web layer runs client-side with no tracking. Here's how you'd actually use it. REST: one GET, one JSON Cheapest thing you can do is check a NIP (the tax ID): curl https://skanfirmy.pl/nip/5260250995 You get back the VAT status (active, exempt, or not registered), the company details from the VAT register, and the accounts sitting on the white list. The paths: GET /nip/{nip} gives VAT status + white-list data for one NIP GET /nips/{list} takes several NIPs at once (comma-separated) GET /regon/{nip} returns data from the REGON register (GUS) GET /vies/{country}/{number} validates an EU VAT number, e.g. /vies/DE/811128135 It's a plain GET that returns JSON, so it drops into anything that can make an HTTP request: a cron job, a lambda, a CI step, whatever. Python requests and a few lines. This one raises if the company isn't an active VAT payer: import requests def check_vat ( nip : str ) -> dict : r = requests . get ( f " https://skanfirmy.pl/nip/ { nip } " , timeout = 10 ) r . raise_for_status () data = r . json () status = data . get ( " vatStatus " ) or data . get ( " status " ) if status != " Czynny " : # status comes back in Polish; compare against the raw value raise ValueError ( f " NIP { n

Bluesky starter packs look like a single thing in the app — a shareable page that lets a new user follow a curated group in one tap. At the protocol level they are three separate records glued together by references, and if you create them from code (we do, as part of an automated outreach pipeline), the decomposition matters: it decides what you can update later, what you can only create once, and where a naive script will quietly make a mess. The three records Everything below is plain com.atproto.repo.createRecord / putRecord calls against your own PDS — no special API surface. 1. The list — app.bsky.graph.list . A starter pack is backed by an ordinary Bluesky list with purpose: app.bsky.graph.defs#referencelist . The list record itself holds metadata — name, purpose, createdAt, plus optional description and avatar. Members live elsewhere. 2. The memberships — app.bsky.graph.listitem . One record per member, each holding the member's DID and the list's AT-URI. There is no "add 20 members" batch call in the record layer: twenty members means twenty listitem creates. Plan for partial failure in the middle of that loop — more below. 3. The pack — app.bsky.graph.starterpack . The record that makes the share page exist. Per the lexicon, name , list , and createdAt are required; list is the AT-URI of the referencelist from step 1, the name is capped at 50 graphemes, and optional feeds can attach custom feeds. The official limits: up to 150 people, up to 3 feeds. The share URL is derivable, not returned: https://bsky.app/starter-pack/{your-handle}/{rkey} where {rkey} is the tail of the starterpack record's AT-URI. The trap: creation is not idempotent Every createRecord mints a fresh rkey. Run your create-starter-pack script twice and you have two packs with two URLs, both live, both indexed — and the one you already shared is not the one your script now reports. There is no natural key (like a title) that the protocol dedupes on. Our rules after learning this: Creation

WordPress is often treated as a traditional CMS, but its REST API makes it possible to use WordPress as the backend for applications, dashboards, mobile clients, automation systems, and external services. The difficult part isn't registering an endpoint. The difficult part is designing the endpoint so that authentication, authorization, validation, error handling, and data access are all handled correctly. A production API needs a contract. It needs to know: Who can access it What data they can access What input is accepted What output is returned What happens when something fails Here's a practical approach. Register a Custom Route A basic WordPress REST API route can be registered with register_rest_route() . add_action ( 'rest_api_init' , function () { register_rest_route ( 'myplugin/v1' , '/posts' , [ 'methods' => WP_REST_Server :: READABLE , 'callback' => 'myplugin_get_posts' , ]); }); This creates an endpoint similar to: /wp-json/myplugin/v1/posts The namespace matters. Using: myplugin/v1 gives the API a version boundary. If the response structure changes later, a new version can be introduced without immediately breaking existing clients. Don't Put Authorization Inside the Callback A common beginner implementation does everything inside the callback: function myplugin_get_posts () { if ( ! current_user_can ( 'manage_options' )) { return new WP_Error ( 'forbidden' , 'Access denied' , [ 'status' => 403 ] ); } // Query data... } This works, but WordPress provides a cleaner place for the permission decision. Use permission_callback . register_rest_route ( 'myplugin/v1' , '/posts' , [ 'methods' => WP_REST_Server :: READABLE , 'callback' => 'myplugin_get_posts' , 'permission_callback' => function () { return current_user_can ( 'manage_options' ); }, ]); Now the endpoint has a clearer separation: Request ↓ Permission check ↓ Callback ↓ Data That separation becomes increasingly valuable as an API grows. Authentication Is Not Authorization These concepts are easy to m