DEV Community: Dev Stack Hub

Best AI Web Scraper Tools in 2026: I Tested 7, These Are Worth It

Dev Stack Hub — Sun, 01 Nov 2026 15:14:04 +0000

I tested seven AI web scrapers, from no-code point-and-click tools to scraping APIs and open-source libraries. Here is what each one does well, where it falls short, and which one I would choose for different projects.

Last reviewed: October 2026. Pricing, plans, and features change fast in this category, so check each vendor's current docs before you commit.

TL;DR

No-code monitoring and scheduled extraction: Browse AI
No-code bulk scraping with ready-made templates: Octoparse
Quick extraction straight from your browser: Thunderbit
Developer feeding data to an LLM, RAG pipeline, or agent: Firecrawl
Protected sites at scale: Bright Data
Self-hosted Python with LLM-based extraction: ScrapeGraphAI
Free, self-hosted crawling to clean Markdown: Crawl4AI

AI web scraping sounds simple: point a tool at a page, say what data you want, and get clean rows or JSON back. But once you move past the demo page, the differences between tools become obvious. Layout changes break selectors, JavaScript-heavy pages return empty HTML, anti-bot systems block requests, and the cost model decides whether the project survives.

Some of these tools are built for people who never want to see a selector. Others give developers an API that returns LLM-ready Markdown. A few are open-source libraries you run on your own machine.

I compared 7 tools across three groups: no-code scrapers, scraping APIs, and open-source libraries. This is an editorial comparison based on each tool's documented capabilities and public product information, not a controlled benchmark in which every tool ran against identical pages.

My biggest takeaway: The best AI scraper is the one that still works in week two, when the site changes its layout, the volume grows, and the data has to keep flowing.

What is an AI web scraper?

A traditional scraper relies on selectors (CSS or XPath) that you write and maintain. An AI web scraper uses a language model or learned patterns to decide what to extract from a plain-language prompt, a schema, or a few clicks. Many also return output meant for LLMs, such as clean Markdown or structured JSON.

For example, you might ask a tool to pull the name, price, and availability from every product page on a store, without writing a single selector.

But AI doesn't remove the hard parts of scraping: rendering JavaScript, avoiding blocks, running at scale, and staying within a site's rules. The tools also put AI in different places. Some use it only to suggest fields, some to interpret every page, and some mainly to render and clean pages for an LLM to read. That distinction should drive your choice.

How AI scrapers work under the hood

Most AI scrapers run the same four stages, and the tools differ mainly in which stages they handle for you.

Stage	What happens	Typical failure	Who handles it
1. Fetch and render	Load the page, run JavaScript, route through proxies	Empty HTML, 403 errors, CAPTCHAs	Scraping APIs and Bright Data; you, with open-source libraries
2. Clean	Strip navigation, ads, and scripts; convert to Markdown or simplified HTML	Boilerplate leaks into the output	Firecrawl and Crawl4AI
3. Extract	Pull fields with selectors, a schema, or an LLM	Wrong or missing fields	All of them, in different ways
4. Validate and store	Check types, retry failures, save	Silent bad data	You

The practical difference shows up in how you describe what you want. A traditional scraper encodes the structure of the page, so it breaks when the markup changes:

import requests
from bs4 import BeautifulSoup

html = requests.get("https://example.com/products", timeout=30).text
soup = BeautifulSoup(html, "html.parser")

products = [
    {
        "name": card.select_one("h2.product-title").get_text(strip=True),
        "price": card.select_one("span.price").get_text(strip=True),
    }
    for card in soup.select("div.product-card")
]

An AI scraper encodes the result you want instead. You describe the output as a schema, and the tool works out where the fields are:

from pydantic import BaseModel

class Product(BaseModel):
    name: str
    price: float
    in_stock: bool

# An AI scraper takes a schema like this plus a URL or a prompt and
# returns objects shaped like Product. The sections below show
# example calls for each tool.

Choosing an approach by page type

Page type	Symptom	Start with
Static HTML	The data is visible in the raw response	Plain requests with selectors, or Crawl4AI
JavaScript-rendered	The raw response is nearly empty	Firecrawl, Crawl4AI (Playwright), or Bright Data's Browser API
Protected	403 errors, CAPTCHAs, rate limiting	Bright Data's unblocking tools, or Firecrawl
Behind a login	Content appears only after sign-in	Browse AI robots, Firecrawl's interact features, or a browser-based API
Irregular layouts	Selectors keep breaking	LLM extraction with ScrapeGraphAI or Firecrawl's extract

How the tools are compared

A scraper that works on one clean page tells you little about week two. So the tools are judged on five criteria that matter after the first successful run:

Ease of setup: how quickly its intended user gets a first working extraction, and what skills that takes
Extraction quality: whether you get accurate, structured output from messy real-world pages
Dynamic sites and anti-bot handling: JavaScript rendering, logins, and blocking
Scale and cost control: how volume, concurrency, and pricing behave as the project grows, and whether you can self-host
Output and integrations: APIs, exports, scheduling, LLM-ready formats, and MCP support

The better tool keeps delivering clean data when the site changes, volume grows, and the target starts fighting back.

The 7 tools at a glance

Tool	Category	Best for	Coding knowledge needed
Browse AI	No-code scraper	Scheduled extraction and change monitoring	None
Octoparse	No-code scraper	Template-based bulk scraping with cloud runs	None
Thunderbit	No-code scraper	Fast extraction from your browser	None
Firecrawl	Scraping API	LLM-ready Markdown and JSON for apps and agents	Beginner to intermediate
Bright Data	Scraping API and infrastructure	Protected sites and large-scale collection	Intermediate to advanced
ScrapeGraphAI	Open-source library	Prompt-driven extraction in Python	Intermediate
Crawl4AI	Open-source library	Self-hosted crawling to clean Markdown	Intermediate

Scorecard against the five criteria

These ratings reflect my editorial judgment based on documented capabilities, not measured test results. Ease of setup is rated for each tool's intended user, so a high score for an API means it is easy for a developer.

Tool	Ease of setup	Extraction quality	Dynamic sites and anti-bot	Scale and cost control	Output and integrations
Browse AI	High	Medium	Medium	Medium	High
Octoparse	High	Medium	Medium	Medium	Medium
Thunderbit	High	Medium	Medium	Low	Medium
Firecrawl	High	High	Medium	High	High
Bright Data	Low	Medium	High	High	High
ScrapeGraphAI	Medium	Medium	Low	Medium	Medium
Crawl4AI	Medium	Medium	Medium	High	Medium

The trade-off is clear. No-code tools are the quickest to start but the least flexible at scale. Scraping APIs handle blocking and volume for you at a usage-based cost. Open-source libraries give you the most control and the lowest cost, but leave browsers, proxies, and scaling to you.

Who should pick what

You are...	Start with	Why
A marketer or analyst who needs recurring data	Browse AI or Octoparse	You set it up visually and it runs on a schedule
Someone who needs a table from a page right now	Thunderbit	Extraction starts from the page in your browser
A developer building an LLM app, RAG pipeline, or agent	Firecrawl	One API for scrape, crawl, search, and extract, with Markdown and JSON output
A team scraping protected sites at scale	Bright Data	Proxy and unblocking infrastructure is the core product
A Python developer who wants prompt-based extraction	ScrapeGraphAI	Describe the fields in a prompt and run it with your own LLM
A developer who wants free, self-hosted crawling	Crawl4AI	Open source, runs on your own infrastructure

My default picks: Browse AI for non-developers, Firecrawl for developers building with LLMs, Bright Data when blocking is the main problem, and Crawl4AI when you want to self-host. Replace any of these if the specifics below fit your project better.

Category 1: No-Code Scrapers (For Non-Developers)

These are the best places to start if you want data in a spreadsheet without writing code or running infrastructure.

1. Browse AI

I would send someone who needs data from a website on a schedule and doesn't want to touch code to Browse AI. You train a robot by pointing and clicking on the data you want, then run it on demand or on a schedule. Its help center describes it as a way to scrape, monitor, and automate data extraction without coding.

What makes it useful

Point-and-click robot training, with no selectors or XPath
Scheduled runs with change monitoring and notifications
Prebuilt robots for popular sites and use cases
Handling for pagination, scrolling, and, in many cases, logged-in pages
Results delivered as a spreadsheet, a file, or an API

For example, a retailer could train a robot on three competitor product pages, run it every morning, and get an alert when a price changes.

The important part is to train on representative pages. A robot that has only seen one layout may miss fields on a page that looks slightly different.

Where it falls short: Robots are tied to the structure of the pages they were trained on, so a redesign can break them. Sites with aggressive anti-bot protection or complex login flows may not work reliably, and monitoring many pages can quickly use up credits.

My verdict: Browse AI is my starting recommendation for non-developers who need recurring data or change alerts from a handful of sites.

2. Octoparse

Octoparse is a no-code scraper with a desktop app and optional cloud runs. You select data visually, or start from a template, and it handles the extraction. Its website lists a library of preset templates for common targets such as maps, marketplaces, and directories.

What makes it useful

A visual builder with automatic on-page data detection
A large library of ready-made templates for popular sites
Cloud runs and scheduling on paid plans, so your computer doesn't have to stay on
Anti-blocking options such as proxies and CAPTCHA solving, on paid tiers
An API and an MCP server for triggering tasks from other tools and agents

For example, an e-commerce analyst could pick a marketplace template, change the search term, and schedule a daily export of listings.

The free plan is best treated as a trial. It runs locally, so recurring cloud jobs need a paid plan.

Where it falls short: Reviewers report slower results on JavaScript-heavy pages, and cloud concurrency is capped by plan. It isn't an API-first crawler, so developers who want code-level control will outgrow it.

My verdict: Octoparse is a good fit for analysts and small teams that want template-driven bulk scraping and scheduling without a developer.

3. Thunderbit

Thunderbit is an AI scraper that runs as a Chrome extension. You open a page, click once, and it suggests the fields to extract, which you can adjust or extend by describing extra columns in plain language. It can also visit linked pages and add their data as extra columns.

What makes it useful

AI-suggested fields, with custom columns defined by natural-language instructions
Subpage scraping that enriches a table with data from linked pages
Templates for popular sites
Export to Google Sheets, Airtable, Notion, and common file formats
Scheduled scraping on paid plans and an API for programmatic use

For example, a recruiter could scrape a list of candidate profiles and let it open each profile to collect a contact detail into a new column.

Where it falls short: Browser-based work suits small and medium jobs better than high-volume collection. Check how it handles logins, blocking, and credit usage for your target sites, and spot-check the AI's field suggestions before you trust a large export.

My verdict: Thunderbit is the quickest way to turn a page you are already looking at into a spreadsheet, best for one-off and small recurring jobs.

Working with exports from no-code tools

No-code tools end in a CSV or JSON file, and that is where code takes over. Treat every export as untrusted input: coerce types and reject rows that don't fit your schema before they reach a database.

import pandas as pd
from pydantic import BaseModel, ValidationError

class Row(BaseModel):
    name: str
    price: float

df = pd.read_csv("export.csv")
df["price"] = pd.to_numeric(
    df["price"].astype(str).str.replace(r"[^0-9.]", "", regex=True),
    errors="coerce",
)

valid, rejected = [], []
for record in df.to_dict(orient="records"):
    try:
        valid.append(Row(**record))
    except ValidationError as err:
        rejected.append((record, str(err)))

print(f"{len(valid)} valid, {len(rejected)} rejected")

Category 2: Scraping APIs and Infrastructure (For Developers)

These give developers an API instead of a visual builder. You send a URL, and the service handles rendering, retries, and often blocking, then returns data your code can use.

4. Firecrawl

Firecrawl is built for developers who want web data in a form that LLMs can use. A single API covers scraping, crawling, mapping, search, and structured extraction, and it returns clean Markdown or JSON. Its documentation also describes endpoints for interacting with pages and for monitoring them for changes.

What makes it useful

Scrape one page, crawl a whole site, map its URLs, or search and scrape results in one call
LLM-ready Markdown, or structured JSON from a schema or a prompt
SDKs for Python, Node.js, Go, Rust, and Java, plus a CLI
A hosted MCP server, so Claude, Cursor, and other MCP clients can call it directly
An open-source version you can self-host

For example, to give an agent fresh context, you could search for a topic, scrape the top results as Markdown, and pass the text to the model.

The important part is to start with the simplest endpoint that fits. A plain scrape often does the job before you need structured extraction.

A minimal Python quick start with the official SDK. Response field names have varied between SDK versions, so check the current SDK reference before copying this into production.

# pip install firecrawl-py
import os
from firecrawl import Firecrawl

app = Firecrawl(api_key=os.environ["FIRECRAWL_API_KEY"])

# 1. Scrape one page to LLM-ready Markdown
doc = app.scrape("https://example.com/pricing", formats=["markdown"])
print(doc.markdown[:300])

# 2. Crawl a documentation site
crawl = app.crawl(
    "https://docs.example.com",
    limit=50,
    scrape_options={"formats": ["markdown"]},
)
for page in crawl.data:
    print(page.markdown[:100])

# 3. Search, then scrape the top results
results = app.search(
    "vector database benchmarks 2026",
    limit=5,
    scrape_options={"formats": ["markdown"]},
)

For structured output, pass a schema so the response has a predictable shape:

from pydantic import BaseModel

class Product(BaseModel):
    name: str
    price: float
    in_stock: bool

result = app.extract(
    urls=["https://example.com/product/42"],
    schema=Product,
    system_prompt="Extract the product name, price, and availability",
)
print(result.data)

Where it falls short: It is credit-based, so crawling large sites adds up, and heavier features like extraction may cost more than a basic scrape. If you plan to self-host, check which features the open-source version includes compared with the hosted one.

My verdict: Firecrawl is my default for developers building LLM apps, RAG pipelines, and agents that need clean web content with minimal setup.

5. Bright Data

Bright Data is less a single tool than a web data platform. Its documentation lists a Scraper API for structured data from specific sites, Scraper Studio, datasets, a Web Unlocker API, a SERP API, a Browser API, and large proxy networks, along with an MCP server for AI agents.

What makes it useful

Unblocking infrastructure, with Web Unlocker handling blocks and CAPTCHAs
Prebuilt scrapers that return structured data from popular sites
A Browser API for pages that need a real browser session
Proxy networks for geographic targeting
An MCP server that exposes these tools to AI agents and coding assistants

For example, a team that tracks product data from heavily protected retail sites could use a prebuilt scraper instead of maintaining its own proxies and unblocking logic.

To give an MCP client such as Claude Desktop or Cursor access to Bright Data, add the server to your MCP configuration. It runs through npx, and by default it uses a Web Unlocker zone named mcp_unlocker, which you can override with the WEB_UNLOCKER_ZONE environment variable.

{
  "mcpServers": {
    "Bright Data": {
      "command": "npx",
      "args": ["@brightdata/mcp"],
      "env": {
        "API_TOKEN": "<your-brightdata-api-token>"
      }
    }
  }
}

Where it falls short: The breadth also creates complexity: you have to understand many products and pricing models before you pick the right one. Costs are usage-based, which is efficient for hard-to-reach sites and expensive for easy ones, so check which product your target actually needs. You remain responsible for collecting data legally and under each site's terms.

My verdict: Bright Data is the strongest option when getting blocked, not parsing, is your main problem, and you have the engineering time to use a larger platform.

Category 3: Open-Source Libraries (For Self-Hosters)

These are libraries you install and run yourself. You get the most control and the lowest license cost, but you handle the browsers, proxies, and scaling.

6. ScrapeGraphAI

ScrapeGraphAI is a Python library that combines an LLM with graph-based pipelines to scrape websites and local documents. You say which information you want, and the library builds the extraction for you. Its GitHub repository is MIT-licensed and also points to a managed cloud API with SDKs.

What makes it useful

Prompt-driven extraction: describe the fields instead of writing selectors
Ready-made pipelines, such as a single-page scraper, a search-and-scrape pipeline, and one that generates a Python script for multiple pages
Works with hosted models or local ones through Ollama
Supports schemas for structured output
A managed API is available if you don't want to run it yourself

For example, you could point it at a company page and ask for the description, founders, and contact email, and get a dictionary back.

The important part is to define a schema. Without one, the output shape can change between runs.

Here is a schema-based pipeline that runs against a local model through Ollama. To use a hosted model instead, change the llm block to include an api_key and a model such as openai/gpt-4o-mini.

# pip install scrapegraphai && playwright install
from typing import List
from pydantic import BaseModel, Field
from scrapegraphai.graphs import SmartScraperGraph

class Product(BaseModel):
    name: str = Field(description="Product name")
    price: str = Field(description="Price as shown on the page")

class ProductList(BaseModel):
    products: List[Product]

graph_config = {
    "llm": {"model": "ollama/llama3.2", "model_tokens": 8192},
    "headless": True,
}

graph = SmartScraperGraph(
    prompt="Extract all products with their names and prices",
    source="https://example.com/products",
    schema=ProductList,
    config=graph_config,
)

print(graph.run())

Where it falls short: In the open-source version, you manage the browsers, proxies, and scaling yourself, and every page costs LLM tokens or local compute. Because an LLM interprets each page, extraction can vary, so validate the output before it feeds anything important. The project's README also frames it as meant for data exploration and research.

My verdict: ScrapeGraphAI is a good fit for Python developers who want to prototype prompt-based extraction quickly and are happy to run their own LLM.

7. Crawl4AI

Crawl4AI is an open-source, LLM-friendly crawler and scraper that turns web pages into clean Markdown for RAG, agents, and data pipelines. It runs on Playwright, installs with pip, and can also be deployed with Docker. See the GitHub repository and the documentation.

What makes it useful

Clean Markdown output, with a filtered mode that strips noise from pages
An async crawler with a browser pool, caching, and deep crawling strategies
Structured extraction with CSS-based strategies, or with any LLM, including local models
Sessions, proxies, cookies, and hooks for custom behavior
A command-line interface and Docker images, with no API keys required

For example, you could crawl a documentation site to depth three, save the Markdown, and feed it into a vector store.

The important part is to use CSS-based extraction for repetitive pages and save the LLM for irregular ones. It is cheaper and more predictable.

This example uses CSS-based extraction, so the crawl needs no LLM calls. It also prints the page's Markdown, and extraction strategies and config options have changed between releases, so check the documentation for your installed version.

# pip install crawl4ai && crawl4ai-setup
import asyncio
import json
from crawl4ai import AsyncWebCrawler, CrawlerRunConfig, CacheMode
from crawl4ai.extraction_strategy import JsonCssExtractionStrategy

schema = {
    "name": "Products",
    "baseSelector": "div.product-card",
    "fields": [
        {"name": "title", "selector": "h2.product-title", "type": "text"},
        {"name": "price", "selector": "span.price", "type": "text"},
    ],
}

async def main():
    config = CrawlerRunConfig(
        extraction_strategy=JsonCssExtractionStrategy(schema),
        cache_mode=CacheMode.BYPASS,
    )
    async with AsyncWebCrawler() as crawler:
        result = await crawler.arun("https://example.com/products", config=config)
        print(json.loads(result.extracted_content))
        print(result.markdown[:300])

asyncio.run(main())

The command-line interface covers quick jobs without writing any Python:

# Crawl one page to Markdown
crwl https://www.example.com/blog -o markdown

# Deep crawl with a breadth-first strategy, capped at 10 pages
crwl https://docs.crawl4ai.com --deep-crawl bfs --max-pages 10

Where it falls short: You run and maintain the infrastructure, including browser memory, scaling, and proxies. Anti-bot handling is largely your responsibility, so heavily protected sites will need extra work or a service like the ones above.

My verdict: Crawl4AI is a strong choice for developers who want free, self-hosted crawling to Markdown and don't mind operating it.

ScrapeGraphAI or Crawl4AI?

Both are open source and run on your own machine. Crawl4AI focuses on fast, controllable crawling and clean Markdown, with optional LLM extraction. ScrapeGraphAI starts from the LLM and builds the extraction around a prompt. If you mostly need crawled content for retrieval, start with Crawl4AI. If you want to describe fields and get structured data back, try ScrapeGraphAI. Test each on the same small set of your own pages and compare the output.

Pricing, scale, and lock-in

Prices change too often to list, but the models differ in ways that matter:

No-code tools are typically plan- or credit-based, and cloud runs, scheduling, and anti-blocking often sit on paid tiers. Free plans are better for trials than production.
Scraping APIs are usage-based. Firecrawl bills in credits per page, while Bright Data prices by product and volume, so estimate your page count before you commit.
Open-source libraries cost nothing to license, but you pay for servers, proxies, and, for LLM extraction, tokens.

Lock-in lives in the setup. Robots, templates, and workflows built inside a no-code tool don't move easily, while open-source code and standard outputs like Markdown and JSON do.

In general, the more the tool does for you, the more you should check export options and exit costs before you commit.

What AI scrapers can't replace

AI has made scraping more accessible, but it hasn't removed the need for judgment and validation.

Rules and permissions still matter: Check a site's terms and robots.txt, avoid personal data you have no right to collect, and get legal advice if you're unsure. A tool being able to fetch a page doesn't mean you are allowed to use the data.
Extraction needs verification: Language models can misread a field or invent a value. Spot-check outputs, validate against a schema, and watch for silent changes in format.
Maintenance never disappears: Sites change layouts, add blocking, and move content behind logins. Plan for monitoring and fixes, not a one-time setup.
Cost has to be modeled: Credits, proxies, and LLM tokens scale with page count. Test on a small sample and multiply before you commit to a large crawl.

AI scraping works best when the tool handles the repetitive extraction, and you stay responsible for what you collect, how you use it, and whether it is correct.

Production patterns that apply to any scraper

These three patterns work with every tool in this guide, because they wrap whatever scraper you choose.

Check robots.txt before you fetch

Python's standard library can read robots.txt. Remember that it is a convention, not legal permission, and a site's terms of service still apply.

from urllib import robotparser
from urllib.parse import urlparse

def allowed(url: str, user_agent: str = "my-scraper") -> bool:
    parts = urlparse(url)
    parser = robotparser.RobotFileParser()
    parser.set_url(f"{parts.scheme}://{parts.netloc}/robots.txt")
    parser.read()
    return parser.can_fetch(user_agent, url)

Retry with exponential backoff

Networks fail and sites rate-limit. Retry transient errors with growing delays, and give up after a few attempts instead of looping forever.

import random
import time

def with_retries(fn, attempts: int = 4, base: float = 1.0):
    for attempt in range(attempts):
        try:
            return fn()
        except Exception:
            if attempt == attempts - 1:
                raise
            time.sleep(base * 2 ** attempt + random.random())

Validate every record

LLM extraction can return a plausible but wrong value. Validate against a schema and treat a failure as a signal to inspect, not a row to store.

from pydantic import BaseModel, ValidationError, field_validator

class Product(BaseModel):
    name: str
    price: float

    @field_validator("price")
    @classmethod
    def price_is_sane(cls, value: float) -> float:
        if not 0 < value < 100_000:
            raise ValueError("price out of range")
        return value

def parse(record: dict):
    try:
        return Product(**record)
    except ValidationError:
        return None  # log it, don't store it

Run your own comparison

The scores in this guide come from documentation, not from your pages, so test on your own. Write one small function per tool that takes a URL and returns a dict, then run them all through the same harness. It reports median latency and how many of your expected fields each tool actually filled in.

import time
from statistics import median

URLS = [
    "https://example.com/product/1",
    "https://example.com/product/2",
    "https://example.com/product/3",
]
EXPECTED_FIELDS = {"name", "price", "in_stock"}

def benchmark(name, scrape_fn, urls=URLS):
    latencies, completeness = [], []
    for url in urls:
        start = time.perf_counter()
        try:
            record = scrape_fn(url)
        except Exception:
            record = {}
        latencies.append(time.perf_counter() - start)
        found = {key for key, value in record.items() if value not in (None, "")}
        completeness.append(len(found & EXPECTED_FIELDS) / len(EXPECTED_FIELDS))
    average = sum(completeness) / len(completeness)
    print(f"{name}: median {median(latencies):.2f}s, field completeness {average:.0%}")

# benchmark("firecrawl", firecrawl_scrape)
# benchmark("crawl4ai", crawl4ai_scrape)

Use at least 20 pages that include your hardest cases, such as long product lists, missing fields, and slow-loading pages. Then compare cost per page alongside the results.

Final verdict

No single tool suits every project. If you aren't a developer, start with Browse AI for scheduled data and change alerts, Octoparse for template-based bulk jobs, or Thunderbit for quick extraction from your browser. If you're building with LLMs, use Firecrawl. If the target fights back, use Bright Data. If you want to self-host, choose Crawl4AI for crawling to Markdown or ScrapeGraphAI for prompt-based extraction.

AI scraping shortens the time between wanting data and having it, but the first successful run is only the beginning. Choose the tool that fits your technical comfort, handles your target sites, and keeps working when those sites change.

Frequently asked questions

What is the best AI web scraper?

It depends on who is using it. Browse AI, Octoparse, and Thunderbit suit non-developers. Firecrawl suits developers building with LLMs, Bright Data suits protected sites at scale, and Crawl4AI and ScrapeGraphAI suit self-hosters.

Can I scrape a website without coding?

Yes. No-code tools let you select data visually or describe it, then export it to a spreadsheet or app. Complex sites with logins or heavy blocking may still need a developer or a more capable service.

What are the best web scraping tools for beginners?

For beginners, no-code web scraping tools are the easiest starting point since they need no coding knowledge. Browse AI and Octoparse are good for scheduled or template-based jobs, and Thunderbit works well for quick one-off extraction from your browser. Once you're comfortable with Python, Firecrawl and Crawl4AI are approachable next steps for LLM-ready output.

What is the difference between a scraping API and an open-source library?

A scraping API is a hosted service that handles rendering, retries, and often blocking, and bills by usage. An open-source library runs on your own infrastructure, costs nothing to license, and leaves browsers, proxies, and scaling to you.

Is AI web scraping legal?

It depends on the site, the data, and where you are. Review the site's terms and robots.txt, avoid collecting personal data without a lawful basis, and get legal advice for commercial or sensitive projects.

Which tool is best for feeding data to an LLM or RAG pipeline?

Firecrawl and Crawl4AI both return clean Markdown designed for LLMs. Firecrawl is a hosted API with SDKs and an MCP server, while Crawl4AI is free to self-host. Bright Data can supply the pages when sites block simpler tools.

Great guide! Playwright is a powerful choice for scraping JavaScript-heavy websites. The practical examples make it easier to understand how to handle dynamic content and extract data reliably.

Dev Stack Hub — Sat, 31 Oct 2026 15:38:50 +0000

Alina Shah

Oct 31

Scrape JavaScript-Heavy Sites with Playwright in Python (Developer Guide)

#discuss #javascript #python #playwright

9 min read

6 Best API Gateways for Developers Breaking Their Routing Logic

Dev Stack Hub — Sat, 31 Oct 2026 14:43:59 +0000

Six API gateways compared through the lens of routing: path matching, rewrites, header-based rules, and traffic splitting. Here is what each one does well, where it falls short, and which one I would choose for different projects.

Last reviewed: October 2026. Pricing, licensing, and features change often in this category, so check each vendor's current docs before you commit.

TL;DR

AWS-native and fully managed: Amazon API Gateway.
Enterprise API programs with governance and policies: Apigee.
Microsoft and Azure shops: Azure API Management.
Fine-grained route matching and a big plugin ecosystem: Kong Gateway (read the licensing note first).
Stateless, declarative, and good at aggregation: KrakenD.
Open-source core with an optional dashboard: Tyk.

Most gateway bugs are routing bugs. A trailing slash that returns a 404. A rewrite that doubles a path segment. A canary that sends everything to the new version. A header rule that never fires because the casing is different.

Every gateway here can route a request. They differ in how you express rules, split traffic, ship config changes, and what happens when a rule is wrong.

I compared 6 gateways across two groups: cloud-managed and self-hosted. This is an editorial comparison based on each product's documented capabilities, not a benchmark in which every gateway handled identical traffic.

My biggest takeaway: the best gateway is the one whose routing rules you can read, test, and change safely when something breaks at 2 a.m.

What is an API gateway?

An API gateway is the single entry point between clients and your services. It receives every request, decides which upstream should handle it, and applies cross-cutting rules on the way: authentication, rate limits, transformations, and logging.

For example, a client calls /v1/orders/42, and the gateway authenticates it, rewrites the path to /orders/42, and forwards it to the orders service without the client knowing where that service lives.

That routing step is where gateways differ most. Some express rules as declarative config, some as XML policies, some as code-like expressions. That distinction should drive your choice.

How gateway routing works

Every gateway in this guide runs roughly the same pipeline for each request:

Stage	What happens	Typical failure
1. Match	Find the route by host, path, method, and headers	Wrong route wins, or no route matches
2. Authenticate and limit	Check keys, tokens, and quotas	Rule applied to the wrong route
3. Transform	Rewrite the path, add or strip headers	Doubled or missing path segments
4. Select upstream	Pick a backend: static, weighted, or conditional	Split ratios that don't match the config
5. Proxy	Forward with timeouts, retries, and health checks	Retries on non-idempotent calls
6. Respond	Return, transform, or aggregate the response	Leaked internal headers or errors

Here is how each gateway expresses the routing-specific parts:

Gateway	Match on	Rewrite with	Split traffic with
Amazon API Gateway	Resource path and method	Integration request mapping	Canary release settings on a REST API stage
Apigee	Base path, plus conditions on request variables	Policies and the target Path	Weighted load balancer across target servers
Azure API Management	Operation URL template and method, plus policy expressions	The `rewrite-uri` policy	A `choose` policy with a random expression, or backend pools
Kong Gateway	Paths (including regex), methods, hosts, and headers	`strip_path` and the service path	Weighted targets in an upstream
KrakenD	Endpoint and method; header conditions in Enterprise	`url_pattern` on each backend	Repeated hosts for weights, or DNS SRV weights
Tyk	`listen_path`, API versions, and rewrite rules	`strip_listen_path` and `target_url`	Load balancing with weights set in the Dashboard

One routing problem, six configs

To compare gateways fairly, I use the same problem throughout:

Rewrite: GET /v1/orders/{id} must reach the upstream as /orders/{id}.
Split: 90 percent of traffic goes to orders v1, and 10 percent goes to orders v2.
Override: a request with the header X-Canary: true always goes to v2.

Each tool section shows the config for this problem. Where a gateway can't do a part natively, I say so. The testing section at the end includes a small harness you can run against any of them.

How the tools are compared

A gateway that routes a demo request tells you little about production. So the tools are judged on five criteria that matter once real traffic and real teams arrive:

Routing expressiveness: how precisely you can match requests and rewrite them.
Traffic splitting and releases: how well it supports canary, blue/green, and header-based overrides.
Config model and GitOps: whether rules live in reviewable files you can test and deploy from CI.
Operations: how much infrastructure you run, and how it scales and fails.
Cost and licensing clarity: how predictable the pricing and license terms are.

The better gateway is the one that lets you change a routing rule safely, review it in a pull request, and roll it back quickly.

The 6 tools at a glance

Tool	Category	Best for	Config style
Amazon API Gateway	Cloud-managed	AWS-native APIs, Lambda, and private VPC integrations	OpenAPI and infrastructure as code
Apigee	Cloud-managed	Large API programs with governance	XML proxy bundles and policies
Azure API Management	Cloud-managed	Azure-based teams and hybrid deployments	XML policies and Bicep or ARM
Kong Gateway	Self-hosted	Rich route matching and plugins	Declarative YAML, decK, or Admin API
KrakenD	Self-hosted	Stateless gateways and API aggregation	A single JSON file
Tyk	Self-hosted	Open-source core with optional dashboard	API definitions in JSON or YAML

Scorecard against the five criteria

These ratings reflect my editorial judgment based on documented capabilities, not measured test results.

Tool	Routing expressiveness	Traffic splitting and releases	Config model and GitOps	Operations	Cost and licensing clarity
Amazon API Gateway	Medium	High	Medium	High	High
Apigee	High	Medium	Medium	High	Low
Azure API Management	High	Medium	Medium	High	Medium
Kong Gateway	High	High	High	Medium	Low
KrakenD	Medium	Low	High	High	High
Tyk	Medium	Medium	High	Medium	Medium

The trade-off is clear. Cloud-managed gateways remove the operations work but tie your routing logic to one vendor's model. Self-hosted gateways give you declarative config and portability, and you run them yourself.

Who should pick what

You are...	Start with	Why
An AWS-native team using Lambda or private services	Amazon API Gateway	Fully managed, with native canary releases on REST APIs
A large organization with an API governance program	Apigee	Policy-driven proxies and API product management
A team standardized on Azure	Azure API Management	Policy expressions and deep Azure integration
A team that needs flexible route matching and plugins	Kong Gateway	Routes by path, host, header, and regex, plus weighted upstreams
A team that wants a stateless gateway in one JSON file	KrakenD	Simple deployment and built-in aggregation
A team that wants an open-source core and a dashboard	Tyk	Open-source gateway with a commercial dashboard option

My default picks: Amazon API Gateway if you're on AWS, Azure API Management if you're on Azure, KrakenD for a simple self-hosted gateway, and Kong when you need the richest route matching and can accept its licensing terms. Replace any of these if the specifics below fit your project better.

Category 1: Cloud-Managed Gateways

These run as a service, so you don't patch or scale gateway nodes. They are the best place to start if your backends already live in that cloud.

1. Amazon API Gateway

Amazon API Gateway is AWS's managed gateway. It offers REST, HTTP, and WebSocket APIs, and it integrates directly with Lambda, HTTP backends, and private services inside a VPC. Its canary release documentation describes how to send a percentage of traffic to a new deployment.

What makes it useful

Fully managed, with no gateway servers to run or scale.
Stage variables let one API definition point to different backends per stage.
Canary release deployments on REST API stages, with a percentTraffic setting and stage variable overrides.
Native integrations with Lambda, authorizers, usage plans, and AWS services.
Configuration through OpenAPI, the AWS CLI, and infrastructure-as-code tools.

Here is the rewrite part of the running problem for a REST API. The integration URI uses a stage variable for the host, and the path parameter is mapped from the method request to the integration request.

openapi: "3.0.1"
info:
  title: orders-gateway
  version: "1.0"
paths:
  /v1/orders/{id}:
    get:
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
      x-amazon-apigateway-integration:
        type: http_proxy
        httpMethod: GET
        uri: http://${stageVariables.ordersHost}/orders/{id}
        requestParameters:
          integration.request.path.id: method.request.path.id
        passthroughBehavior: when_no_match

The 90/10 split comes from a canary release. First deploy to the stage with the production host in a stage variable, then deploy again with canary settings that override that variable for 10 percent of traffic:

# 1. Deploy v1 to the stage, with the host in a stage variable
aws apigateway create-deployment \
  --rest-api-id abcd1234 \
  --stage-name prod \
  --variables ordersHost=orders-v1.internal.example.com

# 2. Deploy again as a canary that overrides the variable for 10% of requests
aws apigateway create-deployment \
  --rest-api-id abcd1234 \
  --stage-name prod \
  --canary-settings percentTraffic=10,stageVariableOverrides={ordersHost=orders-v2.internal.example.com}

The important part is that the split is percentage-based and applies to the whole stage. I didn't find a native way to force a header such as X-Canary: true to v2 in the documentation I reviewed, so a header override needs a separate stage or a layer in front.

Where it falls short: A canary deployment covers the whole API stage, so you can't canary a single route. The documented canary workflow is for REST APIs, so check the current feature matrix if you plan to use the lighter HTTP API type. Routing rules also live partly in OpenAPI extensions and partly in stage settings, which makes them harder to review in one place.

My verdict: Amazon API Gateway is my default for AWS-native teams that want a managed gateway and simple percentage-based canaries.

2. Apigee

Apigee is Google Cloud's API management platform. You build an API proxy from a bundle of XML: a ProxyEndpoint that receives requests, a TargetEndpoint that calls your backend, and policies in between. Its load balancing documentation covers target servers and the available algorithms.

What makes it useful

RouteRules with conditions let one proxy send requests to different TargetEndpoints.
Target servers separate backend hosts from proxy config so that you can change them per environment.
A built-in load balancer with RoundRobin, Weighted, and LeastConnections algorithms.
A large policy library for transformation, security, and traffic management.
Managed and hybrid deployment options.

This proxy covers the whole routing problem: the BasePath handles /v1/orders, a header-based RouteRule overrides to v2, and a weighted load balancer splits everything else.

<ProxyEndpoint name="default">
  <HTTPProxyConnection>
    <BasePath>/v1/orders</BasePath>
  </HTTPProxyConnection>

  <!-- Header override: always v2 -->
  <RouteRule name="canary-header">
    <Condition>request.header.x-canary = "true"</Condition>
    <TargetEndpoint>orders-v2</TargetEndpoint>
  </RouteRule>

  <!-- Default rule goes last -->
  <RouteRule name="default">
    <TargetEndpoint>orders-split</TargetEndpoint>
  </RouteRule>
</ProxyEndpoint>

<TargetEndpoint name="orders-split">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Algorithm>Weighted</Algorithm>
      <Server name="orders-v1"><Weight>9</Weight></Server>
      <Server name="orders-v2"><Weight>1</Weight></Server>
    </LoadBalancer>
    <Path>/orders</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

<TargetEndpoint name="orders-v2">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Server name="orders-v2" />
    </LoadBalancer>
    <Path>/orders</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

The request path after the BasePath is appended to the target Path, so /v1/orders/42 reaches the backend as /orders/42. The orders-v1 and orders-v2 names refer to target servers that you define in the environment.

The important part is that every server in one load balancer shares the same Path. If v2 lived at a different path, a weighted balancer can't express that, and you would need conditional routes or a separate proxy in front.

Where it falls short: The XML bundle model is verbose, and routing logic spreads across proxy endpoints, target endpoints, and target servers. Enterprise-grade pricing and platform breadth make it heavy for a small team that only needs routing. Check the current pricing model before you commit.

My verdict: Apigee is the strongest option when routing is one part of a larger API governance program, and a poor fit when it is the whole job.

3. Azure API Management

Azure API Management, or APIM, is Microsoft's managed gateway. Its routing logic lives in policies, XML snippets that run in the inbound, backend, outbound, and on-error sections of a request. Policies can be set at global, product, API, or operation scope. See the set-backend-service policy reference.

What makes it useful

Policy expressions use C# syntax so that conditions can inspect headers, query strings, and variables.
set-backend-service switches the backend by base URL or by a named backend entity.
Backend entities can form a load-balanced pool with circuit breaker rules.
Gateway options include classic, v2, consumption, and self-hosted gateways for hybrid setups.
You can configure this through the portal, Bicep, ARM, and the management API.

Here is an operation-level policy for the running problem. It rewrites the path, then picks a backend with a header override or a 10 percent random split.

<policies>
  <inbound>
    <base />
    <rewrite-uri template="/orders/{id}" />
    <choose>
      <when condition="@(context.Request.Headers.GetValueOrDefault(&quot;x-canary&quot;, &quot;&quot;) == &quot;true&quot; || new System.Random().Next(1, 101) > 90)">
        <set-backend-service base-url="https://orders-v2.internal.example.com" />
      </when>
      <otherwise>
        <set-backend-service base-url="https://orders-v1.internal.example.com" />
      </otherwise>
    </choose>
  </inbound>
  <backend>
    <base />
  </backend>
  <outbound>
    <base />
  </outbound>
  <on-error>
    <base />
  </on-error>
</policies>

The operation's URL template would be /v1/orders/{id}. Published examples of this pattern note that APIM has no dedicated traffic-splitting policy, so you build it from a random expression, and each request is decided independently.

The important part is to keep the split values in named values, not hard-coded in the expression, so you can change the percentage without editing policy code.

Where it falls short: XML plus C# expressions is hard to unit test, and a quoting mistake is a runtime error. The random split is not sticky, so the same user can bounce between versions. Tier choice affects features and cost, so check the tier comparison before you design around a capability.

My verdict: Azure API Management is the natural choice for Azure-centric teams, and its policy expressions make header-based routing easy. Plan to build and test the traffic split yourself.

Category 2: Self-Hosted Gateways

These run on your infrastructure, in containers or on Kubernetes. You get portable, declarative config and full control, and you take on the operations and the licensing questions.

4. Kong Gateway

Kong Gateway models routing with services, routes, upstreams, and plugins. Routes match requests by path (including regex), method, host, and headers, and upstreams hold weighted targets. Its documentation covers the entities and the declarative config format.

A licensing note before you adopt it. Starting with Gateway 3.10, released in March 2025, Kong stopped publishing prebuilt open-source Docker images and removed free mode, so running 3.10 or later without a license behaves like an expired Enterprise license. The last open-source line is 3.9, which Kong's community discussions describe as frozen. Confirm Kong's current licensing and downloads before you choose it.

What makes it useful

Precise route matching on paths, regex, methods, hosts, and headers.
Upstreams with weighted targets and health checks, so a 90/10 split is a config value.
A large plugin ecosystem for authentication, rate limiting, and transformation.
Declarative config you can validate and sync from CI with decK, or run without a database.
Kubernetes support through its ingress controller.

This declarative file covers the running problem. The main route sends traffic to a weighted upstream, and a second, more specific route sends the canary header straight to v2.

_format_version: "3.0"

upstreams:
  - name: orders-upstream
    targets:
      - target: orders-v1.internal:8080
        weight: 90
      - target: orders-v2.internal:8080
        weight: 10

services:
  - name: orders
    host: orders-upstream
    path: /orders
    routes:
      - name: orders-route
        paths:
          - /v1/orders
        methods:
          - GET
        strip_path: true

  - name: orders-v2
    host: orders-v2.internal
    port: 8080
    path: /orders
    routes:
      - name: orders-canary-header
        paths:
          - /v1/orders
        methods:
          - GET
        headers:
          x-canary:
            - "true"
        strip_path: true

# Preview, then apply (older decK versions use `deck diff` and `deck sync`)
deck gateway diff kong.yaml
deck gateway sync kong.yaml

The important part is how the rewrite works. With strip_path set to true, Kong removes the matched route path, /v1/orders, and prepends the service path, /orders, so /v1/orders/42 reaches the backend as /orders/42.

Where it falls short: The licensing change is the biggest risk, because the free path now ends at an older release and current builds need a license. Route precedence between a plain route and a header route is easy to get wrong, so confirm the winner with a test request. Plugin availability also varies by tier, so check that the plugins you need are in the plan you choose.

My verdict: Kong has the most expressive routing in this list. Weigh the licensing terms first, and pick it when you will use that expressiveness.

5. KrakenD

KrakenD is a stateless gateway driven by one JSON file, with no database. You declare endpoints, and each endpoint lists the backends it calls. Its backend documentation explains how host, url_pattern, and aggregation work. The Community Edition is open source under Apache 2.0, and an Enterprise Edition adds features.

What makes it useful

Stateless and database-free, so deployment is a container and a config file.
An endpoint can call several backends in parallel and merge the results, which suits backend-for-frontend designs.
The url_pattern on each backend rewrites the path, using variables from the endpoint.
Egress load balancing across a host list, with DNS SRV records for weighted balancing.
Enterprise adds API key authentication and conditional routing, and the configuration is compatible with the Community Edition.

Here is the Community Edition config for the running problem. KrakenD's documentation describes a simple way to weight a host list: repeat the host. Nine entries for v1 and one for v2 give a 90/10 split.

{
  "$schema": "https://www.krakend.io/schema/krakend.json",
  "version": 3,
  "endpoints": [
    {
      "endpoint": "/v1/orders/{id}",
      "method": "GET",
      "output_encoding": "no-op",
      "backend": [
        {
          "encoding": "no-op",
          "url_pattern": "/orders/{id}",
          "host": [
            "http://orders-v1:8080", "http://orders-v1:8080", "http://orders-v1:8080",
            "http://orders-v1:8080", "http://orders-v1:8080", "http://orders-v1:8080",
            "http://orders-v1:8080", "http://orders-v1:8080", "http://orders-v1:8080",
            "http://orders-v2:8080"
          ]
        }
      ]
    }
  ]
}

The header override needs Enterprise conditional routing. In that edition, you split v1 and v2 into separate backends and let a header rule choose between them, with a fallback for everything else:

"backend": [
  {
    "url_pattern": "/orders/{id}",
    "host": ["http://orders-v2:8080"],
    "extra_config": {
      "backend/conditional": {
        "strategy": "header",
        "name": "X-Canary",
        "value": "true"
      }
    }
  },
  {
    "url_pattern": "/orders/{id}",
    "host": ["http://orders-v1:8080"],
    "extra_config": {
      "backend/conditional": {
        "strategy": "fallback"
      }
    }
  }
]

The important part is KrakenD's design rule that one endpoint can't have several write backends, which keeps the gateway from acting as a transaction coordinator.

Where it falls short: Weighted splitting in the Community Edition is a workaround, not a feature, and header-based routing and API keys are Enterprise-only. By default, url_pattern must be RESTful, which you can relax with disable_rest. KrakenD has also announced that it is dropping plugin support in the open-source edition, so check the current status if you depend on custom plugins.

My verdict: KrakenD is my default for a simple self-hosted gateway, especially when you want aggregation and a config file you can review in one place. It is the weakest option here for fine-grained traffic splitting.

6. Tyk

Tyk is a gateway whose routing lives in API definitions. Each definition sets a listen_path, a target_url, and options such as strip_listen_path and load balancing. The gateway is open source, and the Dashboard and other management features are offered commercially. Its load balancing documentation covers target lists and weighting.

What makes it useful

Simple API definitions, expressed as JSON or as Kubernetes resources through Tyk Operator.
Native round-robin load balancing with a target_list.
Weighting in the Dashboard so that you can send, for example, 10 percent of traffic to a beta backend.
Service discovery integrations, such as Consul and etcd, for dynamic target lists.
Rewrite rules that can act on request details, plus gRPC load balancing.

Here is a Tyk Operator definition for the running problem. Without weights, the two targets share traffic evenly.

apiVersion: tyk.tyk.io/v1alpha1
kind: ApiDefinition
metadata:
  name: orders
spec:
  name: orders
  use_keyless: true
  protocol: http
  active: true
  proxy:
    listen_path: /v1/orders
    strip_listen_path: true
    target_url: http://orders-v1.internal:8080/orders
    enable_load_balancing: true
    target_list:
      - http://orders-v1.internal:8080/orders
      - http://orders-v2.internal:8080/orders

The rewrite follows the documented rule: Tyk strips the listen path and appends what remains to the target URL, so /v1/orders/42 reaches the backend as /orders/42. For the 90/10 ratio, set weights of 9 and 1 in the Dashboard's load balancing settings. A header override can use a URL rewrite rule that matches the header, and the exact syntax depends on your Tyk version, so check its rewrite documentation.

The important part is how Tyk treats versions. Its documentation recommends a separate, non-versioned API definition for each URL-based version (e.g., /v1 and /v2), because versions in an API definition assume the same URL structure.

Where it falls short: Weighted routing is documented through the Dashboard, so confirm how you will express weights in your deployment model, whether files, the Operator, or the Dashboard. Without strip_listen_path, proxied requests are literal, so the listen path leaks into the upstream URL. Check which management features your use case needs a commercial license for.

My verdict: Tyk is a solid choice if you want an open-source gateway with a Kubernetes-friendly definition format and the option of a dashboard.

Kong, KrakenD, or Tyk?

Kong has the richest route matching and plugin ecosystem, but it carries the licensing risk described above. KrakenD is the simplest to run and the best at aggregation, but it has the weakest traffic splitting in its Community Edition. Tyk sits between them, with an open-source gateway, simple definitions, and weighting that lives in its Dashboard. Test each on the same routing problem, using the harness below, before you decide.

Pricing, licensing, and lock-in

Prices change too often to list, but the models differ in ways that matter:

Cloud-managed gateways charge by usage, tier, or subscription. Amazon API Gateway bills per request, Azure API Management sells tiers with different features, and Apigee uses enterprise-style pricing, so model your expected traffic before you compare.
Kong changed its terms in 2025: the free path ends at the 3.9 open-source line, and later releases need a license.
KrakenD has a free Community Edition under Apache 2.0 and a commercial Enterprise Edition that is quoted on request.
Tyk offers an open-source gateway, with commercial management features such as the Dashboard.

Lock-in lives in your rules. XML policies and C# expressions don't port between vendors, while declarative route definitions are easier to translate. Keep business logic out of the gateway, so switching is a routing migration, not a rewrite.

In general, the more routing logic you put into vendor-specific policy, the more you should check export options and exit costs before you commit.

Test your routing logic before production

Routing rules fail quietly, so test them like code. The setup below works against any gateway in this guide. First, a tiny upstream that reports its path and version, so you can see exactly what the gateway sent.

# echo.py  (pip install flask)
import os
from flask import Flask, jsonify, request

app = Flask(__name__)
VERSION = os.environ.get("VERSION", "v1")

@app.get("/orders/<order_id>")
def get_order(order_id):
    response = jsonify({"id": order_id, "path": request.path, "version": VERSION})
    response.headers["X-Served-By"] = VERSION
    return response

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8080)

Run one copy as v1 and another as v2, point the gateway at them, then assert the three requirements from the running problem:

import collections
import requests

GATEWAY = "http://localhost:8000"

def test_path_is_rewritten():
    r = requests.get(f"{GATEWAY}/v1/orders/42", timeout=5)
    assert r.status_code == 200
    assert r.json()["path"] == "/orders/42"

def test_header_forces_v2():
    for _ in range(50):
        r = requests.get(
            f"{GATEWAY}/v1/orders/42",
            headers={"X-Canary": "true"},
            timeout=5,
        )
        assert r.headers["X-Served-By"] == "v2"

def test_split_is_close_to_90_10():
    counts = collections.Counter()
    n = 2000
    for _ in range(n):
        r = requests.get(f"{GATEWAY}/v1/orders/42", timeout=5)
        counts[r.headers["X-Served-By"]] += 1
    v2_share = counts["v2"] / n
    assert 0.06 <= v2_share <= 0.14, counts

The tolerance on the split matters. With 2,000 requests, a true 10 percent split will vary by well under a percentage point, so a band of 6 to 14 percent catches a wrong ratio without flaking. Run these in CI against a staging gateway whenever routing config changes.

Common routing bugs

Symptom	Likely cause	What to check
404 only when the URL ends in a slash	Trailing-slash handling differs between gateways	Test the path with and without a trailing slash
The backend receives `/v1/orders/42`	The route prefix wasn't stripped	`strip_path`, `strip_listen_path`, or a rewrite rule
The backend receives `/orders/orders/42`	A stripped prefix plus a service path that repeats the segment	Compare the route path with the service or target path
The canary header is ignored	Route precedence, or the rule never matches	Send the header through a test and confirm which route wins
The split is off at low volume	Random selection needs a large sample	Measure with at least 1,000 requests
Users bounce between versions	The split is random per request, not sticky	Route by header, cookie, or a hash of the user ID
Duplicate writes appear	The gateway retried a non-idempotent call	Limit retries to idempotent methods

Roll out a canary with a rollback

A percentage split is only safe if something watches it. This sketch shows the loop: raise the weight in steps, compare the error rate with the baseline, and roll back when it worsens. Wire set_weight and error_rate to your gateway's API and your metrics.

STEPS = [1, 5, 25, 50, 100]

def promote(set_weight, error_rate, baseline, tolerance=0.005):
    for percent in STEPS:
        set_weight(percent)
        # Let traffic soak here, then compare against the baseline
        if error_rate() > baseline + tolerance:
            set_weight(0)
            raise RuntimeError(f"Rolled back at {percent}%")

Also set explicit upstream timeouts, add health checks or circuit breakers where the gateway supports them, and tag every response with the version that served it so that you can compare error rates and latency per version.

What gateways can't replace

A gateway centralizes routing, but it doesn't remove the need for good design.

Business logic belongs in services: Complex orchestration in gateway policy is hard to test, version, and debug. Keep the gateway to routing, security, and cross-cutting rules.
Authentication isn't authorization: A gateway can verify a token, but your services still decide what each caller may do.
Config drift is a real risk: Rules edited in a console and not in version control will diverge from what you reviewed. Treat gateway config as code.
Observability is your job: Without per-route metrics, logs, and traces, a bad rule looks like a flaky backend.

Gateways work best when they handle routing and policy, and you stay responsible for testing the rules, watching the traffic, and keeping the logic simple.

Final verdict

No single gateway suits every team. If you're on AWS, start with Amazon API Gateway for managed canaries. If you're on Azure, use Azure API Management and plan to build your own traffic split. If you run a large API program with governance needs, consider Apigee. If you want a simple self-hosted gateway, use KrakenD. If you need the richest route matching and can accept its licensing terms, use Kong. If you want an open-source gateway with an optional dashboard, consider Tyk.

A gateway shortens the path between a client request and the right service, but the first working route is only the beginning. Choose the gateway whose rules you can read, test in CI, and change safely when traffic and teams grow.

Frequently asked questions

What is the best API gateway for microservices?

It depends on where you run. Amazon API Gateway suits AWS, Azure API Management suits Azure, Apigee suits large governed API programs, and Kong, KrakenD, and Tyk suit self-hosted setups on Kubernetes or containers.

What is the difference between an API gateway, a reverse proxy, and an ingress controller?

A reverse proxy forwards requests to backends. An ingress controller routes external traffic into a Kubernetes cluster. An API gateway adds API-level features, such as authentication, rate limiting, transformation, and developer management. The lines blur, and several products play multiple roles.

How do I run a canary release at the gateway?

Send a small percentage of traffic to the new version and watch error rates and latency before raising it. Amazon API Gateway has canary settings on REST API stages, Kong uses weighted upstream targets, Apigee uses a weighted load balancer, and Azure API Management needs a policy expression. Use a header or cookie rule if users must stay on one version.

Is Kong still open source?

Kong's source repository is open, but the open-source distribution stopped at the 3.9 line. Starting with 3.10, Kong stopped publishing prebuilt open-source images and removed free mode, so current builds need a license. Check Kong's current terms before you adopt it.

Should I put business logic in my API gateway?

Generally no. Keep the gateway to routing, authentication, rate limiting, and transformation. Business rules in gateway policy are hard to test and tie your system to one vendor.

Struggling with 403, 429, or CAPTCHA errors while web scraping? Learn how to troubleshoot blocks, use proxies effectively, and make your scraping workflows more reliable. 🚀 Read the guide 👇

Dev Stack Hub — Wed, 28 Oct 2026 17:08:56 +0000

Dev Stack Hub

Oct 28

Debugging 403, 429 and CAPTCHA Errors with Proxies

#discuss #python #webscraping #debugging

8 min read

Debugging 403, 429 and CAPTCHA Errors with Proxies

Dev Stack Hub — Wed, 28 Oct 2026 17:05:07 +0000

Your scraper worked fine on 50 requests. At 500, it started returning 403 Forbidden. At 5,000, you're staring at 429 Too Many Requests and CAPTCHA pages with a 200 status code. Adding more proxies didn't help, or helped for ten minutes.

The mistake most developers make here is changing several things at once: new proxies, new headers, more retries. This guide gives you a repeatable way to find out why you're being blocked so that you can fix the right thing.

What we'll cover

What 403, 429, and CAPTCHA responses actually mean
A step-by-step isolation process (and a small Python probe script)
Detecting "soft blocks" that return HTTP 200
Backoff, Retry-After, and pacing done properly
Tracking proxy health so bad IPs get benched automatically
When the problem isn't the IP at all

Examples use Python and requests, with placeholder proxies from the documentation range (203.0.113.x).

What each signal usually means

Signal	What the server is telling you	Typical root cause
429 Too Many Requests	You exceeded a rate limit	Too many requests per IP, per session or per account in a time window
403 Forbidden	The server understood you and refuses	IP reputation, bot detection, missing or inconsistent headers, geo restriction
200 with a CAPTCHA page	A challenge is served instead of content	Risk score too high: IP, behavior or fingerprint looks automated
407 Proxy Authentication Required	The proxy rejected you, not the target	Wrong credentials or non-whitelisted IP

Note that 407 is not a block at all. It's your proxy configuration, and it's the first thing to rule out.

Step 1: Isolate where the block happens

Before touching your scraper, test the target with the simplest possible client. If curl through the proxy works but your script fails, the problem is in your code. If both fail, it's the IP or the target.

# Direct (no proxy)
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/products

# Through the proxy
curl -s -o /dev/null -w "%{http_code}\n" -x http://user:pass@203.0.113.10:8080 https://example.com/products

Then reproduce the comparison in Python with a small probe that varies one thing at a time:

import requests

TARGET = 'https://example.com/products'
PROXY = 'http://user:pass@203.0.113.10:8080'
PROXIES = {'http': PROXY, 'https': PROXY}

BROWSER_HEADERS = {
   'User-Agent': (
       'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 '
       '(KHTML, like Gecko) Chrome/124.0 Safari/537.36'
   ),
   'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8',
   'Accept-Language': 'en-US,en;q=0.9',
}

def probe(label, **kwargs):
   try:
       r = requests.get(TARGET, timeout=(5, 15), **kwargs)
       print(f'{label:<28} {r.status_code}  {len(r.content):>8} bytes')
   except requests.RequestException as exc:
       print(f'{label:<28} ERROR {type(exc).__name__}')

probe('direct, default headers')
probe('direct, browser headers', headers=BROWSER_HEADERS)
probe('proxy, default headers', proxies=PROXIES)
probe('proxy, browser headers', proxies=PROXIES, headers=BROWSER_HEADERS)

Read the results like a truth table:

Direct works, proxy fails: the proxy IP is the problem (reputation, type, or geo).
Default headers fail, browser headers pass: the site checks the User-Agent and friends. The default python-requests/x.y agent is an easy signal to filter.
Everything fails: the page may need JavaScript, a cookie, or a login. The proxy is not the issue.
Everything passes: your problem is volume or pacing, so move on to Step 3.

Also confirm the proxy really is being used by calling an IP-echo endpoint such as https://api.ipify.org?format=json through it. A surprising number of "proxy problems" are requests silently going out directly.

Step 2: Detect soft blocks

A response code of 200 doesn't mean you got the page. Many sites serve a CAPTCHA or an "access denied" page with a success status, and your parser then silently stores garbage. Classify every response before you trust it:

BLOCK_MARKERS = (
   'captcha',
   'unusual traffic',
   'access denied',
   'verify you are human',
   'are you a robot',
)

def classify(response):
   if response.status_code == 407:
       return 'proxy_auth'
   if response.status_code == 429:
       return 'rate_limited'
   if response.status_code in (401, 403):
       return 'blocked'

   snippet = response.text[:5000].lower()
   if any(marker in snippet for marker in BLOCK_MARKERS):
       return 'challenge'
   return 'ok'

The marker list is site-specific, so tune it to the challenge pages you actually see. A cheaper complementary check is to assert that the content you expect (a product title, a JSON key) is present, and treat its absence as a failure.

Step 3: Fix 429s with backoff and pacing

A 429 is the friendliest error you'll get, because the server is telling you exactly what to do: slow down. Many servers include a Retry-After header, either as several seconds or as an HTTP date. Honor it:

import random
import time
from datetime import datetime, timezone
from email.utils import parsedate_to_datetime

def retry_after_seconds(response, default=30):
   value = response.headers.get('Retry-After')
   if not value:
       return default
   if value.isdigit():
       return int(value)
   try:
       when = parsedate_to_datetime(value)
       return max(0, (when - datetime.now(timezone.utc)).total_seconds())
   except (TypeError, ValueError):
       return default

def polite_sleep(base=1.0, jitter=1.5):
   # randomized delay between requests, so traffic isn't perfectly periodic
   time.sleep(base + random.uniform(0, jitter))

Three principles prevent most 429s:

Limit concurrency per IP, not just overall. Ten threads on one IP is a burst. Ten threads across ten IPs is not.
Add jitter. A request every exactly 1.000 seconds looks robotic.
Use exponential backoff on repeated failures. If a 429 comes back after waiting, wait longer next time instead of retrying at the same speed.

If you're still rate-limited at a sensible pace, the limit probably applies per IP, and the fix is a larger pool rather than a faster loop.

Step 4: Track proxy health and bench bad IPs

Random rotation keeps sending traffic to IPs that are already burned. Instead, record outcomes and give failing proxies a cooldown:

import random
import time
from collections import defaultdict

class ProxyPool:
   def __init__(self, proxies, cooldown=300, max_failures=3):
       self.proxies = list(proxies)
       self.cooldown = cooldown
       self.max_failures = max_failures
       self.failures = defaultdict(int)
       self.benched_until = {}

   def get(self):
       now = time.time()
       available = [p for p in self.proxies if self.benched_until.get(p, 0) <= now]
       if not available:
           raise RuntimeError('No healthy proxies: slow down or add more IPs')
       return random.choice(available)

   def report(self, proxy, outcome):
       if outcome == 'ok':
           self.failures[proxy] = 0
           return
       self.failures[proxy] += 1
       # a 429 benches the IP immediately; other failures need a streak
       if outcome == 'rate_limited' or self.failures[proxy] >= self.max_failures:
           self.benched_until[proxy] = time.time() + self.cooldown
           self.failures[proxy] = 0

And a fetch function that ties the pieces together:

import requests

def fetch(url, pool, attempts=4):
   for _ in range(attempts):
       proxy = pool.get()
       try:
           r = requests.get(
               url,
               proxies={'http': proxy, 'https': proxy},
               headers=BROWSER_HEADERS,
               timeout=(5, 15),
           )
       except requests.RequestException:
           pool.report(proxy, 'error')
           continue

       outcome = classify(r)
       pool.report(proxy, outcome)

       if outcome == 'ok':
           return r
       if outcome == 'rate_limited':
           time.sleep(retry_after_seconds(r))
       elif outcome == 'proxy_auth':
           raise RuntimeError('Proxy credentials rejected (407). Check auth or IP whitelist.')

       polite_sleep()

   raise RuntimeError(f'Failed to fetch {url} after {attempts} attempts')

Log the outcome, proxy, and URL for every request. After a few hundred requests, you'll be able to see whether failures cluster on specific IPs (bad IPs), specific URLs (protected pages), or specific times (rate-limit windows). That pattern tells you which fix to apply.

Step 5: When it's the IP type

If your probe showed that browser-like headers pass directly but fail through the proxy, you're dealing with IP reputation. Different proxy types carry different levels of trust:

Proxy type	Trust with strict sites	Strengths	Watch out for
Datacenter / IPv6	Lower	Fast, cheap, easy to scale	Whole ranges are often flagged; shared IPs inherit other users' behavior
ISP (static residential)	Higher	Looks like a home user, stable for long sessions	Priced per IP, so pool size is limited by budget
Residential (rotating)	High	Huge pools, precise geo-targeting	Usually billed per GB; can be slower
Mobile (4G/5G)	Highest	Carrier IPs are shared by many real users, so sites are cautious about blocking them	Most expensive; speed varies

A few related checks:

Dedicated vs shared: a shared IP can be burned by someone else before you send a single request.
Geo mismatch: if your Accept-Language says en-US but your exit IP is in another country, or your IP is in Germany while you request a US-only price page, you will get blocked or served different content.
Burned static IPs: a static IP that has been hammered for days may need a rest or a replacement. Rotation isn't just for volume; it's hygiene.

Step 6: When it isn't the IP at all

If you've tried clean IPs and sensible pacing and still get 403s, look beyond the proxy:

Session and cookies: Many sites set a cookie on the first page and expect it on the next. Use a requests.Session and keep the same IP for the whole flow (a sticky session if your provider supports one).
Inconsistent headers: A Chrome User-Agent with a missing Accept-Language, or headers in an unusual order, is a signal. Keep the set realistic and consistent per session.
TLS fingerprinting: Some bot-protection systems inspect the TLS handshake itself, and Python's default stack looks different from a real browser's. If headers and IPs are fine but a site still refuses you, a real browser (Playwright or Selenium) or an HTTP client that mimics browser TLS such as curl_cffi may be the next thing to test.
JavaScript-rendered content: If the data is loaded by JavaScript, plain requests get an empty shell. Look for the JSON API call the page makes in your browser's network tab, or use a headless browser.
Behavioral signals: Hitting deep URLs with no prior navigation, or requesting pages at inhuman speed, can raise a risk score even from a perfect IP.

A word on CAPTCHAs

A CAPTCHA is not an error to defeat. It's a signal that your traffic looks risky. The most reliable strategy is to trigger fewer of them: better IP quality, lower rate, consistent sessions, realistic headers. If you're seeing them constantly, treat that as a symptom and work back through the steps above.

It's also worth asking whether you should be scraping that page at all. Check for an official API or data export first, read the site's terms of service and robots.txt, and only collect data you're permitted to use. Circumventing access controls on sites that forbid automated access can create legal problems that no proxy will solve.

Choosing proxies for testing

To follow along, you need proxies that let you compare types on the same target. I used a provider that offers datacenter, ISP, residential, and mobile IPs with both HTTP/HTTPS and SOCKS5 so that I could swap types without changing code. Disclosure: [add your affiliate or sponsorship note here if applicable]. Whichever service you use, buy a small amount of each type you're considering, run the probe script from Step 1, and compare success rate and latency on your target before committing to a larger plan.

Quick reference

407? Fix proxy auth first. It isn't a block.
Isolate: compare direct vs proxy, default vs browser headers.
Classify every response, including 200 pages that are really CAPTCHAs.
429: honor Retry-After, add jitter, limit per-IP concurrency, then grow the pool.
Bench bad IPs with a cooldown instead of rotating unquestioningly.
403 on clean IPs: check sessions, headers, TLS fingerprint, and JavaScript rendering.
Constant CAPTCHAs: reduce the triggers, and check whether an official API exists.

Got a blocking pattern that isn't covered here? Share it in the comments, and I'll add it to the guide.

Choosing an AI design-to-code tool isn't just about generating code. It's about finding the right fit for your workflow. I compared 11 tools for different use cases, from Figma-to-code to full-stack AI builders. Which tool are you using for your project?

Dev Stack Hub — Tue, 27 Oct 2026 16:09:37 +0000

Dev Stack Hub

Oct 26

I Compared 11 Best AI Design-to-Code Tools for My Client Projects

#discuss #ai #design #nocode

13 min read

I Compared 11 Best AI Design-to-Code Tools for My Client Projects

Dev Stack Hub — Mon, 26 Oct 2026 17:45:04 +0000

From Figma integrations to AI coding agents, here is how to choose the right tool for turning an approved design into a working interface.

Last reviewed: October 2026. This space changes monthly, so confirm features, supported frameworks, and pricing in each vendor's current documentation.

The hard part of a client website is rarely the first screen. The real work starts when that screen must match the approved design, work on mobile, reuse existing components, connect to real data, and stay maintainable after handoff.

AI design-to-code tools promise to speed this up, but they don't all solve the same problem. Some convert Figma layouts into frontend code. Some generate UI from text prompts. Others build whole applications or work inside your existing repository.

This guide compares 11 tools across four workflows to show where each one fits. It is an editorial comparison based on documented capabilities and practical implementation concerns, not a benchmark where every tool was run against the same repository.

The main takeaway: The best tool isn't the one that generates the most code. It's the one that gets you closest to the required result without creating more cleanup than it saves.

How the tools are compared

Comparing a Figma integration directly with a full-stack app builder can mislead, because their jobs differ. So the tools are grouped by starting point and intended output, then judged on six criteria:

Design fidelity: how well the layout, spacing, typography, colors, and responsive behavior are preserved.
Code integration: whether the output fits an existing codebase and uses the project's components.
Iteration speed: how easily a developer can change things after the first generation.
Functional completeness: whether you get only a visual interface or working application features.
Developer control: whether the team can inspect, edit, test, and maintain the generated code.
Handoff quality: whether designers and developers can keep working together without losing design intent.

The 11 tools at a glance

Tool	Category	Best for	Suits	Biggest watch-out
Figma Make	Figma-to-code	Interactive prototypes from design context	Designers	Prototype code still needs engineering review
Figma MCP Server	Design context for agents	Feeding structured Figma data to a coding agent	Developers with a design system	It supplies context; the agent writes the code
Builder.io Visual Copilot	Figma-to-code	Code aligned with an existing design system	Designers and developers	Setup and component mapping take effort
Anima	Figma-to-code	Exporting Figma layouts as React, Vue, or HTML	Designers and developers	Output may need refactoring and responsive QA
v0 by Vercel	Prompt-based UI	Polished web UI and app features	Developers, especially React teams	Output needs integration and testing
Google Stitch	Prompt-based UI	Exploring interface directions	Designers, product teams	A draft, not a production application
Banani	Prompt-based UI	Editable multi-screen prototypes with export	Designers, product teams	Logic and architecture are separate work
Bolt.new	App builder	Interactive web apps from prompts	Small teams, solo builders	Awkward fit for an existing client repository
Lovable	App builder	MVPs and early product validation	Small teams, solo builders	Backend and access rules need real review
Cursor	Coding agent	Implementing designs in an existing repository	Developers	Needs clear instructions and diff review
Claude Code	Coding agent	Multi-step implementation across a codebase	Developers	Needs clear constraints and test coverage

Scorecard against the six criteria

These ratings are my editorial judgment from documented capabilities, not measured results. "n/a" means the criterion doesn't apply because the tool doesn't start from an existing design. The agent-based rows assume good design context is supplied.

Tool	Design fidelity	Code integration	Iteration speed	Functional completeness	Developer control	Handoff quality
Figma Make	High	Medium	High	Medium	Medium	High
Figma MCP + agent	High	High	High	High	High	High
Visual Copilot	High	High	Medium	Low	Medium	Medium
Anima	High	Medium	Medium	Low	Medium	Medium
v0	n/a	Medium	High	Medium	High	Medium
Stitch	n/a	Low	High	Low	Low	Medium
Banani	n/a	Medium	High	Low	Medium	High
Bolt.new	n/a	Low	High	High	Medium	Medium
Lovable	n/a	Low	High	High	Medium	Medium
Cursor	Medium	High	High	High	High	Medium
Claude Code	Medium	High	High	High	High	Medium

Converters score well on fidelity but low on functional completeness. App builders show the reverse. Only the agent-based workflows combine fidelity, integration, and completeness, and they do it by working inside your real project.

Category 1: Figma-to-code and design system integrations

These tools fit when a designer has finished the interface and developers need to translate it without losing design decisions.

1. Figma Make

Figma Make creates working, editable code and testable prototypes from prompts and design inputs, with built-in code inspection, sharing, and publishing.

Say a client approves a dashboard design but wants to see how filters, navigation, and interactive cards behave before engineering commits. Make can turn that concept into a prototype for feedback. It also helps while the design is still changing, since the team can explore an idea without treating it as a production feature.

Watch out for: a working prototype is not a maintainable application. Authentication, permissions, error handling, validation, and integration with the client's services still need real engineering.

Verdict: the right tool for getting client sign-off on an experience. For implementation in an established repository, move to Figma MCP, Builder.io, or a coding agent.

2. Figma MCP Server

The Figma MCP Server changes how coding agents get design information. Instead of recreating a screen from a screenshot, an agent can receive structured context from Figma: selected layers, components, variables, and layout details. Figma's documentation makes it clear that the server provides context while the connected agent writes the final code, so quality depends on the context, instructions, and model.

Picture a client with a React component library, spacing tokens, and reusable form elements. A generic prompt might produce yet another button with slightly different padding. With a well-configured MCP workflow, the agent can follow the project's component conventions instead. Code Connect and clear component documentation help further where available.

Watch out for: the connection doesn't guarantee the agent picks the right components. You still need implementation rules, relevant codebase context, and verification steps.

Verdict: the strongest starting point for a team with a mature Figma design system and developers already using an agent. It connects design context to the place where implementation actually happens.

3. Builder.io (Visual Copilot)

Visual Copilot translates designs into code while accounting for existing components, tokens, and conventions. Its documentation describes support for frameworks and styling approaches including React, Vue, Angular, Tailwind CSS, and CSS Modules, with specifics depending on the workflow.

It suits projects that can't simply replace their frontend with whatever an AI tool generates. If a client already has a navigation component, product card, pricing section, and type system, rebuilding them from scratch creates differences and maintenance costs.

Watch out for: the output is only as good as your mappings. Unclear component names, missing documentation, or inconsistent codebase patterns mean you may need to fix that foundation first.

Verdict: the strongest converter to evaluate when consistency with an existing product matters as much as initial speed.

4. Anima

Anima is the more direct option when you start with a Figma file and want frontend code. Its documented workflow covers React, Vue, and HTML, with styling and component options depending on the output, plus a playground to preview and refine the code.

It works best on well-structured designs with clear layouts, where it can cut the effort of recreating pages and establishing a first responsive version.

Watch out for: exported code isn't the same as code that follows your architecture. Inspect component structure, class names, responsive behavior, accessibility, and repeated elements before merging.

Verdict: choose it when direct export is the main requirement. If reusing existing components is essential, compare its output against Builder.io and an MCP-based workflow.

Category 2: Prompt-based UI generators

These help when the team needs to explore a direction or turn a product brief into an initial interface before the final design is settled.

5. v0 by Vercel

v0 has grown beyond isolated snippets. Its documentation describes building UI, creating full-stack apps, connecting backends, and deploying through Vercel.

A useful prompt describes a customer dashboard with a sidebar, recent activity summary, filter controls, and a responsive table. The developer then refines the result instead of building every element from a blank file.

Watch out for: convincing components can still miss edge cases, loading states, error handling, and your design system's conventions. If you have custom components and tokens, name them in the prompt rather than letting v0 invent new ones.

Verdict: the best fit here for moving fast from an interface brief to editable frontend code, especially on React projects.

6. Google Stitch (formerly Galileo AI)

Stitch generates interface concepts from text and visual references, and it is the successor to Galileo AI in this space. Current descriptions emphasize web and mobile concepts and handoff through export options.

It helps when a client wants a cleaner onboarding flow but supplies only a short brief. The team can try several screen structures and visual directions before choosing one to refine.

Watch out for: an attractive draft doesn't settle interaction behavior, responsive edge cases, data handling, or architecture.

Verdict: use it early, when the open question is what the interface should look like, not as a way to deliver the finished application.

7. Banani

Banani generates editable UI designs from prompts, screenshots, and references. Documented workflows include editing generated screens, building multi-screen prototypes, exporting to Figma or HTML/CSS, and connecting designs to coding agents through MCP.

That suits a client who needs more than one landing page concept, such as a dashboard, settings page, account screen, and onboarding flow. Editing before export means the team can align on layout and hierarchy first.

Watch out for: a multi-screen prototype isn't an implemented application. Navigation, authentication, API behavior, validation, and persistence still need building.

Verdict: a good bridge between concept exploration and code. Pair it with a coding agent for production work.

Category 3: Full-Stack & App Builders (Vibe Coding)

These go beyond a design or exported markup. They aim to create working applications from prompts, making them useful for prototypes and MVPs, but reviews have to cover more than visual accuracy.

8. Bolt.new

Bolt.new lets you describe an app, generate code, preview it, and keep refining in the same workflow. The product also highlights integrated hosting, databases, and authentication.

It fits briefs that include interaction rather than a static page, such as a small booking app with a service-selection screen, a booking form, and a basic data-backed flow.

Watch out for: bundled infrastructure is convenient for a new project but pulls against an existing one. If the client already has a repository, hosting, and database, you'll spend time reconciling Bolt's setup with theirs. As the app grows, review the data structure, permissions, validation, and deployment configuration; a working preview doesn't mean it's secure.

Verdict: excellent for a fast, standalone prototype. For a client with an established codebase, check fit before starting.

9. Lovable

Lovable creates applications from natural-language instructions and suits early validation, such as a customer portal, booking workflow, or internal dashboard built to gather feedback before a larger investment.

Watch out for: the sharpest risk is the backend. If you connect a hosted database, the data-access rules, such as row-level security policies, determine who can read and write what, and a generated app can look fine while exposing data. Review authentication, authorization, secret handling, and failure states, and confirm how code ownership and export work if the project must move into the client's repository.

Verdict: a strong choice for validating a product concept quickly. Don't treat a generated MVP as production-ready until its code and security assumptions have been reviewed.

Category 4: AI coding agents

Agents don't generate a design or an app from scratch. They work inside your repository, which is why they suit most established client projects.

10. Cursor

Cursor is an AI coding environment. Its agent can inspect a codebase, edit multiple files, run terminal commands, and help debug, and Cursor documents workflows for using screenshots and Figma context to guide implementation.

Suppose a client has a working React app and wants a redesigned pricing page. Rather than generating a separate application, you ask the agent to find the relevant components, use the design context, and build the page within the current structure.

Watch out for: the agent can pick the wrong abstraction, touch unrelated files, or introduce regressions. Keep changes small, write your component and styling conventions into the project's rules, inspect the diffs, run tests, and check the result in a browser.

Verdict: a natural first choice for developers who want AI assistance inside an editor with changes visible as they happen.

11. Claude Code

Claude Code is an agentic coding tool that works through development tasks in a codebase: reading files, editing code, running commands, and connecting to external tools through supported integrations. Figma's documentation lists Claude Code among the clients that can use its MCP server.

A typical task: implement a Figma screen, reuse existing components, add validation, update the tests, and fix whatever verification turns up. That works best with a clear specification and access to the right project context.

Watch out for: it needs boundaries. State which files and conventions matter, what must not change, and what tests to run, and put standing conventions in the project's instruction file. Review the commands and file changes it proposes, especially around sensitive configuration.

Verdict: strong when the work is several connected engineering tasks rather than a single layout.

Cursor or Claude Code?

The practical difference is mostly workflow. Cursor is editor-centered, so you see and steer changes inline as you work. Claude Code is terminal-centered, which suits longer multi-step tasks you can specify up front and review afterward. Both can read your repository, use Figma context through MCP, and run tests. Many teams choose based on habit and tooling preference, and some use both. Try each on the same small task in your own repository.

Disclosure: This guide was edited with help from Claude, made by Anthropic, which also makes Claude Code. I've rated the two agents equally for that reason; judge them on your own repository.

Pricing, learning curve, and team fit.

I haven't listed prices because plans and limits change often. A few patterns hold in general:

Editor and agent tools typically use per-seat or usage-based plans. Cost scales with how much your developers lean on them.
App builders are often credit- or usage-based. Heavy iteration can burn through allowances, so budget for the number of revisions a real project needs.
Design-side tools may gate export, code, or MCP features by plan. Confirm that the feature you need is on the plan you'd buy.

On the learning curve, Figma Make, Stitch, and Banani are approachable for designers. Converters need some developer setup. App builders are quick to start but reward someone who can read and fix the code. Agents give the most control and ask the most of the developer.

Which should you choose?

If your priority is...	Shortlist	Why
An interactive prototype for client sign-off	Figma Make	Shows behavior before engineering commits
Design context inside a real codebase	Figma MCP Server + Cursor or Claude Code	Connects the approved design to repository-level coding
Code that matches an existing design system	Builder.io Visual Copilot	Maps designs to your components and tokens
Direct Figma export	Anima	Fast path to editable React, Vue, or HTML
Prompt-generated, polished UI	v0	Quick iteration on component-driven interfaces
Exploring visual directions	Stitch or Banani	Cheap to generate and compare concepts
A functional prototype or MVP	Bolt.new or Lovable	Includes application behavior
Implementing in an existing project	Cursor or Claude Code	Works with your files, components, and tests

If the client has approved Figma designs and an existing codebase, start with the Figma MCP Server connected to Cursor or Claude Code. It isn't one-click, but it gives the agent real design context while keeping it inside your actual components. If the client has only an idea, try v0, Stitch, or Banani first. If the goal is a working MVP with several flows, compare Bolt.new and Lovable on the same brief.

What to check before handing code to a client

Treat AI-generated code as a starting point. Whatever tool produced it, run the same checks.

Design fidelity: Compare the build with the approved design at the same viewport size. Check typography, spacing, alignment, image cropping, button sizes, and hierarchy.
Responsive behavior: Test several widths, including narrow phones. Confirm navigation collapses, cards reflow, forms stay usable, and long content doesn't overflow.
Functionality: Click buttons, submit forms, open menus, trigger validation, and inspect loading and error states. A screenshot can't tell you whether the interface works.
Component reuse: Confirm the build uses your design system's buttons, inputs, cards, and layout primitives instead of new variants.
Accessibility: Test keyboard navigation, focus indicators, heading structure, form labels, and color contrast. Give meaningful images and charts text alternatives.
Maintainability and security: Review code structure, dependencies, API usage, environment variables, and data handling. Never expose secrets in frontend code, and never assume generated auth rules are correct.
Client handoff: Deliver the code, setup instructions, required environment variables, known limitations, and deployment steps. A clean handoff is part of the deliverable.

Final thoughts

These tools don't compete head-to-head. Figma Make turns design ideas into prototypes. The Figma MCP Server feeds design context to coding agents. Visual Copilot and Anima translate existing designs into frontend code. v0, Stitch, and Banani generate and refine interfaces; Bolt.new and Lovable build whole applications. Cursor and Claude Code make changes inside an existing repository.

For most client projects, my shortlist is the Figma MCP Server with a coding agent for existing codebases, v0 for prompt-driven UI, and Lovable or Bolt.new for functional MVPs. Pick based on your starting point and expected deliverable, then verify with visual comparison, responsive testing, functional checks, and code review.

The real time-saver isn't the first generated screen. It's choosing the workflow that minimizes the work between that screen and code the client can confidently maintain.

Frequently asked questions

What is the best AI design-to-code tool?

It depends on your starting point: Builder.io Visual Copilot and Anima suit converting finished Figma designs into frontend code. The Figma MCP Server connects designs to coding agents, v0 suits prompt-driven UI work, and Lovable or Bolt.new suit functional application prototypes.

Can AI convert a Figma design into production-ready code?

It can generate code from a design, but production readiness is never guaranteed. Developers still need to review layout fidelity, responsive behavior, component reuse, accessibility, security, error handling, and maintainability.

What is the difference between Figma MCP Server and Figma Make?

The MCP Server provides structured design context to external AI agents that write or modify code. Figma Make creates and refines code-backed prototypes inside Figma's own workflow. One feeds your existing development tools; the other is an integrated design-and-prototyping experience.

Are AI app builders better than Figma-to-code tools?

Not necessarily. Figma-to-code tools are better at translating approved visual designs into frontend code. App builders are better when the task also involves application structure, backend integration, and data flows. Choose based on whether design fidelity or rapid application development matters more.

How do I test AI-generated frontend code before client delivery?

Compare the rendered interface to the approved design, test responsive layouts at several widths, verify every interaction and form, check accessibility, and run the project's build and test commands. Also review component reuse, dependencies, API calls, and sensitive-data handling before deploying or handing over the code.

Confused about AI governance frameworks? I compared NIST, ISO 42001, the EU AI Act, and more to help you understand their differences, requirements, and use cases. Explore which framework fits your organization! 🚀

Dev Stack Hub — Mon, 26 Oct 2026 16:54:11 +0000

Dev Stack Hub

Oct 22

AI Governance Frameworks: NIST, ISO, EU AI Act & More Compared

#discuss #ai #security #devdiscuss

12 min read

Exploring Respan Gateway 🚀 Discover how its plugin-first architecture approaches LLM routing, fallbacks, and MCP tools. I explored its features and limitations for developers building AI applications. Read my findings!

Dev Stack Hub — Mon, 26 Oct 2026 16:33:09 +0000

Born from a 100k-line legacy code nightmare

Dev Stack Hub

Oct 21

I Explored Respan Gateway: A Plugin-First, Open-Source LLM Gateway

#discuss #ai #llm #opensource

8 min read

AI Governance Frameworks: NIST, ISO, EU AI Act & More Compared

Dev Stack Hub — Thu, 22 Oct 2026 17:58:34 +0000

Artificial intelligence is becoming part of everyday business operations, from customer support chatbots and recruitment systems to fraud detection and generative AI tools.

But as organizations adopt AI, a difficult question follows: how do you make sure these systems are safe, fair, transparent, and accountable without slowing innovation? That is where AI governance frameworks come in. Frameworks such as the NIST AI Risk Management Framework, ISO/IEC 42001, and the EU AI Act help organizations understand AI risks, establish accountability, and manage compliance.

However, they serve different purposes. Some provide practical risk management guidance, others establish auditable management systems, and some introduce legally binding requirements. Understanding these differences is the first step toward building an AI governance strategy that works in the real world.

What Are AI Governance Frameworks?

AI governance frameworks are structured guidelines, standards, or legal requirements that help organizations develop, deploy, monitor, and manage artificial intelligence responsibly.

They establish how organizations should make AI decisions, who is accountable, what risks to evaluate, and how to respond when an AI system produces harmful or unreliable results.

A practical AI governance framework may cover:

Risk management: Identifying potential harm before and after deployment.
Data governance: Managing data quality, privacy, security, and access.
Transparency: Documenting how AI systems work and communicate their limitations.
Accountability: Assigning clear responsibilities for AI-related decisions.
Human oversight: Defining when people must review or override AI outputs.
Monitoring: Evaluating system performance, reliability, and emerging risks.
Compliance: Meeting applicable legal, regulatory, and contractual obligations.

For example, a company using AI to screen job applications needs more than a model that produces quick results. It must consider discrimination, data protection, explainability, human review, and the consequences of incorrect decisions.

AI governance provides a structure for addressing these concerns before they become expensive operational, legal, or reputational problems.

The key distinction: an AI governance framework is not necessarily a law. Some frameworks are voluntary guidance, some are certifiable standards, and others are enforceable legislation.

Top AI Governance Frameworks Compared

Organizations do not have to choose a single framework and ignore the rest. In many cases, the most practical approach is to combine a risk management framework, a formal management standard, and the legal requirements that apply to the business.

The following are the major frameworks and related governance instruments worth understanding.

1. NIST AI Risk Management Framework (AI RMF)

The NIST AI Risk Management Framework is a voluntary framework developed by the US National Institute of Standards and Technology. Published in January 2023, AI RMF 1.0 helps organizations identify, assess, and manage risks throughout the AI lifecycle. NIST also provides a companion profile for generative AI.

Its central structure consists of four functions:

Govern: Establish policies, accountability, leadership responsibilities, and an organizational culture for managing AI risk.
Map: Understand the system's purpose, context, intended users, and potential impacts.
Measure: Evaluate risks through testing, analysis, assessment, and ongoing monitoring.
Manage: Prioritize risks and decide how to mitigate, monitor, transfer, or accept them.

Consider a business deploying an AI customer support assistant. The Govern function establishes who owns the system. Map identifies the users, data, and situations in which the assistant may fail. Measure evaluates incorrect answers, privacy risks, and reliability. Manage establishes escalation rules, monitoring, and corrective actions.

Best for: Organizations that need a practical, adaptable process for managing AI risk.
Main advantage: It provides a clear structure without requiring an organization to adopt a particular technology or purchase a certification.
Limitation: NIST AI RMF is not a certification standard and does not, by itself, demonstrate compliance with every applicable law.

For many teams, NIST is a sensible starting point because its functions can be adapted to different business sizes, industries, and AI use cases.

2. ISO/IEC 42001: AI Management System Standard

ISO/IEC 42001 is an international standard published in 2023 that specifies requirements for establishing, implementing, maintaining, and continually improving an artificial intelligence management system, commonly called an AIMS.

Unlike a framework that primarily guides risk assessment, ISO/IEC 42001 focuses on how an organization systematically manages AI.

It encourages businesses to establish an AI policy, define responsibilities, assess risks and impacts, document relevant processes, evaluate performance, and improve controls over time.

For example, a software company developing AI-powered analytics could use ISO/IEC 42001 to formalize how it approves models, reviews risks, documents changes, and evaluates the effectiveness of its governance program.

Best for: Enterprises, AI vendors, SaaS providers, and organizations seeking a structured, auditable AI management system.
Main advantage: Organizations can pursue third-party certification through an appropriate certification process, giving customers and business partners evidence that an AI management system has been independently assessed.
Limitation: Implementing and maintaining the system requires documentation, resources, internal ownership, and audit preparation. Certification does not automatically establish compliance with every AI-related regulation.

ISO/IEC 42001 is particularly relevant when customers ask how you manage AI risks, who approves AI deployments, and whether you independently assess governance practices.

3. EU AI Act

The EU AI Act differs from NIST and ISO/IEC 42001 because it is legislation, not voluntary guidance.

Adopted as Regulation (EU) 2024/1689, it establishes legally binding requirements for covered AI systems and models, with obligations depending on the system's risk classification, the organization's role, and other factors. Its scope can affect organizations outside the EU when their activities fall within the regulation's reach.

The Act takes a risk-based approach. Broadly, it distinguishes between prohibited AI practices, high-risk systems, systems subject to specific transparency obligations, and other AI uses that may face fewer requirements under this legislation.

Examples of areas requiring careful assessment include certain employment-related AI systems, education, access to essential services, and biometric applications.

The exact obligations depend on the system and the relevant provisions. Organizations may need to address risk management, data governance, technical documentation, record-keeping, human oversight, accuracy, robustness, transparency, or conformity assessment.

Best for: Organizations developing, supplying, importing, distributing, or deploying AI within the regulation's scope.
Main advantage: It establishes enforceable legal requirements rather than relying solely on voluntary commitments.
Limitation: Compliance can be complex because obligations vary by AI category, organizational role, and applicable implementation dates.

Businesses should not assume that ISO certification or alignment with NIST automatically satisfies the EU AI Act. They need a separate assessment of the legal obligations that apply to their systems.

4. OECD AI Principles

The OECD AI Principles provide a high-level foundation for trustworthy AI policy and governance.

They promote AI systems that respect human rights and democratic values, support transparency and explainability, remain robust and secure, and have clear accountability.

Unlike the EU AI Act, the OECD principles are not themselves a directly enforceable AI compliance regime. Their value lies in providing shared principles that governments, businesses, and other institutions can translate into policies and practices.

For example, an organization can use these principles to develop internal rules for responsible AI use, communicate its expectations to suppliers, and evaluate the broader social effects of its AI products.

Best for: Organizations building responsible AI policies, ethical principles, and high-level governance commitments.
Main advantage: The principles provide a broad foundation that can complement technical risk controls and legal compliance programs.
Limitation: They do not provide a complete operational control framework or a certification mechanism.

5. ISO/IEC 23894: AI Risk Management Guidance

ISO/IEC 23894 guides the management of AI-related risks.

It is useful for organizations that need to incorporate AI-specific considerations into their wider enterprise risk management processes. These considerations can include uncertain model behavior, data limitations, changing operating conditions, and unintended consequences.

For example, a financial services company introducing an AI forecasting system can use risk management guidance to identify failure scenarios, assess their potential impact, assign mitigation measures, and monitor residual risk.

Best for: Risk managers, compliance teams, AI developers, and organizations integrating AI risk into existing enterprise risk processes.
Main advantage: It provides AI-focused risk management guidance that can complement broader standards and governance systems.
Limitation: It is guidance rather than a standalone AI management system certification standard or a substitute for applicable legal obligations.

6. ISO/IEC 27001: Information Security Management

ISO/IEC 27001 is an information security management standard, not an AI-specific governance framework. Nevertheless, it can play an important supporting role.

AI systems depend on data, infrastructure, access controls, software, and external services. Weaknesses in any of these areas can expose sensitive information or allow unauthorized manipulation.

An organization using AI may therefore need security controls for training datasets, model access, credentials, deployment pipelines, logging, and third-party integrations.

Best for: Organizations that need to integrate AI governance with information security and data protection practices.
Main advantage: It provides a structured approach to managing information security risks across the organization.
Limitation: Information security controls alone do not address every AI-specific concern, including algorithmic discrimination, explainability, or broader societal impacts.

ISO/IEC 27001 and ISO/IEC 42001 can complement each other, but they address different management objectives.

7. OWASP Top 10 for LLM Applications

The OWASP Top 10 for LLM Applications focuses on security risks in applications built with large language models.

It is especially relevant to organizations deploying AI assistants, retrieval-augmented generation systems, AI agents, and applications that connect language models to business data or external tools.

Relevant security concerns include prompt injection, sensitive information disclosure, improper output handling, excessive agency, and weaknesses in the way an application manages model inputs and outputs.

For example, test an AI assistant connected to an internal knowledge base to determine whether a malicious prompt could expose information the requesting user is not authorized to access.

Best for: AI engineers, application security teams, and organizations deploying LLM-powered applications.
Main advantage: It translates AI application security concerns into practical testing and mitigation areas.
Limitation: It is not a complete organizational governance framework and does not replace a broader risk management or compliance program.

OWASP is most effective as a technical security resource within a broader governance approach.

AI Governance Frameworks Comparison Table

Here is a quick comparison of the seven frameworks and standards, based on their primary purpose rather than treating them as interchangeable alternatives.

Framework	Type	Primary Focus	Certification
NIST AI RMF	Voluntary framework	AI risk management	No
ISO/IEC 42001	International standard	AI management system	Yes
EU AI Act	Binding legislation	Legal AI requirements	No general organizational certification
OECD AI Principles	International principles	Responsible AI values	No
ISO/IEC 23894	Risk management guidance	AI-specific risks	Not a standalone certification standard
ISO/IEC 27001	International standard	Information security	Yes
OWASP Top 10 for LLM Applications	Security guidance	LLM application risks	No

These instruments address different needs. ISO/IEC 42001 offers a certifiable management system, NIST provides a risk management structure, and the EU AI Act establishes legal obligations for covered systems.

How to Choose the Right AI Governance Framework

The best starting point depends on your organization’s size, industry, AI use cases, customer expectations, and regulatory exposure.

For startups and small businesses

Start with NIST AI RMF principles to establish basic AI policies, inventory your systems, identify risks, and assign accountability. You can introduce more formal controls as your AI usage grows.

For enterprises seeking independent assurance

Consider ISO/IEC 42001 if you need a documented AI management system and want the option of independent certification. This can be useful when enterprise customers evaluate supplier governance.

For businesses serving EU customers

Start by determining whether the EU AI Act applies to your organization and each relevant AI system. Identify your role, risk classification, applicable obligations, and deadlines before deciding which additional controls are needed.

For teams building generative AI applications

Combine an organization-wide governance approach with technical security guidance such as OWASP's LLM resources. Pay particular attention to sensitive data, prompt injection, access permissions, output validation, and human review.

How to Implement an AI Governance Framework

Choosing a framework is only the beginning. The real challenge is turning its recommendations into repeatable processes that teams actually follow.

A practical implementation plan can be broken into six steps.

Step 1: Create an AI System Inventory

Identify every AI system used, developed, purchased, or embedded in business processes.

Record the system's purpose, owner, vendor, data sources, users, business impact, and deployment status. Include third-party AI tools and employee use of generative AI where relevant.

Without an inventory, it is difficult to assess risk or determine which requirements apply.

Step 2: Assess AI Risks and Impacts

Evaluate what could go wrong and who could be affected.

Consider inaccurate outputs, discrimination, privacy violations, cybersecurity threats, unreliable decisions, intellectual property concerns, and excessive dependence on automated recommendations.

Risk assessments should consider both the likelihood of an issue and the severity of its consequences.

Step 3: Define Roles and Responsibilities

Decide who approves AI use cases, performs risk assessments, monitors performance, and responds to incidents.

Depending on the organization, these responsibilities may involve legal, compliance, security, engineering, product, HR, and senior leadership teams.

A governance policy is ineffective if nobody is responsible for enforcing it.

Step 4: Establish Policies and Controls

Develop clear rules for AI development, procurement, deployment, and ongoing use.

For example, employees may need approval before entering confidential information into external AI tools. High-impact AI applications may require additional testing, documented approval, and human oversight.

Controls should reflect the actual risks rather than imposing the same process on every AI use case.

Step 5: Monitor Systems After Deployment

AI governance does not end when a model passes its initial evaluation.

Monitor accuracy, reliability, security, unexpected behavior, user complaints, and performance changes. Define escalation procedures and set clear triggers for when a system must be corrected, restricted, or withdrawn.

Generative AI applications also require attention to changing model behavior, retrieval sources, prompts, and connected tools.

Step 6: Document Evidence and Improve Continuously

Maintain records of risk assessments, approvals, test results, policies, incidents, corrective actions, and monitoring activities.

Review these records regularly and update controls when business requirements, AI capabilities, or applicable regulations change.

This evidence supports internal accountability and can also help with external audits, customer assessments, and regulatory inquiries.

Can Organizations Use Multiple AI Governance Frameworks Together?

Yes. Using multiple frameworks is often more practical than relying on one instrument to cover every governance requirement.

For example, a company might use NIST AI RMF to structure risk assessments, ISO/IEC 42001 to organize its management system, ISO/IEC 27001 to support information security, and the EU AI Act to identify legally required controls.

The important part is to map overlapping requirements rather than build separate processes for each framework.

A single risk register, AI inventory, control library, and evidence repository can support several frameworks, as long as the records meet each relevant requirement.

However, overlapping controls do not automatically satisfy every requirement. The organization must still document gaps and verify that the controls meet the applicable standard or law.

Common AI Governance Mistakes to Avoid

Even well-intentioned organizations can struggle to turn governance principles into effective practices.

Treating every framework as a law: NIST and OECD guidance are not equivalent to binding legislation.
Assuming certification guarantees legal compliance: An ISO/IEC 42001 certificate does not automatically satisfy every regulatory obligation.
Focusing only on model accuracy: Privacy, security, fairness, transparency, and human impact matter too.
Creating policies without assigning owners: Every important control needs a responsible person or team.
Ignoring third-party AI: External models and embedded AI features can introduce risks even when an organization did not develop them.
Treating governance as a one-time project: AI systems and their operating environments change, so governance must evolve with them.

The goal is not to produce the largest collection of policies. It is to build a system that helps people make informed decisions, manage risks, and demonstrate accountability.

Conclusion

AI governance frameworks help organizations adopt artificial intelligence with clearer responsibilities, better risk controls, and greater accountability. However, NIST AI RMF, ISO/IEC 42001, the EU AI Act, OECD AI Principles, ISO/IEC 23894, ISO/IEC 27001, and OWASP's LLM security guidance are not direct substitutes for one another.

NIST AI RMF is a practical starting point for managing AI risk, ISO/IEC 42001 provides a structured and certifiable AI management system, and the EU AI Act establishes legal requirements for AI activities within its scope. The remaining instruments can strengthen ethical decision-making, information security, risk assessment, and application-level protection.

For most organizations, the sensible approach is to identify applicable legal obligations first, establish a consistent governance process, and map relevant standards and guidance into that process. This creates a more manageable way to support innovation while keeping AI risks visible, measurable, and accountable.

Frequently Asked Questions (FAQs)

1. What are the main AI governance frameworks?

The main AI governance frameworks and related instruments include the NIST AI Risk Management Framework, ISO/IEC 42001, the EU AI Act, and the OECD AI Principles. ISO/IEC 23894, ISO/IEC 27001, and OWASP's LLM security guidance provide additional risk management and technical security support.

2. What is the difference between NIST AI RMF and ISO 42001?

NIST AI RMF provides voluntary guidance for identifying, measuring, and managing AI risks through its Govern, Map, Measure, and Manage functions. ISO/IEC 42001 specifies requirements for an AI management system that organizations can implement and pursue third-party certification against.

3. Is the EU AI Act mandatory for all companies using AI?

No. The EU AI Act applies according to its scope, the AI system involved, and the organization's role. Certain obligations may affect organizations outside the EU, but businesses must assess their specific activities and applicable requirements rather than assume that every AI use is subject to identical rules.

4. Can ISO 42001 certification replace EU AI Act compliance?

No. ISO/IEC 42001 certification demonstrates that an organization's AI management system has been assessed against the standard. It does not automatically establish compliance with the EU AI Act, which may impose additional system-specific legal requirements.

5. How can a company choose the right AI governance framework?

A company should begin by identifying its AI systems, applicable legal obligations, risk exposure, industry requirements, and customer expectations. NIST AI RMF can help structure risk management, ISO/IEC 42001 can formalize governance, and relevant laws and technical standards can supply additional requirements.

🚀 Exploring Respan Gateway, an open-source LLM gateway with a plugin-first architecture for model routing, fallbacks, and MCP tools. An interesting project for AI developers to explore!

Dev Stack Hub — Wed, 21 Oct 2026 17:58:49 +0000

Born from a 100k-line legacy code nightmare

Dev Stack Hub

Oct 21

I Explored Respan Gateway: A Plugin-First, Open-Source LLM Gateway

#discuss #ai #llm #opensource

8 min read

I Explored Respan Gateway: A Plugin-First, Open-Source LLM Gateway

Dev Stack Hub — Wed, 21 Oct 2026 17:39:05 +0000

Every time I connect an application to a new LLM provider, I run into the same problem: how much provider-specific code do I have to add? One SDK expects one request format, another provider uses a different API, and switching models can mean changing far more than a model name. Then come retries, fallback logic, usage tracking, and debugging when a request fails.

Most gateways answer this with the same pitch: one endpoint, many providers. Respan Gateway is more interesting for how it’s built than for that pitch. It is an open-source Rust gateway with a very small core, where nearly everything, including the providers, is a plugin. I went through the documentation and the launch post to see what that design means for a developer and what I’d check before relying on it.

One caveat first: the project describes itself as pre-alpha, and its config and APIs may still change.

Why the Architecture Is the Interesting Part

Respan says it ran its hosted gateway on LiteLLM since 2024. As customers needed different API-key settings, routes, and limits, its wrapper code grew to more than 100,000 lines. Then, this January, a routine LiteLLM upgrade caused intermittent connection errors and forced a rollback. Respan says it never found the cause and now backports upstream fixes by hand. That is the company’s own account, and I haven’t tested LiteLLM myself. It does explain the design goal: add features without breaking existing ones.

The result is a small core inspired by Nginx, responsible only for dispatching events. Providers, protocols (chat, real-time voice, MCP), modalities (images, video), and gateway features like routing and fallbacks are all plugins. A provider is a short file. Respan cites Mistral’s at 22 lines, and provider quirks, such as Groq reporting token usage in its own field, are separate plugins with their own tests.

Here is how a request moves through it:

A client adapter hands each HTTP or WebSocket connection to the first client format that recognizes it.
That format exposes the request as a two-way stream of typed events.
Plugins run in registration order. They can choose a provider, filter either stream, make extra calls, return a response, or refuse the request.
A provider format opens the upstream connection.

When client and provider speak the same API, and no plugin changes the payload, the original bytes and provider-specific fields pass through untouched. When the formats differ, requests translate through shared types for messages, tool calls, results, streams, and usage.

The trade-off: plugins are natively compiled Rust crates, not dynamically loaded or interpreted. Config-only template plugins cover common needs like adding a vendor or format without a rebuild. Custom logic means compiling it in. In the Hacker News launch thread, a commenter pointed out that this means a CI step instead of pulling a container image, and raised supply-chain concerns. Respan replied that compiled-in crates can at least be reviewed, and said it pulled its Docker image before launch because some APIs may still change. Official builds are prebuilt binaries on GitHub Releases.

Installing and Making a First Request

Respan Gateway can be installed in three ways: by downloading a binary from GitHub Releases, using Cargo, or installing the Python package from PyPI. Linux x86_64 is shown here (macOS, arm64, and Windows builds are also available), using the version shown in the release:

VERSION=v0.1.0
curl -fsSL "https://github.com/respanai/respan-gateway/releases/download/$VERSION/respan-gateway-$VERSION-x86_64-unknown-linux-gnu.tar.gz" | tar xz
sudo mv "respan-gateway-$VERSION-x86_64-unknown-linux-gnu/respan-gateway" /usr/local/bin/

Alternatively, install it with Cargo:

cargo install --git https://github.com/respanai/respan-gateway respan-gateway

Or install the Python package from PyPI:

pip install respan-gateway

A source build has no web UI unless you build it first. Check the current release before copying the version number.

With no config file, every provider key in your environment becomes a provider:

export OPENAI_API_KEY="sk-..."
export ANTHROPIC_API_KEY="sk-ant-..."
export GEMINI_API_KEY="..."
respan-gateway

export OPENAI_API_KEY="sk-..."
export ANTHROPIC_API_KEY="sk-ant-..."
export GEMINI_API_KEY="..."
respan-gateway

The gateway prints the providers it found, the endpoints it serves, and a request to try. The model name in each request decides where it goes, and a prefix like openai/gpt-5.5 forces a provider. The docs’ curl example sends a request in OpenAI format to Gemini:

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "gemini-3.6-flash", "messages": [{"role": "user", "content": "Hello!"}]}'

The same idea works from an SDK. Here, the OpenAI client talks to Claude:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8080/v1", api_key="unused")
response = client.chat.completions.create(
    model="claude-sonnet-4-5-20250929",
    messages=[{"role": "user", "content": "Hello!"}],
)
print(response.choices[0].message.content)

With no client keys configured, the gateway answers only on your own machine.

The documentation describes the startup output and request log available at /ui/requests. I have not included a screenshot or claimed a local test result here.

One File: gateway.toml

Everything beyond relaying a request is configured in one gateway.toml. respan-gateway init writes a commented starter from the keys in your environment. This block is adapted from the configure docs:

client_keys = ["env:GATEWAY_KEY"]

[providers.openai]
vendor = "openai"
key = "env:OPENAI_API_KEY"

[providers.anthropic]
vendor = "anthropic"
key = "env:ANTHROPIC_API_KEY"

[providers.gemini]
vendor = "gemini"
key = "env:GEMINI_API_KEY"

[routes.cheap-and-good]
to = ["openai/gpt-5.5", "anthropic/claude-sonnet-4-5-20250929", "gemini/gemini-3.6-flash"]
pick = "cheapest"
needs = ["tools"]
tries = 2

[routes.fast]
to = ["anthropic/claude-sonnet-4-5-20250929", "openai/gpt-5.5"]
hedge = "800ms"

A client asks for cheap-and-good as if it were a model name. These are the documented behaviors that matter:

pick sets the order candidates are tried in: first, cheapest (input price plus three times output price), fastest, weighted, or random.
needs filters candidates to models that list capabilities like tools, reasoning, vision, or pdf.
Fallback is on by default, so a failed candidate falls through to the next.
tries allows 1 to 10 attempts per candidate. Backoff starts at 250ms, doubles each time, and caps at 10s.
hedge races the candidates instead. Each starts after the delay, and the first answer wins.

Fallback models may differ in context length, tool support, or quality. Retries can waste tokens and add latency. Hedging deliberately sends more than one upstream request, which can increase cost.

Run respan-gateway check before starting (--online also calls each provider and MCP server). You can reload without a restart by sending SIGHUP, starting with --watch, or using the web UI. An invalid file is refused while the old config keeps serving. To see where a model would go and why, open /ui/api/routes/explain?model=cheap-and-good.

Before deployment, run respan-gateway check and inspect /ui/api/routes/explain?model=cheap-and-good to confirm the configuration and routing behavior in your environment.

For a failure test, configure an invalid key or unreachable provider as the first candidate, send a request, and inspect the request log to verify the actual retry and fallback behavior.

What It Can Proxy

The documented scope is chat, images, speech (including transcription), video, and real-time voice. The docs give examples like the Anthropic SDK calling a GPT model, and an OpenAI Realtime client talking to Gemini Live. It handles tools, images, streaming, and reasoning parameters across formats. Embeddings aren’t on that list, so retrieval pipelines will still need a separate path.

Sixteen providers are built in, including OpenAI, Anthropic, Gemini, Groq, DeepSeek, Mistral, xAI, OpenRouter, and Ollama. Any other OpenAI-, Anthropic-, or Gemini-style endpoint works with a base_url. Translation has limits, and Respan itself says not every feature carries over between providers. Test the exact models and parameters you use.

MCP Tools Behind the Gateway

Each [mcp.NAME] block puts an MCP server behind the gateway, with its credentials staying on the gateway. The tool_loop plugin lets any chat model use those tools mid-request. The gateway runs the tool, feeds the result back, and returns only the final answer, so the client needs no MCP support.

This is powerful and worth treating carefully. By default, any client key can make the model call any tool you offer, using the server’s credentials. Use deny lists for destructive tools, and per-key tools globs to limit what each client can reach.

Request Logs and Tracing

The web UI shows each request’s provider, latency, tokens, and cost. By default, it keeps the last 1,000 requests in memory. The request_log plugin can also append each finished request to a JSONL file, without bodies or keys.

The optional respan plugin sends each request to Respan as a trace. Its content setting defaults to true, meaning messages and replies are sent if your prompts contain sensitive data; set content = false to send metadata only.

Where It Fits

LiteLLM is the established self-hosted option, and Respan’s own history is built on it. A newer pre-alpha project can’t match its track record, and Respan’s pitch is mainly about extensibility.
OpenRouter is a hosted router with one API and one bill. It isn’t a competitor in the self-hosted sense, since it’s one of the gateway’s built-in vendors and you can route to it from here.
Respan’s hosted platform runs the gateway for you, adds observability and evals, and bills centrally. That is how the company makes money. The open-source binary is the self-run version, and you can combine them by adding a Respan key as a provider.

I’ve kept these comparisons to differences I could support. Check each project’s current docs before relying on them.

Before Using It in Production

Because it’s pre-alpha, I’d treat this as a proof of concept rather than a critical dependency for now. My checklist:

Stability: Expect config and API changes. Pin versions and read release notes.
Provider compatibility: Test streaming, tool calls, structured output, images, and any provider-specific parameters your feature uses.
Failure behavior: Simulate rate limits, timeouts, and bad keys. Confirm what retries, what falls back, and what happens when every candidate fails.
Latency: Measure end-to-end with and without the gateway, including time to first token.
Deployment: There’s no official Docker image right now, and custom plugins mean a rebuild. Plan for how you’ll build and ship it.
Security: Set client_keys before exposing it beyond localhost (it refuses to start on a public address without them). Review the auth code you depend on. A commenter on the launch thread questioned the project’s MCP OAuth implementation, and Respan said it used Claude to generate code but reviewed every line.
State: Conversation state for translated Responses API clients lives in one gateway’s memory, so multi-instance setups need clients pinned to the right instance.
Privacy: Decide what the request log and the respan plugin may record.

Verdict

Respan Gateway is worth a look if you want a small, extensible gateway with swappable providers and features as plugins, and you’re comfortable with compiled Rust extensions. It’s less suited to teams that need a drop-in container and a stable API today. Run it against your own models, break it on purpose, and then decide.

To explore it yourself, start with the GitHub repository, then the open-source gateway introduction and quickstart. For how it relates to the hosted offering, see the Respan AI Gateway overview.

Frequently Asked Questions

What is Respan Gateway?

An open-source Rust LLM gateway with a small core in which providers, protocols, and features are plugins. It translates between API formats and supports routing, retries, fallbacks, MCP tools, and a request log.

Is it open source?

Yes, under your choice of MIT or Apache-2.0. Confirm against the repository’s license files.

How do I install it?

Respan Gateway can be installed by downloading a binary from GitHub Releases, using cargo install --git https://github.com/respanai/respan-gateway respan-gateway, or installing the Python package from PyPI with pip install respan-gateway.

What does it support?

Chat, images, speech, video, and real-time voice across OpenAI, Anthropic, Gemini, and other providers, plus MCP tools. Embeddings aren’t supported.

Is it production-ready?

The project calls itself pre-alpha. Validate compatibility, failure handling, security, and deployment before relying on it.