DEV Community: Preecha

What Is the Model Context Protocol (MCP) and Why Does It Matter for APIs?

Preecha — Sat, 29 Aug 2026 14:01:24 +0000

TL;DR

Model Context Protocol (MCP) is a standard for connecting AI assistants to external data sources and APIs. It lets Claude Desktop, Cursor, and other AI tools access your API securely. Modern PetstoreAPI implements MCP so AI assistants can search pets, place orders, and manage inventory through natural language.

Try Apidog today

Introduction

Imagine asking Claude Desktop:

Show me available cats under $300.

Without API access, Claude might respond that it cannot access your pet store data. You would then need to query the API manually and paste the results into the conversation.

With MCP, Claude can call your API through an MCP server. The same request becomes an automated workflow:

Claude identifies the required tool.
It calls search_pets with the appropriate filters.
The MCP server queries PetstoreAPI.
Claude formats the response for the user.

Modern PetstoreAPI implements MCP, allowing AI assistants to interact with the pet store through natural language.

If you’re building APIs for AI integration, Apidog helps you test MCP implementations and validate AI assistant interactions.

What Is MCP?

MCP is a protocol created by Anthropic for connecting AI assistants to external resources and tools.

The Problem MCP Solves

AI assistants are powerful but isolated. Without an integration layer, they cannot:

Access your company’s internal APIs
Query your database
Read files from your filesystem
Interact with external services

MCP provides a standard way for AI assistants to connect to these resources while keeping authentication and API access in the MCP server.

MCP Components

MCP server — Exposes resources and tools to AI assistants.
MCP client — The AI assistant, such as Claude Desktop or Cursor.
Resources — Data the AI can read, including files, database records, and API responses.
Tools — Actions the AI can perform, such as creating an order, updating a pet, or searching inventory.

MCP Architecture

AI Assistant (Claude Desktop)
    ↓ MCP Protocol
MCP Server (PetstoreAPI MCP Server)
    ↓ Internal APIs
PetstoreAPI Backend
    ↓
Database

How MCP Works

An MCP integration typically follows three steps:

Register the MCP server with the AI client.
Expose the available tools and their input schemas.
Execute a tool when the assistant determines that it is needed.

1. Register the MCP Server

For example, configure Claude Desktop to start a local MCP server:

{
  "mcpServers": {
    "petstore": {
      "command": "node",
      "args": ["/path/to/petstore-mcp-server.js"],
      "env": {
        "PETSTORE_API_KEY": "your-api-key"
      }
    }
  }
}

The configuration tells the client:

Which command starts the server
Where the server entry point is located
Which environment variables the server needs

Keep credentials in environment variables rather than hard-coding them in the server source.

2. Expose Tools and Schemas

The AI client can discover the tools exposed by the server:

{
  "tools": [
    {
      "name": "search_pets",
      "description": "Search for pets by species, status, and price",
      "inputSchema": {
        "type": "object",
        "properties": {
          "species": {
            "type": "string",
            "enum": ["CAT", "DOG"]
          },
          "maxPrice": {
            "type": "number"
          },
          "status": {
            "type": "string",
            "enum": ["AVAILABLE", "ADOPTED"]
          }
        }
      }
    },
    {
      "name": "create_order",
      "description": "Place an order for a pet",
      "inputSchema": {
        "type": "object",
        "properties": {
          "petId": {
            "type": "string"
          },
          "userId": {
            "type": "string"
          }
        },
        "required": ["petId", "userId"]
      }
    }
  ]
}

The tool schema is important because it tells the assistant:

Which operations are available
What each tool does
Which arguments it accepts
Which arguments are required
Which values are valid for enum fields

Keep descriptions specific. A clear description helps the assistant select the correct tool and construct valid arguments.

3. Execute a Tool Call

When the user asks:

Show me available cats under $300.

The assistant can translate that request into a tool call:

{
  "tool": "search_pets",
  "arguments": {
    "species": "CAT",
    "status": "AVAILABLE",
    "maxPrice": 300
  }
}

The MCP server then maps the tool arguments to the underlying API request:

async function search_pets({ species, status, maxPrice }) {
  const params = new URLSearchParams({
    species,
    status,
    maxPrice: String(maxPrice)
  });

  const response = await fetch(
    `https://petstoreapi.com/v1/pets?${params}`
  );

  return await response.json();
}

The server returns the API response to the assistant, which formats the results for the user.

MCP vs. Traditional APIs

Feature	Traditional API	MCP
Access	Direct HTTP	Through an AI assistant
Interface	REST or GraphQL	Natural language
Authentication	API keys or OAuth	MCP server handles authentication
Discovery	OpenAPI documentation	Tool schemas
Usage	Code or `curl`	Conversational requests
Error handling	HTTP status codes	AI interprets and presents errors

MCP does not replace the underlying API. It adds an AI-oriented interface on top of it.

Example Comparison

A direct API request might look like this:

curl -H "Authorization: Bearer token" \
  "https://petstoreapi.com/v1/pets?species=CAT&maxPrice=300"

The equivalent MCP interaction is conversational:

User: Show me available cats under $300

AI: Calls search_pets with:
    species = CAT
    status = AVAILABLE
    maxPrice = 300

AI: Here are 5 available cats under $300:
    1. Fluffy - $250
    2. Whiskers - $280
    ...

The API still performs the search. MCP provides the discovery and interaction layer that allows the assistant to invoke it.

How Modern PetstoreAPI Implements MCP

Modern PetstoreAPI provides an MCP server that exposes pet-store operations as tools.

Available Tools

The available tools include:

search_pets — Search pets by criteria
get_pet — Get pet details
create_order — Place an order
get_inventory — Check inventory
update_pet_status — Update pet availability

Example: Search and Order

A request such as:

Find me a dog under $500 and place an order

should be handled as a multi-step workflow:

Call search_pets({ species: "DOG", maxPrice: 500 }).
Show the matching results to the user.
Wait for confirmation, such as: Order the Labrador.
Call create_order({ petId: "019b4132", userId: "user-456" }).
Confirm that the order was placed.

Separating search from order creation gives the user an opportunity to review and confirm the selected pet before an action is performed.

MCP Server Code

The following server uses the MCP SDK and a standard input/output transport:

import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';

const server = new Server(
  {
    name: 'petstore-mcp',
    version: '1.0.0'
  },
  {
    capabilities: {
      tools: {}
    }
  }
);

server.setRequestHandler('tools/list', async () => ({
  tools: [
    {
      name: 'search_pets',
      description: 'Search for pets',
      inputSchema: {
        type: 'object',
        properties: {
          species: { type: 'string' },
          maxPrice: { type: 'number' }
        }
      }
    }
  ]
}));

server.setRequestHandler('tools/call', async (request) => {
  const { name, arguments: args } = request.params;

  if (name === 'search_pets') {
    const response = await fetch(
      `https://petstoreapi.com/v1/pets?${new URLSearchParams(args)}`
    );

    return {
      content: [
        {
          type: 'text',
          text: JSON.stringify(await response.json())
        }
      ]
    };
  }
});

const transport = new StdioServerTransport();
await server.connect(transport);

The implementation has two important handlers:

tools/list publishes the tools and their schemas.
tools/call executes the selected tool and returns the result.

For a production implementation, add validation for tool names and arguments, and map API failures to clear tool responses.

Testing MCP with Apidog

Use Apidog to test the API and MCP integration in separate stages.

Test the Underlying API

First verify that the API endpoints work independently:

Search pets with valid filters.
Retrieve pet details.
Create orders with valid identifiers.
Test invalid query parameters.
Confirm authentication behavior.
Check response formats and error status codes.

Validate the MCP Layer

Then verify that the MCP server correctly exposes and invokes those operations:

Confirm every expected operation appears in tools/list.
Check that tool names and descriptions are accurate.
Validate required and optional input fields.
Confirm enum values match the API contract.
Verify tool arguments map to the correct API parameters.
Test authentication failures.
Test API errors and malformed tool input.
Confirm returned data is formatted as valid tool content.

Testing both layers makes it easier to determine whether a failure comes from the API contract, the MCP schema, or the tool execution logic.

Why MCP Matters

1. AI-Native APIs

APIs become accessible through natural language. Non-technical users can interact with your API through supported AI assistants.

2. Standardization

MCP provides a standard approach to AI and API integration. You can expose your operations through MCP instead of building a separate custom integration for every AI client.

3. Security

MCP servers handle authentication. AI assistants do not need direct access to the API keys used by the underlying service.

The MCP server should still validate inputs, enforce authorization, and apply the same security controls as any other API integration.

4. Composability

AI assistants can combine multiple MCP servers to create workflows across services.

For example, an assistant could search a pet inventory service, retrieve customer information from another service, and then create an order through the PetstoreAPI MCP server.

Conclusion

MCP bridges AI assistants and APIs. Modern PetstoreAPI implements MCP, allowing Claude Desktop and other AI tools to interact with the pet store through natural language.

To implement a similar integration:

Identify the API operations the assistant should access.
Wrap those operations as MCP tools.
Define accurate input schemas.
Register the MCP server with an AI client.
Validate authentication, input handling, and error responses.
Test both the underlying API and MCP tool calls.

Key takeaways:

MCP connects AI assistants to APIs.
Tools define what the AI can do.
Tool schemas describe valid inputs.
Natural language requests can trigger API calls.
MCP servers can wrap existing REST APIs.
Modern PetstoreAPI demonstrates an MCP-based implementation.

FAQ

Which AI assistants support MCP?

Claude Desktop, Cursor, and other Anthropic-powered tools support MCP. Support is growing across AI clients.

Is MCP secure?

MCP servers handle authentication, so AI assistants do not need to see the API keys used by the underlying service. You should still validate inputs and enforce authorization in the MCP server and API.

Can I use MCP with existing APIs?

Yes. Build an MCP server that wraps your existing API. Each MCP tool can translate structured tool arguments into requests to your REST or GraphQL endpoints.

Does MCP replace REST APIs?

No. MCP is an interface for AI assistant access. REST APIs remain useful for direct programmatic access, integrations, and clients that do not use MCP.

How do I test MCP tools?

Use Apidog to test the underlying APIs and contracts, then connect the MCP server to an MCP-compatible client such as Claude Desktop to test tool discovery and execution.

WebSocket vs Server-Sent Events: Which Is Better for Real-Time APIs?

Preecha — Sat, 29 Aug 2026 13:01:28 +0000

TL;DR

Use Server-Sent Events (SSE) for one-way server-to-client updates such as notifications, status changes, and live feeds. Use WebSocket for bidirectional communication such as chat, gaming, and live bidding. SSE is simpler and runs over HTTP, while WebSocket provides lower-latency two-way messaging at the cost of additional complexity. Modern PetstoreAPI uses both protocols for different real-time scenarios.

Try Apidog today

Introduction

Suppose a pet changes from available to adopted. Clients need to receive that update immediately. Should you use WebSocket or Server-Sent Events (SSE)?

WebSocket is often the default because it supports more communication patterns. However, SSE is usually the better option when the server only needs to push updates. It uses standard HTTP, works with existing HTTP infrastructure, and includes browser-managed reconnection.

Modern PetstoreAPI uses both protocols:

SSE for pet status updates and order notifications
WebSocket for live auction bidding and real-time chat

The right choice depends on how data flows through your application.

If you are building or testing real-time APIs, Apidog supports both SSE and WebSocket testing. You can test event streams, validate message formats, and simulate reconnection scenarios.

This guide compares SSE and WebSocket, demonstrates both implementations with Modern PetstoreAPI examples, and explains when to use each protocol.

What Is Server-Sent Events (SSE)?

SSE is an HTTP-based protocol for streaming events from a server to a client.

How SSE Works

The client opens a long-lived HTTP connection and listens for events:

const eventSource = new EventSource(
  'https://petstoreapi.com/v1/pets/notifications'
);

eventSource.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log('Pet update:', data);
};

eventSource.addEventListener('adoption', (event) => {
  const data = JSON.parse(event.data);
  console.log('Pet adopted:', data.petId);
});

The server responds with a text/event-stream:

GET /v1/pets/notifications HTTP/1.1
Accept: text/event-stream

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache

event: adoption
data: {"petId":"019b4132","userId":"user-456"}

event: status-change
data: {"petId":"019b4127","status":"AVAILABLE"}

Each event ends with a blank line. The event field identifies the event type, and the data field contains the payload.

SSE Features

1. One-way communication

The server pushes messages to the client. The client cannot send messages through the SSE connection, but it can use regular HTTP requests for client-to-server actions.

2. Built on HTTP

SSE uses standard HTTP and can work with HTTP proxies, firewalls, and CDNs.

3. Automatic reconnection

When the connection drops, the browser automatically attempts to reconnect.

4. Event IDs for resuming

The server can assign IDs to events:

id: 123
event: adoption
data: {"petId":"019b4132"}

id: 124
event: status-change
data: {"petId":"019b4127"}

After disconnecting, the client sends the last received ID in the Last-Event-ID header so the server can resume the stream.

5. Simple text-based protocol

You can inspect an SSE stream directly with curl:

curl -N -H "Accept: text/event-stream" \
  https://petstoreapi.com/v1/pets/notifications

SSE Limitations

One-way only: Client-to-server communication requires separate HTTP requests.
Text-only: Binary data must be encoded, such as with base64.
Browser connection limits: Browsers typically limit SSE connections per domain to about six.
No protocol-level compression: HTTP compression can still be used, but SSE does not provide a WebSocket-style compression mechanism.

What Is WebSocket?

WebSocket is a full-duplex protocol that keeps a persistent connection open for communication in both directions.

How WebSocket Works

The client and server can send messages at any time:

const ws = new WebSocket(
  'wss://petstoreapi.com/auctions/019b4132'
);

ws.onopen = () => {
  ws.send(JSON.stringify({
    type: 'bid',
    amount: 500
  }));
};

ws.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log('Auction update:', data);
};

ws.onclose = () => {
  console.log('Connection closed');
  // Add manual reconnection logic when needed.
};

The server can send messages such as:

{"type":"bid","userId":"user-456","amount":550}
{"type":"outbid","newAmount":550}

The client can send messages such as:

{"type":"bid","amount":600}
{"type":"watch","petId":"019b4132"}

WebSocket Features

1. Bidirectional communication

Both the client and server can send messages whenever necessary.

2. Low latency

After the connection is established, messages do not require a new HTTP request. This makes WebSocket suitable for gaming, chat, and live collaboration.

3. Binary data support

WebSocket can send binary frames directly, so images, audio, and video do not need base64 encoding.

4. Custom protocol

Connections use ws:// or secure wss://. After the initial handshake, communication uses the WebSocket protocol.

5. Frame-based messages

WebSocket frames allow messages to be transmitted and reassembled independently.

WebSocket Limitations

More complex setup: You need a WebSocket server and connection lifecycle management.
Manual reconnection: Applications must implement retry and reconnection logic.
Proxy compatibility issues: Some corporate proxies block or do not fully support WebSocket traffic.
Stateful connections: The server must track active connections, which can make scaling more involved.
Limited HTTP semantics after the handshake: You cannot rely on HTTP caching, status codes, or standard headers for each message.

SSE vs. WebSocket: Side-by-Side Comparison

Feature	SSE	WebSocket
Direction	Server → client	Bidirectional
Protocol	HTTP	WebSocket (`ws://` or `wss://`)
Reconnection	Automatic in browsers	Manual
Browser support	All modern browsers	All modern browsers
Proxy-friendly	Yes	Sometimes
Complexity	Simple	Complex
Binary data	No, text only	Yes
Latency	Low	Very low
Scalability	High for many stateless HTTP patterns	Medium because connections are stateful
Typical use cases	Notifications and feeds	Chat, gaming, and collaboration

How Modern PetstoreAPI Uses Both

Modern PetstoreAPI chooses the protocol based on the communication pattern.

Use SSE for Pet Updates

Endpoint:

GET https://petstoreapi.com/v1/pets/notifications

A client can subscribe to updates for a specific user:

const events = new EventSource(
  'https://petstoreapi.com/v1/pets/notifications?userId=user-456'
);

events.addEventListener('adoption', (event) => {
  const data = JSON.parse(event.data);
  showNotification(`${data.petName} was adopted!`);
});

events.addEventListener('status-change', (event) => {
  const data = JSON.parse(event.data);
  updatePetStatus(data.petId, data.status);
});

A Node.js server can create the stream like this:

app.get('/v1/pets/notifications', (req, res) => {
  res.setHeader('Content-Type', 'text/event-stream');
  res.setHeader('Cache-Control', 'no-cache');
  res.setHeader('Connection', 'keep-alive');

  const userId = req.query.userId;

  const subscription = petUpdates.subscribe(userId, (event) => {
    res.write(`event: ${event.type}\n`);
    res.write(`data: ${JSON.stringify(event.data)}\n\n`);
  });

  req.on('close', () => {
    subscription.unsubscribe();
  });
});

SSE is a good fit for:

Pet status changes, such as available → adopted
Order notifications, such as placed, shipped, and delivered
Inventory updates
Price changes

Use WebSocket for Live Auctions

Endpoint:

wss://petstoreapi.com/auctions/{auctionId}

The client can place bids and process updates over the same connection:

const ws = new WebSocket(
  'wss://petstoreapi.com/auctions/019b4132'
);

function placeBid(amount) {
  ws.send(JSON.stringify({
    type: 'bid',
    amount
  }));
}

ws.onmessage = (event) => {
  const message = JSON.parse(event.data);

  switch (message.type) {
    case 'bid':
      updateCurrentBid(message.amount, message.userId);
      break;

    case 'outbid':
      showOutbidNotification(message.newAmount);
      break;

    case 'auction-end':
      showAuctionResult(message.winner);
      break;
  }
};

A server can process bids and broadcast them to all auction participants:

wss.on('connection', (ws, req) => {
  const auctionId = req.params.auctionId;
  const auction = auctions.get(auctionId);

  ws.on('message', (data) => {
    const message = JSON.parse(data);

    if (message.type === 'bid') {
      auction.placeBid(message.userId, message.amount);

      auction.participants.forEach((participant) => {
        participant.send(JSON.stringify({
          type: 'bid',
          userId: message.userId,
          amount: message.amount
        }));
      });
    }
  });
});

WebSocket is a good fit for:

Live auction bidding
Real-time support chat
Collaborative pet care planning
Live inventory updates during sales

Testing Real-Time APIs with Apidog

Apidog supports testing both SSE and WebSocket APIs.

Test an SSE Endpoint

Create an SSE request:

   GET https://petstoreapi.com/v1/pets/notifications
   Accept: text/event-stream

Validate the event stream:

Check event types.
Validate JSON payloads.
Verify event IDs.
Confirm that events arrive in the expected order.

Test failure and recovery scenarios:

Drop the connection.
Restart the server.
Resume from the last event ID.
Verify reconnection behavior.

Test a WebSocket Connection

Create a connection:

   wss://petstoreapi.com/auctions/019b4132

Send test messages:

   {"type":"bid","amount":500}
   {"type":"watch","petId":"019b4132"}

Validate responses:

Check message formats.
Test client-to-server and server-to-client flows.
Verify connection handling.
Test invalid messages and error responses.

Test operational scenarios:

Multiple concurrent connections
Message ordering
Connection timeouts
Reconnection logic

When to Use SSE

Choose SSE when:

The server is the primary sender.
You want to use standard HTTP infrastructure.
Browser-managed reconnection is useful.
The connection must work through HTTP proxies and firewalls.
You are delivering notifications, status updates, or feeds.

Examples include:

Pet adoption notifications
Order status updates
Inventory changes
Price alerts
News feeds

When to Use WebSocket

Choose WebSocket when:

Both client and server send messages frequently.
Low latency is critical.
The application needs binary frames.
You need a custom message protocol.
The application handles a high message frequency, such as hundreds of messages per second.

Examples include:

Live auction bidding
Real-time chat
Multiplayer games
Collaborative editing
Live video streaming

Do Not Choose WebSocket Just Because It Seems More Advanced

Avoid adding WebSocket complexity when your application only needs server-to-client updates:

“It’s more advanced.” Extra complexity does not provide value if you do not need bidirectional messaging.
“Everyone uses it.” SSE may be a better fit for simple event streams.
“It’s faster.” SSE is fast enough for many notification and status-update scenarios.
“It’s bidirectional.” First confirm that the client actually needs to send messages through the persistent connection.

Conclusion

SSE and WebSocket both support real-time communication, but they solve different problems.

SSE is a practical choice for one-way server-to-client updates because it is simple, HTTP-compatible, and supports automatic browser reconnection. WebSocket is better for bidirectional, low-latency communication such as live auctions, chat, and gaming.

Modern PetstoreAPI uses SSE for notifications and status updates, and WebSocket for live auctions and chat. Choose the protocol based on your communication pattern—not on which protocol appears more powerful.

Test your real-time APIs with Apidog to verify event streams, message formats, reconnection behavior, and failure scenarios.

FAQ

Can SSE work through corporate firewalls?

Yes. SSE uses standard HTTP, so it generally works through HTTP proxies and firewalls. WebSocket uses a custom protocol that some proxies block.

Is WebSocket faster than SSE?

WebSocket can have slightly lower latency because messages do not include HTTP overhead after the handshake. For many applications, however, the difference is negligible, and SSE is fast enough for notifications, feeds, and status updates.

How do you handle SSE reconnection?

Browsers handle reconnection automatically. The server should send event IDs so the client can reconnect with the Last-Event-ID header and resume from the last received event.

Can you use SSE with mobile apps?

Yes. iOS and Android applications can consume SSE through native HTTP clients or libraries. SSE works anywhere HTTP works.

What is the maximum SSE connection time?

There is no protocol-defined maximum. An SSE connection can remain open indefinitely, although proxies or load balancers may impose timeouts, often around 30–60 seconds. The browser can reconnect when the connection closes.

Can WebSocket send binary data?

Yes. WebSocket supports both text and binary frames, allowing applications to send images, audio, or other binary data without base64 encoding.

How many SSE connections can a browser have?

Browsers typically limit SSE connections per domain to about six. This is rarely a problem because most applications only need one or two SSE connections.

Do you need a special server for SSE?

No. Any HTTP server can handle SSE. Set Content-Type: text/event-stream, keep the response open, and write events using the SSE format.

When Should You Use MQTT Instead of HTTP for APIs?

Preecha — Sat, 29 Aug 2026 02:01:48 +0000

TL;DR

Use MQTT for IoT devices with limited battery, unreliable networks, or pub-sub messaging patterns. Use HTTP for standard web and mobile APIs. MQTT uses 2-byte headers compared with HTTP’s 100+ bytes, making it suitable for constrained devices. Modern PetstoreAPI uses MQTT for pet tracking collars and smart feeders.

Try Apidog today

Introduction

Imagine a pet tracking collar that sends a location update every five minutes. It runs on a coin-cell battery designed to last six months.

With HTTP, the battery might last only two weeks. With MQTT, it can last the full six months.

HTTP is the standard choice for web and mobile APIs, but it was designed for general-purpose request-response communication. MQTT (Message Queuing Telemetry Transport) was designed for constrained devices operating with limited bandwidth, battery power, and unreliable networks.

Modern PetstoreAPI uses both protocols:

HTTP for web and mobile applications
MQTT for IoT devices such as pet tracking collars, smart feeders, and health monitors

If you’re building or testing IoT APIs, Apidog supports MQTT testing alongside HTTP. You can test pub-sub patterns, validate message formats, and simulate network failures.

In this guide, you’ll learn when MQTT is a better fit than HTTP, how Modern PetstoreAPI uses both protocols, and how to test each approach.

What Is MQTT?

MQTT is a lightweight publish-subscribe messaging protocol designed for IoT applications.

How MQTT Works

MQTT clients publish messages to topics. Other clients subscribe to those topics. An MQTT broker routes messages between publishers and subscribers.

For example:

Publisher: Pet collar
Topic: pets/019b4132/location
Payload: {"lat":37.7749,"lng":-122.4194,"battery":85}

Subscriber: Mobile app
Subscription: pets/019b4132/location
Receives: {"lat":37.7749,"lng":-122.4194,"battery":85}

The collar does not need to know which applications consume the message. It only publishes to the topic. Any authorized subscriber can receive updates.

Core MQTT Features

Small headers — MQTT headers can be as small as 2 bytes, compared with roughly 100–500 bytes for typical HTTP requests.
Persistent connections — Clients can keep a connection open instead of creating a new connection for every message.
Quality of Service (QoS) — QoS 0, 1, and 2 provide different delivery guarantees.
Last Will messages — A broker can publish a message when a client disconnects unexpectedly.
Retained messages — A broker can store the latest message on a topic and deliver it to new subscribers.

MQTT vs. HTTP

Feature	MQTT	HTTP
Header size	As small as 2 bytes	Typically 100–500 bytes
Communication pattern	Publish-subscribe	Request-response
Connection	Persistent	Per request, unless reused
Bandwidth usage	Very low	Higher
Battery impact	Minimal	Significant for constrained devices
Browser support	Through WebSocket	Native

Bandwidth Example

Assume a device sends 1,000 location updates per day:

HTTP: approximately 420 KB per day, or 12.6 MB per month
MQTT: approximately 52 KB per day, or 1.56 MB per month

In this example, MQTT uses approximately eight times less bandwidth.

Actual usage depends on payload size, connection behavior, TLS settings, and protocol overhead. The example illustrates why MQTT is useful for bandwidth-constrained devices.

When MQTT Is the Better Choice

1. Battery-Powered IoT Devices

For a pet tracking collar:

MQTT: six months of battery life
HTTP: two weeks of battery life

MQTT helps reduce radio usage through persistent connections and smaller protocol overhead.

Use MQTT when the device:

Runs on a small battery
Sends frequent updates
Has limited processing power
Operates over a metered or low-bandwidth connection

2. Unreliable Networks

Cellular IoT devices may frequently lose connectivity. MQTT provides features that help applications recover:

QoS for delivery guarantees
Automatic reconnection in client libraries
Session persistence
Last Will messages for detecting unexpected disconnects

A typical implementation should define what happens when a device disconnects and how it resynchronizes after reconnecting.

3. Many-to-Many Communication

MQTT topics make it easy for multiple devices and applications to exchange messages.

For a smart pet feeder:

Feeder 1 publishes to pets/019b4132/feeding
Feeder 2 publishes to pets/019b4127/feeding

App 1 subscribes to pets/+/feeding
App 2 subscribes to pets/019b4132/feeding

The + wildcard matches one topic level, so pets/+/feeding receives feeding events for all pets.

4. Real-Time Sensor Data

A pet health monitor might send an update every second:

Topic: pets/019b4132/health
QoS: 0

MQTT is useful for this workload because it avoids repeated request setup, minimizes latency, and supports high-frequency messages over a persistent connection.

When HTTP Is the Better Choice

1. Standard Web and Mobile Applications

HTTP is usually the simplest option for user-facing applications because:

Every major language has HTTP libraries
Browsers support it natively
Proxies and firewalls commonly allow it
HTTP APIs are familiar to most developers

2. Request-Response Operations

Use HTTP when a client needs to request a specific resource and receive a direct response.

For example:

GET /pets/019b4132

200 OK
Content-Type: application/json

{
  "name": "Fluffy",
  "species": "CAT"
}

This interaction is naturally represented by HTTP. Using MQTT would require defining request and response topics and correlating messages manually.

3. Caching

HTTP provides established caching mechanisms, including:

Browser caching
CDN caching
Proxy caching
Cache-Control headers
Conditional requests

MQTT does not provide HTTP-style caching. Although retained messages can provide the latest value on a topic, they are not a replacement for general-purpose HTTP caching.

4. RESTful APIs

HTTP provides standard methods, status codes, and semantics:

Methods: GET, POST, PUT, DELETE
Status codes: 200 OK, 201 Created, 404 Not Found
Standard request and response handling
Established error-handling conventions

How Modern PetstoreAPI Uses MQTT

Modern PetstoreAPI uses HTTP for user-facing APIs and MQTT for IoT device communication.

Pet Tracking Collars

A collar publishes location updates to a pet-specific topic:

Topic: pets/019b4132/location
QoS: 1

{
  "lat": 37.7749,
  "lng": -122.4194,
  "battery": 85,
  "timestamp": "2026-03-13T10:30:00Z"
}

A mobile application subscribes to the topic:

const mqtt = require('mqtt');

const client = mqtt.connect('mqtts://mqtt.petstoreapi.com');

client.on('connect', () => {
  client.subscribe('pets/019b4132/location', (error) => {
    if (error) {
      console.error('Subscription failed:', error);
    }
  });
});

client.on('message', (topic, message) => {
  const location = JSON.parse(message.toString());

  updateMap(location.lat, location.lng);
});

The example uses QoS 1, which provides at-least-once delivery. Consumers should therefore be prepared to handle duplicate messages.

Smart Feeders

A feeder subscribes to its feeding schedule:

Topic: pets/019b4132/feeding-schedule
Retained: true

{
  "times": ["08:00", "18:00"],
  "amount": 100
}

The retained message allows a feeder to receive the latest schedule when it subscribes.

The feeder publishes feeding events:

Topic: pets/019b4132/feeding-events

{
  "timestamp": "2026-03-13T08:00:15Z",
  "amount": 100,
  "dispensed": true
}

Health Monitors

A health monitor publishes high-frequency vital updates:

Topic: pets/019b4132/health
QoS: 0

{
  "heartRate": 120,
  "temperature": 38.5,
  "activity": "resting"
}

QoS 0 is suitable when occasional message loss is acceptable and the device will publish another reading shortly.

Testing MQTT with Apidog

Apidog supports MQTT testing alongside HTTP and other protocols.

Test an MQTT Pub-Sub Flow

Use the following workflow:

Connect to the MQTT broker.
Subscribe to the topic used by the application.
Publish a test message from a separate client or request.
Validate the received topic and payload.
Test the behavior for QoS 0, 1, and 2.
Confirm that consumers handle duplicate or delayed messages where applicable.

For the pet location example, publish a message to:

pets/019b4132/location

Then verify that the mobile application receives and parses the expected payload.

Simulate Network Failures

Test how devices and consumers behave when connectivity changes:

Disconnect and reconnect the client
Test automatic reconnection
Verify QoS 1 and QoS 2 delivery behavior
Check Last Will messages
Validate session persistence
Confirm that retained messages are delivered to new subscribers

These tests are especially important for cellular devices that can lose connectivity without warning.

Compare MQTT with HTTP

Implement the same operation through both protocols and compare:

Bandwidth usage
Message latency
Battery or connection overhead
Delivery behavior
Data consistency
Recovery after network failures

This gives you measurable criteria for choosing a protocol instead of choosing based only on familiarity.

Conclusion

MQTT and HTTP solve different problems:

Use MQTT for constrained IoT devices, unreliable networks, real-time sensor data, and pub-sub communication.
Use HTTP for standard web and mobile APIs, request-response operations, caching, and RESTful resources.

Modern PetstoreAPI uses both protocols: HTTP for user-facing APIs and MQTT for IoT devices. The right choice depends on your device constraints, communication pattern, reliability requirements, and caching needs—not on which protocol is universally “better.”

Test both protocols with Apidog to determine which implementation best fits your use case.

FAQ

Can MQTT Work Over HTTP?

MQTT can run over WebSocket, which works over HTTP. This can help with firewall traversal and browser compatibility, but it adds transport overhead compared with a direct MQTT connection.

What Are MQTT QoS Levels?

QoS 0: At most once — The message is delivered without acknowledgment. It may be lost.
QoS 1: At least once — The message is acknowledged, but it may be delivered more than once.
QoS 2: Exactly once — The protocol provides the strongest delivery guarantee and prevents duplicate delivery.

Choose the lowest QoS level that meets your application’s requirements.

Is MQTT Secure?

MQTT supports TLS encryption through MQTTS and username/password authentication. Modern PetstoreAPI uses MQTTS for its IoT devices.

In production, use encrypted connections, authenticate clients, and restrict which topics each client can publish or subscribe to.

Can Browsers Use MQTT?

Browsers can use MQTT over WebSocket. Libraries such as MQTT.js support browser environments.

How Does MQTT Compare with WebSocket?

MQTT is a messaging protocol that can run over WebSocket. WebSocket is a transport layer that provides a persistent, bidirectional connection.

MQTT adds IoT-specific messaging features such as:

Pub-sub topics
QoS levels
Retained messages
Last Will messages

Use WebSocket directly when you need a custom bidirectional protocol. Use MQTT when you need standardized pub-sub messaging and MQTT delivery features.

Socket.IO vs Native WebSocket: Which Should You Use?

Preecha — Sat, 29 Aug 2026 01:01:20 +0000

Native WebSocket vs. Socket.IO: Which Should You Use?

TL;DR

Use Native WebSocket for simple, low-latency communication in modern browsers. Use Socket.IO when you need automatic reconnection, fallback transports, rooms, or namespaces. Socket.IO adds 200KB+ of overhead but handles more connection edge cases. Modern PetstoreAPI uses Native WebSocket for auctions and Socket.IO for support chat.

Try Apidog today

Introduction

Real-time features require bidirectional communication between the client and server. The right protocol depends on how much connection management your application needs.

Native WebSocket is built into modern browsers and has minimal overhead. Socket.IO adds features such as reconnection, fallback transports, rooms, namespaces, and acknowledgments, but increases bundle size by 200KB+.

Modern PetstoreAPI uses both:

Native WebSocket for live pet auctions, where latency matters.
Socket.IO for customer support chat, where reconnection and rooms are more valuable.

If you’re testing real-time APIs, Apidog supports both Native WebSocket and Socket.IO testing.

Native WebSocket

Native WebSocket is the browser standard for bidirectional communication. It uses a straightforward event-based API and does not require a client library.

Basic usage

const ws = new WebSocket(
  'wss://petstoreapi.com/auctions/019b4132'
);

ws.onopen = () => {
  ws.send(JSON.stringify({
    type: 'bid',
    amount: 500
  }));
};

ws.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log('Received:', data);
};

ws.onerror = (error) => {
  console.error('WebSocket error:', error);
};

ws.onclose = () => {
  console.log('Connection closed');
};

Advantages

No dependencies: WebSocket is built into modern browsers.
Low overhead: There is no additional client protocol layer.
Simple API: The connection lifecycle is easy to understand.
Small bundle size: The browser provides the implementation.

Limitations

No automatic reconnection: You must implement retry logic.
No fallback transport: If WebSocket cannot connect, the client does not automatically switch transports.
No built-in rooms or namespaces: You must implement this behavior yourself.
Manual connection health: Your application may need ping/pong or heartbeat handling.

For example, a basic reconnect strategy can be implemented around the connection factory:

function connect() {
  const ws = new WebSocket(
    'wss://petstoreapi.com/auctions/019b4132'
  );

  ws.onopen = () => {
    console.log('Connected');
  };

  ws.onmessage = (event) => {
    console.log('Received:', JSON.parse(event.data));
  };

  ws.onclose = () => {
    console.log('Connection closed; retrying...');
    setTimeout(connect, 1000);
  };

  return ws;
}

connect();

In production, add limits and backoff to avoid retrying indefinitely.

Socket.IO

Socket.IO is a library that adds connection-management and messaging features around real-time communication.

Basic usage

import { io } from 'socket.io-client';

const socket = io('https://petstoreapi.com', {
  path: '/chat'
});

socket.on('connect', () => {
  socket.emit('join-room', 'support-123');
});

socket.on('message', (data) => {
  console.log('Received:', data);
});

socket.on('disconnect', () => {
  console.log('Disconnected; Socket.IO will attempt to reconnect');
});

Key features

1. Automatic reconnection

const socket = io('https://petstoreapi.com', {
  reconnection: true,
  reconnectionDelay: 1000,
  reconnectionAttempts: 5
});

2. Fallback transports

If WebSocket fails, Socket.IO can try other transports, including:

WebSocket
HTTP long-polling
HTTP streaming

3. Rooms and namespaces

Rooms let the server group connections. Namespaces separate communication channels.

// Server
io.of('/chat').on('connection', (socket) => {
  socket.join('support-123');
  socket.to('support-123').emit('user-joined');
});

// Client
const socket = io('/chat');

4. Acknowledgments

Acknowledgments let the server confirm that an event was received or processed.

socket.emit(
  'bid',
  { amount: 500 },
  (response) => {
    console.log('Server acknowledged:', response);
  }
);

5. Binary support

Socket.IO can send binary data such as buffers:

socket.emit('image', buffer);

Limitations

Larger bundle: The minified client adds 200KB+ of overhead.
Server dependency: The server must support Socket.IO.
More concepts: You need to understand events, rooms, namespaces, and acknowledgments.
Protocol overhead: Socket.IO adds an additional protocol layer.

Native WebSocket vs. Socket.IO

Feature	Native WebSocket	Socket.IO
Bundle size	0 KB	200+ KB
Automatic reconnect	No	Yes
Fallback transport	No	Yes, including long-polling
Rooms	No	Yes
Namespaces	No	Yes
Acknowledgments	No	Yes
Binary data	Yes	Yes
Browser support	Modern browsers	Broad support through fallback
Server	Any WebSocket server	Socket.IO server
Complexity	Simple	More feature-rich

How Modern PetstoreAPI Uses Both

Native WebSocket for auctions

Live auctions need low latency and use a simple bidding protocol:

const ws = new WebSocket(
  'wss://petstoreapi.com/auctions/019b4132'
);

ws.onmessage = (event) => {
  const { type, data } = JSON.parse(event.data);

  if (type === 'bid') {
    updateBidDisplay(data.amount, data.userId);
  }

  if (type === 'sold') {
    showSoldNotification(data.winnerId);
  }
};

function placeBid(amount) {
  ws.send(JSON.stringify({
    type: 'bid',
    amount
  }));
}

placeBid(500);

Native WebSocket is a good fit because:

Performance is critical.
The target audience uses modern browsers.
The message protocol is simple.
The feature does not require rooms.

Socket.IO for support chat

Customer support chat prioritizes reliability and connection management:

const socket = io('https://petstoreapi.com/chat');

socket.on('connect', () => {
  socket.emit('join-support', {
    userId: 'user-456'
  });
});

socket.on('message', (msg) => {
  displayMessage(msg);
});

socket.on('agent-typing', () => {
  showTypingIndicator();
});

socket.emit('message', {
  text: 'I need help with my order',
  userId: 'user-456'
});

Socket.IO is a good fit because it provides:

Automatic reconnection for users on mobile networks.
Rooms for multiple support sessions.
Fallback transports for networks where WebSocket is unavailable.
Acknowledgments for message delivery.

See the Modern PetstoreAPI WebSocket docs and Socket.IO docs.

Testing with Apidog

Apidog supports testing both protocols.

Test a Native WebSocket connection

Create a WebSocket request.
Connect to wss://petstoreapi.com/auctions/019b4132.
Send test messages such as a bid event.
Validate the server responses.
Test connection-close and reconnect behavior if your client implements it.

Test a Socket.IO connection

Create a Socket.IO connection.
Test events and acknowledgments.
Validate room behavior.
Test reconnection scenarios.
Verify fallback behavior when WebSocket is unavailable.

When to Use Each

Use Native WebSocket when

You are building for modern browsers only.
Performance is critical.
You need simple bidirectional messaging.
You want minimal bundle size.
You do not need automatic reconnection.
You can implement rooms and health checks yourself.

Typical examples include:

Live auctions
Real-time dashboards
Gaming with manual reconnect handling
Stock tickers

Use Socket.IO when

You need automatic reconnection.
You need support for older browsers.
Users may connect through corporate networks.
You need rooms or namespaces.
You want event acknowledgments.
Your users may have unreliable mobile connections.

Typical examples include:

Chat applications
Collaborative editing
Customer support
Notifications with delivery confirmation

Conclusion

Native WebSocket is faster and simpler, while Socket.IO is more feature-rich and heavier. Choose based on the connection behavior and messaging features your application requires.

Modern PetstoreAPI uses both:

Native WebSocket where performance matters.
Socket.IO where reliability and built-in features matter.

FAQ

Can I use Socket.IO with Native WebSocket clients?

No. Socket.IO uses a custom protocol. A Socket.IO server requires a Socket.IO client.

Does Socket.IO work through corporate firewalls?

It can. If WebSocket is blocked, Socket.IO can fall back to HTTP long-polling.

Is Socket.IO slower than Native WebSocket?

Slightly. Socket.IO adds protocol overhead, but the difference is negligible for most applications.

Can I migrate from Socket.IO to Native WebSocket?

Yes, but you will need to implement reconnection, rooms, namespaces, acknowledgments, and other required features yourself.

Does Native WebSocket support rooms?

No. You must implement room logic on the server and track which connections belong to each room.

What is Tokenization? The Ultimate Guide to API Security

Preecha — Fri, 28 Aug 2026 14:01:24 +0000

Tokenization replaces sensitive data with non-sensitive placeholders called tokens. A token may preserve the original value’s format or length, but it has no useful value by itself. In API security, tokenization lets an application accept payment details, medical records, or personal information while minimizing how often the original data is stored or processed.

Try Apidog today

A typical tokenization workflow has four controlled stages:

Capture the data: Sensitive information enters the system through a secured API request.
Generate a token: A tokenization service creates an opaque, random token that does not reveal the original value.
Store the mapping: The original value is stored in an isolated token vault. The vault maps the token to the original data.
Use the token: Internal services and databases use the token instead of the sensitive value for subsequent operations.

A simplified request flow looks like this:

Client
  |
  |  POST /payment-methods
  |  { "cardNumber": "..." }
  v
Tokenization service
  |
  |-- Stores the card number in the token vault
  |-- Returns an opaque token
  v
Application
  |
  |  Stores and uses:
  |  { "paymentToken": "tok_..." }

The token should not contain the original value, a reversible encoding, or predictable information. Access to the token vault must be restricted with authentication, authorization, audit logging, and network controls.

Tokenization reduces the amount of sensitive data exposed to application services and databases. It can also reduce the systems that directly handle regulated data, although the exact compliance impact depends on the implementation and applicable requirements such as PCI DSS or GDPR.

Tokenization vs. Encryption: Which Offers Better API Security?

Tokenization and encryption protect data in different ways. Choosing between them depends on where the data is used, whether it must be recovered, and how the keys or token mappings will be managed.

How encryption works

Encryption transforms plaintext into ciphertext using an algorithm and a cryptographic key. A service with the correct key can decrypt the ciphertext and recover the original value.

For example:

Plaintext  -> Encrypt(key)   -> Ciphertext
Ciphertext -> Decrypt(key)   -> Plaintext

Encryption is commonly used for:

Data in transit, such as HTTPS and TLS
Backups and files
Database fields
Messages and stored documents

The main security concern is key management. If an attacker obtains both the encrypted data and the decryption key, the data may be exposed.

How tokenization works

Tokenization replaces the sensitive value with an opaque reference. The token has no mathematical relationship to the original value, so it is not decrypted. Instead, an authorized service looks up the value in the token vault.

Sensitive value -> Token vault lookup -> Opaque token
Opaque token    -> Authorized lookup  -> Sensitive value

The application may store and pass a token like this:

{
  "customerId": "cus_12345",
  "paymentToken": "tok_7f31c8..."
}

Only the tokenization service should be able to resolve paymentToken to the original data.

Side-by-side comparison

Feature	Tokenization	Encryption
Reversibility	Requires access to the token vault	Requires the correct decryption key
Data relationship	Opaque value with no mathematical relationship to the original	Mathematically transformed ciphertext
Key or mapping management	Protect the token vault and its mappings	Protect encryption keys and ciphertext
Compliance scope	Can reduce the systems that handle sensitive data, depending on implementation	Encrypted data may still remain in scope for applicable requirements
Performance	Often efficient for reference-based transactions	Processing cost depends on the algorithm, payload, and implementation
Common use cases	Payment references, API identifiers, and database fields	Files, backups, messages, and data in transit

Tokenization and encryption are not mutually exclusive. A practical design often uses both:

Use TLS to protect API requests in transit.
Use tokenization to keep raw payment or personal data out of general application systems.
Encrypt the token vault and its backups.
Use a dedicated key-management system for encryption keys.
Enforce authorization before resolving a token.

For example, an API should usually accept sensitive data only at a narrowly scoped endpoint:

POST /v1/payment-methods
Authorization: Bearer <access-token>
Content-Type: application/json

{
  "cardNumber": "4111111111111111",
  "expirationMonth": 12,
  "expirationYear": 2028
}

After tokenization, the application should use the returned reference:

{
  "paymentToken": "tok_7f31c8..."
}

Do not log the original request body, store it in general-purpose databases, or include it in analytics events.

Tokenization Use Cases, Benefits, and Examples

Tokenization is useful when an application needs to reference sensitive data repeatedly without exposing the original value to every service in the workflow.

Retail and e-commerce

An online store can send card details to a payment or tokenization service and store only the resulting payment token:

{
  "userId": "user_2048",
  "paymentToken": "tok_7f31c8...",
  "lastFour": "1111"
}

The token can be used for future charges, while the raw card number remains outside the merchant’s main application database. The merchant should still verify the provider’s token lifecycle, authorization model, and compliance responsibilities.

Healthcare

Healthcare systems can tokenize patient identifiers, insurance references, or medical record numbers before sharing them with internal services or external integrations. Services can coordinate around the token while access to the original value remains limited to authorized components.

Internal APIs and microservices

Tokenization can reduce the number of services that process sensitive fields. For example:

An ingestion service receives a sensitive identifier.
A tokenization service replaces it with an opaque token.
Downstream services use the token for correlation and processing.
Only an authorized service can resolve the token when necessary.

Key tokenization benefits

Reduced exposure: Fewer systems need to store or process raw sensitive data.
Simpler data handling: Services can pass references instead of sensitive values.
Potentially reduced compliance scope: The systems that never access raw data may be outside parts of the applicable compliance boundary.
Compatible integrations: Format-preserving tokens can help systems that expect a particular field shape, but the token format must be designed carefully.
Safer testing: Non-production environments can use tokens or synthetic values instead of copied production data.

Implementation checklist

When adding tokenization to an API, address the following:

Define which fields require tokenization.
Choose where tokenization occurs: at the edge, in a dedicated service, or through a third-party provider.
Keep the token vault isolated from general application storage.
Use unpredictable tokens with sufficient entropy.
Authenticate and authorize token creation and resolution separately.
Return only the minimum data needed by the caller.
Prevent raw values from appearing in logs, traces, error messages, and analytics.
Define token expiration, revocation, and rotation behavior.
Monitor token-resolution events and alert on unusual access.
Test failure cases, including vault timeouts and invalid tokens.
Use synthetic data or tokens in development and testing environments.

A tokenization design is only as strong as its vault, access controls, and surrounding application behavior. If a service can freely resolve every token, tokenization alone does not provide meaningful isolation.

Apidog: Design and Test APIs with Authentication

Implementing tokenization requires APIs that clearly define request formats, authentication rules, error responses, and token lifecycles. An API design and testing platform can help teams document these contracts and verify their behavior before deployment.

Apidog can be used to design, document, debug, and test APIs. When integrating a tokenization service, define the token-related endpoints explicitly. For example:

openapi: 3.0.3
paths:
  /v1/tokens:
    post:
      summary: Tokenize a sensitive value
      security:
        - bearerAuth: []
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required:
                - value
              properties:
                value:
                  type: string
                  writeOnly: true
      responses:
        "201":
          description: Token created
          content:
            application/json:
              schema:
                type: object
                required:
                  - token
                properties:
                  token:
                    type: string

Keep sensitive fields marked as write-only where appropriate, and avoid documenting real credentials or production values in examples.

You can configure common authentication schemes such as OAuth 2.0, Bearer tokens, and API keys. For tokenized workflows, define which credential is used to create a token and which credential is required to resolve one. These should not automatically be treated as the same permission.

A useful test flow is:

Submit a valid sensitive value to the tokenization endpoint.
Verify that the response contains a token rather than the original value.
Use the token in a downstream API request.
Confirm that unauthorized clients cannot resolve the token.
Verify that invalid, expired, or revoked tokens return the expected status code.
Inspect logs and test output to confirm that raw values are not exposed.

Example test cases include:

POST /v1/tokens with valid authorization       -> 201 Created
POST /v1/tokens without authorization          -> 401 Unauthorized
GET  /v1/records with a valid token            -> 200 OK
GET  /v1/records with an invalid token         -> 401 or 404
POST /v1/tokens with an oversized value        -> 400 Bad Request
Resolve a revoked token                        -> 401 or 404

Environment variables can help pass non-sensitive test values, base URLs, and temporary credentials between requests. Do not place production secrets or real personal data in shared collections, exported projects, or test scripts.

Apidog can also help keep the API contract aligned with OpenAPI, generate documentation, and run repeatable tests against tokenized workflows. Use it to verify both the expected success path and the security boundaries around token creation and resolution.

Conclusion

Tokenization replaces sensitive data with opaque references, allowing applications to process and store tokens instead of raw values. The token itself should not reveal or mathematically encode the original data. Recovering the original value requires controlled access to the token vault.

Tokenization and encryption solve different problems. Encryption protects data using algorithms and keys, while tokenization replaces data with a vault-managed reference. Many systems use both: TLS and encryption protect data in transit and at rest, while tokenization limits how many application components handle sensitive values.

For a reliable implementation:

Tokenize sensitive fields as early as practical.
Isolate the token vault from general application systems.
Enforce separate permissions for token creation and resolution.
Remove raw values from logs, traces, and test data.
Define expiration, revocation, and audit requirements.
Test unauthorized access and failure scenarios.
Document the workflow with an explicit API contract.

The result is not a replacement for secure coding, access control, monitoring, or encryption. It is an additional boundary that can reduce sensitive-data exposure and simplify the design of APIs handling payment, healthcare, and personal information.

Apidog can support this work by helping teams design the API contract, configure authentication, document tokenized fields, and test end-to-end request flows. Use those capabilities to validate that your tokenization workflow returns opaque tokens, protects the token vault, and never exposes raw data through ordinary application endpoints.

Can't Afford Postman? The Ultimate Postman Alternative for API Testing

Preecha — Fri, 28 Aug 2026 13:01:12 +0000

Postman vs Apidog: A Practical Migration Guide for Small API Teams

On March 1, 2026, many developers received an unexpected pricing update: the popular free plan was restricted to a single user. For years, small agencies and technical startups used the free tier to collaborate with up to three team members. Teams that need multiple users must now move to the paid Team plan, priced at $19 per user per month when billed annually. This change has prompted many engineering teams to evaluate reliable Postman alternatives.

Try Apidog today

For a small engineering team, collaboration is not optional. Shared workspaces, synchronized collections, repeatable tests, and fast feedback loops are part of the daily API development workflow. Moving from a free collaborative plan to a mandatory annual subscription can create a significant budget and adoption barrier.

A practical Postman alternative should preserve the essentials:

Send and inspect HTTP requests
Mock server responses
Validate API endpoints
Run automated collections
Share workspaces with teammates
Reuse existing request scripts and environment variables

Postman vs Apidog: Feature Comparison

The comparison between Postman and Apidog is especially relevant for teams affected by the new free-plan restrictions. Postman remains useful for individuals who need to send requests and inspect responses. Apidog focuses more directly on API development teams that need design, testing, mocking, and collaboration in one workspace.

The following table summarizes the plan differences described above:

Feature	Legacy tool free plan, March 2026	Apidog free plan
Team collaboration	1 user	Up to 4 active users
Automated collection runs	25 runs per month	Unlimited
API design	Basic capabilities	Visual schema builder
Mock server	Standard mocking limits	Smart, continuous cloud mock
Primary audience	Solo API consumers	Distributed API development teams

For a small team, the difference is operational as well as financial. A one-user limit makes shared ownership more difficult, while a 25-run monthly limit can interrupt automated testing before a release cycle is complete.

Why Use Apidog for API Testing?

Apidog combines API design, request debugging, mocking, and automated validation in one interface. Consolidating these activities reduces the need to maintain separate tools for API documentation and testing.

1. Build tests visually

A test workflow can be organized as a sequence of requests with dependencies between them:

Authenticate the test user.
Extract the returned token.
Pass the token to subsequent requests.
Create a resource.
Assert the response status and body.
Clean up the test data.

This structure is useful for both QA engineers and backend developers because it makes request order, variables, and assertions visible to the team.

A typical API test plan might look like this:

Authenticate
  └── Extract access_token
        └── Create resource
              ├── Assert status is 201
              ├── Assert response contains resource ID
              └── Fetch resource and validate returned fields

2. Reuse existing JavaScript

If your current collections use custom pre-request scripts, Apidog supports reusing those JavaScript snippets. Before migrating, identify which scripts are responsible for:

Generating timestamps or signatures
Creating random test data
Setting authorization values
Reading environment variables
Preparing request bodies

For example, a simple script that prepares a request value might look like this:

const timestamp = Date.now().toString();
const requestId = `test-${timestamp}`;

// Reuse the equivalent environment-variable mechanism
// provided by your API testing workspace.
console.log({ timestamp, requestId });

Review each script after import and confirm that its variables are available in the new environment. This is particularly important for authentication and dynamic data generation.

3. Keep specifications, tests, and mocks aligned

When an API specification changes, related tests and mock responses also need to change. Keeping these assets together helps reduce manual synchronization work as endpoints evolve.

A useful maintenance workflow is:

Update the endpoint or schema definition.
Review the generated or associated request.
Update assertions for changed fields.
Verify the mock response.
Run the relevant collection before merging the change.

This workflow limits the chance that documentation, mocks, and automated tests describe different versions of the same endpoint.

4. Run collections without the same monthly constraint

Apidog’s free tier supports up to four active users and unlimited test and collection runs, according to the comparison above. That allows a small team to run regression checks repeatedly during development without planning around an arbitrary monthly run limit.

Unlimited runs are useful when you need to:

Re-run a failed test while debugging
Execute a collection after every schema change
Validate multiple environments
Run a larger regression suite before release
Let several teammates verify the same fix

How to Migrate Existing Collections

Migrating tools does not need to interrupt active development. Use a staged process so that the original collections remain available until the new workspace is verified.

Step 1: Inventory your current workspace

Before exporting anything, list the assets your team actually uses:

Collections and folders
Environments
Variables and secrets
Authorization settings
Pre-request scripts
Tests and assertions
Mock configurations
Scheduled or automated runs

Separate reusable configuration from sensitive values. Do not commit access tokens or production secrets to an exported file or source repository.

Step 2: Export collections and environments

Export the collections and environment files from the existing tool and store them in a temporary, access-controlled location. Keep a copy of the original export so you can compare results if an import does not behave as expected.

For a request, verify that the following information survives the export:

{
  "method": "POST",
  "url": "https://api.example.com/resources",
  "headers": {
    "Content-Type": "application/json"
  },
  "body": {
    "name": "example"
  }
}

The exact export format depends on the source tool and collection version, but the migration checklist is the same: method, URL, headers, body, authentication, variables, scripts, and assertions should all be accounted for.

Step 3: Import into the new workspace

Use Apidog’s import tool to upload the collections and associated environment variables. After the import completes, open representative requests from each collection rather than assuming that every configuration migrated correctly.

Check at least one example of each request type:

A public GET request
An authenticated request
A request with path or query variables
A request with a JSON body
A request that depends on a previous response
A request containing a pre-request script

Step 4: Reconfigure secrets safely

Imported environment files may contain values that should not be shared with every workspace member. Replace exported credentials with safe placeholders and configure secrets using the workspace’s supported variable and permission controls.

For example:

API_BASE_URL=https://api.example.com
[REDACTED CREDENTIAL] securely>
TEST_USER_ID=<configure per environment>

Use separate values for development, staging, and production. Avoid using production credentials while validating the migration.

Step 5: Validate before switching the team

Run a representative smoke test and compare its results with the original workspace:

HTTP status codes match
Response headers are present
Response bodies contain expected fields
Variables are resolved correctly
Authentication succeeds
Assertions pass
Mock responses match the intended schema

Only after this validation should you invite the rest of the team and make the new workspace the default location for API testing.

Collaboration Setup for a Four-Person Team

The free Apidog plan supports up to four active users. A simple team setup might assign responsibilities as follows:

API designer: maintains endpoint definitions and schemas
Backend developer: implements and debugs endpoints
QA engineer: maintains assertions and regression collections
Product or integration developer: validates consumer-facing workflows

Define ownership for collections and environments before migrating. Clear ownership prevents duplicate requests, conflicting variable changes, and undocumented edits.

You can also establish a lightweight review process:

Create or update the API definition.
Add or update the corresponding request.
Add assertions for the expected behavior.
Update the mock response if the contract changed.
Ask another team member to run the collection.
Merge the change only after the test passes.

Conclusion: Choose a Postman Alternative That Fits Your Team

The March 2026 pricing change transformed a previously collaborative free plan into a single-user option, with a 25-run monthly limit and a paid Team plan priced at $19 per user per month when billed annually. For small agencies, startups, and development teams, that can make shared API testing difficult to sustain.

A reliable Postman replacement should protect both engineering velocity and the software budget. In the comparison above, Apidog addresses the main constraints by offering:

Up to four active users on the free plan
Unlimited test and collection runs
Visual API design
Integrated request testing
Smart cloud mocking
Support for reusing JavaScript snippets
A single workspace for specifications, tests, and mocks

To evaluate the migration, export a representative collection, import it into Apidog, verify authentication and assertions, and then test the workflow with your team. This staged approach lets you validate compatibility before moving all active projects.

How to use CLI-Anything: make any software agent-native

Preecha — Fri, 28 Aug 2026 02:02:11 +0000

CLI-Anything: Generate CLIs for GUI Applications Your AI Agent Can Use

CLI-Anything is an open-source plugin for AI coding agents—primarily Claude Code—that generates a full command-line interface for software with an accessible codebase. Point it at GIMP, Blender, LibreOffice, or another application, and it analyzes the source code to produce a structured CLI that an AI agent can use programmatically.

Try Apidog today

The problem: AI agents cannot use most GUI software directly

Modern software is split between two worlds that rarely connect cleanly.

API-first services such as cloud storage, payment processors, email providers, and analytics platforms expose HTTP APIs. An AI agent can call them directly with standard tools.

Professional desktop software is different. GIMP, Blender, LibreOffice, and Audacity were primarily designed for people to operate through graphical interfaces. Their capabilities are exposed through menus, buttons, and dialogs rather than structured APIs.

Connecting an AI agent to these applications usually means choosing between two imperfect approaches:

Write a custom wrapper: This can take weeks and may break when the application changes.
Use robotic process automation (RPA): RPA tools simulate clicks using screenshots, coordinates, or pixel matching. These workflows can break when layouts, themes, or display scaling change.

CLI-Anything takes a different approach. Instead of simulating GUI interactions, it analyzes the application's source code to find the APIs that the GUI already uses. It then generates a CLI that calls those APIs directly.

The agent does not need to see the screen. It issues structured commands, and the target application performs the work.

If your agent workflow also needs to call external REST APIs, Apidog handles the API testing side. It is a free tool for sending, inspecting, and organizing API requests so you can verify integrations before adding them to your agent workflow.

What CLI-Anything generates

CLI-Anything is an open-source plugin built by HKUDS, the Hong Kong University Data Science Lab. Its creator, Chao Huang, described the project this way:

"Today's software serves humans. Tomorrow's users will be agents. CLI-Anything: bridging the gap between AI agents and the world's software. One command line to make any software agent-ready."

At the time of writing, the project has more than 6,100 GitHub stars.

The plugin runs inside Claude Code and has experimental integrations for Codex and OpenCode. You point it at a software codebase, and it runs a seven-phase pipeline:

Analyze — Scan the source code, map GUI actions to underlying APIs, and produce a software-specific standard operating procedure document.
Design — Define command groups, state models, and output formats.
Implement — Build a Click-based Python CLI with REPL mode, --json output, and undo/redo support.
Plan tests — Create a TEST.md file containing unit and end-to-end test plans.
Write tests — Generate test_core.py for unit tests with synthetic data and test_full_e2e.py for tests using real files.
Document — Run pytest and append the results to TEST.md.
Publish — Create setup.py, configure console-script entry points, and install the CLI on your PATH.

After phase seven, you have a working CLI installed locally. For example:

which cli-anything-gimp
cli-anything-gimp --help

Generated CLIs follow a consistent design:

Human-readable table output by default
Machine-readable JSON output with --json
Persistent project state
Undo/redo support
Interactive REPL mode

This consistency means an AI agent can reuse the same interaction patterns across different applications.

Install CLI-Anything

CLI-Anything is a Python-based plugin, not an npm package. You install it into your AI coding agent. The generated CLIs are Python packages installed with pip install -e ..

Requirements

Python 3.10 or later
The target application installed on your system
A supported AI coding agent:
- Claude Code is the primary platform
- Codex and OpenCode integrations are experimental

Claude Code

In Claude Code, add the marketplace and install the plugin:

/plugin marketplace add HKUDS/CLI-Anything
/plugin install cli-anything

This adds the /cli-anything slash commands to your Claude Code session.

OpenCode

Clone the repository, then copy the command files and HARNESS.md to:

~/.config/opencode/commands/

This adds the following commands:

/cli-anything
/cli-anything-refine
/cli-anything-test
/cli-anything-validate
/cli-anything-list

Codex

Run the installation script:

bash CLI-Anything/codex-skill/scripts/install.sh

Qodercli

Run the Qodercli setup script:

bash CLI-Anything/qoder-plugin/setup-qodercli.sh

Windows

The plugin requires Git for Windows, which includes bash and cygpath, or WSL. Native Windows shell is not supported.

If you see this error:

cygpath: command not found

Install Git for Windows and retry.

Install a generated CLI

After CLI-Anything generates a harness, install it from the agent-harness directory:

cd <software>/agent-harness
pip install -e .

Editable mode means changes to the generated source remain available without reinstalling the package.

Generate your first CLI

Once the plugin is installed, generation requires a single command.

For a local GIMP codebase:

/cli-anything ./gimp

For a GitHub repository:

/cli-anything https://github.com/blender/blender

The plugin starts the seven-phase pipeline. Generation takes a few minutes depending on the size of the codebase and the number of API surfaces it exposes.

What happens during analysis

During phase one, CLI-Anything reads the source code and maps GUI actions to their underlying API calls.

For GIMP, this can include operations such as:

Creating layers
Applying filters
Exporting files
Managing projects

The plugin writes a software-specific SOP document, such as GIMP.md, describing the supported operations.

During phase three, it builds the CLI with Python's Click framework. Commands support --json output, and stateful operations—such as opening a file or creating a project—store state in a JSON file. The generated CLI also includes an interactive REPL with colored prompts and persistent history.

Generated directory structure

A generated GIMP CLI may look like this:

gimp/
  agent-harness/
    GIMP.md           # Software SOP document
    setup.py
    cli_anything/     # Namespace package; no __init__.py (PEP 420)
      gimp/
        README.md
        gimp_cli.py   # Main CLI entry point
        core/         # Project, session, and export modules
        utils/        # REPL skin and helpers
        tests/
          test_core.py
          test_full_e2e.py
          TEST.md

All generated CLIs use the cli_anything.* namespace. For example:

cli_anything.gimp

This helps prevent naming conflicts when you generate CLIs for multiple applications.

Use the generated CLI

After installing the generated package, inspect the available commands:

cd gimp/agent-harness
pip install -e .

cli-anything-gimp --help

The naming convention is:

cli-anything-<software>

Human-readable output

Human-readable output is the default:

# Start a new project
cli-anything-gimp project new --width 1920 --height 1080

# List layers
cli-anything-gimp layer list

# Add a layer
cli-anything-gimp layer add \
  --name "Background" \
  --type solid \
  --color "#ffffff"

# Apply a filter
cli-anything-gimp filter apply \
  --name "gaussian-blur" \
  --radius 3

# Export the project
cli-anything-gimp export save \
  --format png \
  --output ./output.png

JSON output for AI agents

Use --json when the caller needs machine-readable responses:

cli-anything-gimp --json project new \
  --width 1920 \
  --height 1080

Example response:

{
  "status": "ok",
  "project_id": "proj_abc123",
  "width": 1920,
  "height": 1080
}

Another command might return:

cli-anything-gimp --json layer add -n "Background"

{
  "status": "ok",
  "layer_id": "layer_001",
  "name": "Background"
}

The JSON format includes a status field, operation-specific fields, and error details when an operation fails.

Interactive REPL mode

For longer sessions, start the CLI without a subcommand:

cli-anything-gimp

The REPL provides colored prompts, tab completion, and persistent history. It is useful for exploring commands interactively before turning them into scripts or agent actions.

Undo and redo

State-changing operations support a 50-level undo stack:

cli-anything-gimp undo
cli-anything-gimp redo

Refine and test the generated CLI

The first generated CLI may not cover every capability of the target application. CLI-Anything provides commands for gap analysis, testing, and validation.

Refine the CLI

Run a general refinement pass:

/cli-anything:refine /home/user/gimp

This compares the existing CLI with the application's API surface, identifies missing operations, and adds commands for the gaps.

You can also focus refinement on a specific area:

/cli-anything:refine /home/user/blender "particle systems and physics simulation"

The focused version targets the specified part of the codebase instead of re-analyzing everything.

Run the test suites

/cli-anything:test /home/user/gimp

This runs the test suites and updates TEST.md with the results. The project reports more than 1,508 passing tests across 11 applications with a 100% pass rate.

Validate the harness

/cli-anything:validate /home/user/gimp

Validation checks the generated CLI harness against the HARNESS.md specification and verifies that it meets the required structural conventions.

List generated CLIs

List all available CLIs:

/cli-anything:list

Request machine-readable output:

/cli-anything:list --json

Search in a specific directory:

/cli-anything:list --path /home

Practical use cases

CLI-Anything has been demonstrated with 11 applications. The following examples show how the generated commands can fit into real workflows.

Batch image processing with GIMP

An AI agent can resize product images, apply a watermark, and export multiple formats without interacting with the GUI:

cli-anything-gimp project open --file product.jpg

cli-anything-gimp layer add \
  --name "Watermark" \
  --type image \
  --source watermark.png

cli-anything-gimp layer position \
  --name "Watermark" \
  --x 10 \
  --y 10

cli-anything-gimp export save \
  --format webp \
  --output product-final.webp

The same command pattern can be applied repeatedly in a batch script.

Document generation with LibreOffice

LibreOffice can generate PDFs from templates. An agent can populate invoice, report, or contract data and export the result:

cli-anything-libreoffice document open \
  --template invoice-template.ods

cli-anything-libreoffice cell set \
  --address "B5" \
  --value "Acme Corp"

cli-anything-libreoffice cell set \
  --address "C10" \
  --value "1500.00"

cli-anything-libreoffice export pdf \
  --output invoice-2026-001.pdf

3D rendering with Blender

Blender render jobs can be configured and started without opening the GUI:

cli-anything-blender scene open \
  --file product-scene.blend

cli-anything-blender render set \
  --samples 256 \
  --output /renders/product

cli-anything-blender render start \
  --format png

Streaming automation with OBS Studio

OBS workflows can be scripted for scene changes and recording controls:

cli-anything-obs scene set --name "Main Camera"
cli-anything-obs recording start
cli-anything-obs scene set --name "Screen Share"
cli-anything-obs recording stop --output session.mp4

CI/CD integration

Generated CLIs can run in CI/CD pipelines. For example:

Render a Blender scene on every commit.
Generate PDF release notes from a LibreOffice template.
Process image assets during a build.
Run the generated CLI's tests as part of validation.

Combine local CLIs with external APIs

CLI-Anything handles local desktop software. Production agent workflows often need external APIs as well—for example:

Upload a processed image to a CDN.
Send a generated PDF to a document management system.
Upload a rendered video to a review platform.

Apidog handles the API testing side. It is a free API client for testing, documenting, and automating REST API calls.

For example, suppose you are building an agent that processes product images with GIMP and uploads them to cloud storage. CLI-Anything gives the agent the GIMP commands, while Apidog helps you verify the storage API before writing the integration.

In Apidog, you can:

Create an environment and store API credentials as variables.
Test the upload endpoint with a sample file.
Verify that the request format is correct.
Add assertions that confirm the response includes the expected file URL.
Export the working request as a curl command or code snippet.
Add the request to your agent script.

This separates two potential failure points. You can confirm that the external API works before debugging the GIMP workflow and the API integration at the same time.

Apidog also supports automated test suites. Once the workflow works, add assertions that run during each execution to catch regressions.

Limitations

Windows requires Git Bash or WSL

Generated CLIs are Python applications that rely on bash-style path handling. Windows users need Git for Windows, which includes Bash and cygpath, or WSL. Native PowerShell is not supported.

The target software must already be installed

CLI-Anything does not bundle the applications it wraps. GIMP, Blender, LibreOffice, and other target applications must be installed on the same machine as the generated CLI.

The CLI calls the real application backends directly.

Generated CLIs are Python-only

CLI-Anything generates Python Click applications. It does not generate wrappers in other languages. If you need a Node.js or Go CLI, you must build that wrapper separately.

Claude Code is the stable platform

Claude Code is the primary and most-tested environment. Codex and OpenCode integrations are experimental, so behavior may vary outside Claude Code.

Generation quality depends on the codebase

The plugin must identify the APIs behind GUI actions. If the codebase is poorly structured, heavily obfuscated, or tightly coupled to GUI state, the analysis may miss commands or produce incomplete wrappers.

The refinement workflow can improve coverage, but complex proprietary software may be more difficult to wrap cleanly.

FAQ

Does CLI-Anything work with any software?

In principle, CLI-Anything can generate a CLI for software with an accessible codebase. In practice, it works best with open-source applications where GUI actions map clearly to underlying API calls.

The project has demonstrated support for:

GIMP
Blender
Inkscape
Audacity
Kdenlive
Shotcut
OBS Studio
Draw.io
LibreOffice
AnyGen
Zoom

Is the project free to use?

Yes. CLI-Anything is MIT licensed and fully open source at github.com/HKUDS/CLI-Anything.

Do I need to know Python?

No. The plugin generates the Python code for you. You do need Python 3.10 or later installed to run the generated CLIs.

Can I call the generated CLI from my own code?

Yes. The generated CLI is a standard command-line tool. You can call it from:

Shell scripts
Makefiles
Python programs
CI/CD jobs
Any program that can run a subprocess

What is `HARNESS.md`?

HARNESS.md defines the expected structure of a CLI-Anything-generated harness. It covers command structure, output formats, testing requirements, and packaging.

The validation command checks the generated CLI against this specification.

Can I generate CLIs for internal tools?

Yes. You can point the plugin at any local codebase, including private internal tools. The plugin runs locally and does not send your source code elsewhere.

How does CLI-Anything compare with Model Context Protocol (MCP)?

MCP connects AI agents to external services through a standardized server protocol. CLI-Anything generates local CLI wrappers for GUI applications that do not expose usable APIs.

They solve different problems. You can use both:

MCP for cloud and external services
CLI-Anything for local desktop software

Additional resources

CLI-Anything GitHub repository
CLI-Anything official website
Community guide
Apidog free API client

How to install and use the Resend CLI

Preecha — Fri, 28 Aug 2026 01:01:45 +0000

Resend CLI: Send and Manage Email from the Terminal

The Resend CLI is the official command-line tool for Resend, an email platform built for developers. Install it with npm install -g resend-cli or brew install resend/cli/resend, authenticate with resend login, and then send emails, manage domains, and automate email infrastructure from a terminal or CI/CD pipeline.

Try Apidog today

What is Resend?

Resend is an email API for developers. Connect a domain, create an API key, and start sending transactional emails from your application, including password resets, order confirmations, and onboarding messages.

On March 13, 2026, Resend founder Zeno Rocha shipped the Resend CLI, bringing the same infrastructure to the terminal. The CLI has 53 commands across 13 resources, is written in TypeScript, and is fully open source under the MIT license.

It supports three common use cases:

Humans: Interactive prompts, readable tables, and natural-language scheduling such as tomorrow at 9am
AI agents: JSON output, idempotency keys, and automatic agent detection
CI/CD pipelines: Environment-variable authentication, scriptable flags, and consistent exit codes

If you're building an application that sends email, test your email API calls before they reach production. Apidog provides a visual interface for testing REST APIs, including Resend's email API. You can import the Resend OpenAPI specification, configure environments, and run organized test suites without writing additional test code.

Installing the Resend CLI

Choose the installation method that best fits your environment.

Install with cURL

This method downloads a standalone binary and does not require Node.js:

curl -fsSL https://resend.com/install.sh | bash

The installer downloads a prebuilt binary for your operating system and places it on your PATH.

Install with npm

The npm package requires Node.js 20 or later:

npm install -g resend-cli

Verify the installation:

resend --version

Install with Homebrew

On macOS or Linux, install the CLI with Homebrew:

brew install resend/cli/resend

Homebrew also handles future updates.

Install on Windows with PowerShell

Run the PowerShell installer:

irm https://resend.com/install.ps1 | iex

You can also download .exe binaries directly from the GitHub Releases page.

Build the CLI locally

To contribute to the CLI or build it from source, install Node.js 20 or later and pnpm:

git clone https://github.com/resend/resend-cli.git
cd resend-cli
pnpm install
pnpm build       # outputs ./dist/cli.cjs
pnpm build:bin   # native binary at ./dist/resend

Authenticating your account

Run resend login to connect the CLI to your Resend account:

resend login

The command opens your browser and guides you through creating an API key in the Resend dashboard. Credentials are stored locally at:

~/.config/resend/credentials.json

The file uses restricted 0600 permissions.

For CI/CD pipelines and other non-interactive environments, pass an API key directly:

resend login --key re_xxxxxxxxxxxxx

After authentication, the CLI resolves API keys in this order:

The --api-key flag
The RESEND_API_KEY environment variable
The stored credentials file

For CI pipelines, store RESEND_API_KEY as a secret environment variable:

RESEND_API_KEY=re_xxx \
  resend emails send \
  --from builds@yourco.com \
  --to dev@yourco.com \
  --subject "Build passed" \
  --text "All tests green."

Use multiple accounts

If you work with multiple Resend organizations or teams, switch between stored profiles without logging out:

resend auth switch

You can also select a profile for one command:

resend <command> --profile production

Sending your first email

The main sending command is resend emails send. At minimum, provide:

A sender address from a verified domain
A recipient
A subject
A message body

Send a plain-text email

resend emails send \
  --from "you@yourdomain.com" \
  --to recipient@example.com \
  --subject "Hello from the CLI" \
  --text "This is a test email sent from the Resend CLI."

Send an HTML email

Pass HTML inline with --html:

resend emails send \
  --from "team@yourco.com" \
  --to user@example.com \
  --subject "Your order is confirmed" \
  --html "<h1>Order confirmed</h1><p>Thanks for your purchase.</p>"

For larger templates, use --html-file:

resend emails send \
  --from "team@yourco.com" \
  --to user@example.com \
  --subject "Welcome aboard" \
  --html-file ./templates/welcome.html

Schedule delivery

The CLI accepts natural-language dates as well as ISO 8601 timestamps:

resend emails send \
  --from "you@yourco.com" \
  --to user@example.com \
  --subject "Scheduled check-in" \
  --text "Just checking in." \
  --schedule "tomorrow at 9am"

Other supported formats include:

in 1 hour
next Monday at 3pm
A complete ISO 8601 timestamp

Capture the email ID

When output is piped, the CLI automatically switches to JSON output. Use jq to extract the email ID:

EMAIL_ID=$(resend emails send \
  --from a@acme.com \
  --to b@acme.com \
  --subject "Test" \
  --text "Hi" | jq -r '.data.id')

echo "Sent email: $EMAIL_ID"

You can use the ID for follow-up operations.

Cancel or update a scheduled email

Cancel a scheduled email:

resend emails cancel "$EMAIL_ID"

Update its schedule:

resend emails update "$EMAIL_ID" --schedule "next Monday at 10am"

List recent emails

resend emails list

Send a batch of emails

The CLI supports batches of up to 100 emails. Create a JSON file containing an array of email objects:

[
  {
    "from": "you@yourco.com",
    "to": "alice@example.com",
    "subject": "Hi Alice",
    "text": "Hello!"
  },
  {
    "from": "you@yourco.com",
    "to": "bob@example.com",
    "subject": "Hi Bob",
    "text": "Hello!"
  }
]

Send the batch:

resend emails send-batch --file emails.json

Each batch request counts as one API call against your rate limit, even when it sends up to 100 emails.

Managing domains and API keys

You need a verified domain before you can send email. The CLI supports the complete domain setup and verification workflow.

Add a domain

resend domains create \
  --name yourdomain.com \
  --region us-east-1

Supported regions are:

us-east-1
eu-west-1
sa-east-1
ap-northeast-1

Choose the region closest to your users to minimize latency.

Verify DNS records

After you create a domain, Resend provides DNS records to add to your DNS provider, including SPF, DKIM, and DMARC records.

Start verification with:

resend domains verify --id <domain-id>

Check the domain status:

resend domains get --id <domain-id>

Poll the status until it returns verified.

Configure tracking and TLS

Run the interactive configuration command:

resend domains configure --id <domain-id>

This lets you configure options such as open tracking, click tracking, and custom DKIM.

List domains

resend domains list

Manage API keys

Create scoped API keys for individual services or environments instead of sharing one key everywhere:

resend api-keys create  # Interactive, lets you scope per domain
resend api-keys list
resend api-keys delete --id <key-id>

A key scoped to one domain cannot access your other domains or account settings.

Advanced features

In addition to individual emails, the CLI supports broadcasts, webhooks, templates, contacts, and audiences.

Broadcasts

Create a broadcast draft, then send or schedule it:

resend broadcasts create   # Interactive draft creation
resend broadcasts send --id <broadcast-id>
resend broadcasts schedule \
  --id <broadcast-id> \
  --date "next Monday at 10am"

Webhooks

Webhooks provide real-time delivery events such as bounces, opens, clicks, and spam reports.

Create and list webhook endpoints:

resend webhooks create   # Register a new endpoint
resend webhooks list

For local development, forward webhook events to a local endpoint:

resend webhooks listen \
  --forward-to http://localhost:3000/webhooks/resend

This avoids setting up ngrok or similar tunneling tools. The CLI supports 17 event types, including:

email.sent
email.delivered
email.bounced
email.opened
email.clicked

Templates

Create reusable HTML templates with dynamic variables:

resend templates create  # Interactive template builder

Template variables use the {{variable_name}} syntax with fallback values. Reference a template by ID when sending emails.

Contacts and audiences

Resend also provides contact management for marketing emails:

resend contacts create \
  --audience-id <id> \
  --email user@example.com \
  --first-name "Alice"

resend contacts list --audience-id <id>

resend contacts update \
  --id <contact-id> \
  --unsubscribed false

Run diagnostics

The doctor command checks your local setup:

resend doctor

It verifies your CLI version, API key validity, and verified domains. It can also detect AI coding agents such as Cursor, Claude Desktop, VS Code, and OpenClaw.

Using Resend CLI in CI/CD pipelines

The CLI is designed for automated environments. Use non-interactive authentication, machine-readable output, and automatic confirmation flags in scripts.

Use machine-readable output

Pass --json to force structured JSON output:

resend emails send \
  --from a@co.com \
  --to b@co.com \
  --subject "Deploy" \
  --text "Done" \
  --json

The CLI also automatically uses JSON when its output is piped.

The --quiet flag suppresses spinners and progress indicators:

resend emails list --quiet | jq '.[0].id'

Skip confirmation prompts

Use --yes for destructive operations in scripts:

resend api-keys delete --id <key-id> --yes

GitHub Actions example

Store the API key in GitHub Actions secrets and expose it only to the step that needs it:

- name: Send deployment notification
  env:
    RESEND_API_KEY: ${{ secrets.RESEND_API_KEY }}
  run: |
    resend emails send \
      --from deploys@yourco.com \
      --to team@yourco.com \
      --subject "Deploy to production: ${{ github.sha }}" \
      --text "Deployed commit ${{ github.sha }} to production."

Account for rate limits

The Resend API rate limit is two requests per second, shared across all API keys for your team.

When sending multiple messages, prefer send-batch—which supports up to 100 emails per call—instead of looping over individual send commands.

Testing your email API with Apidog

The Resend CLI works well for interactive development and simple scripts. If your backend calls Resend's REST API directly, an API client can help you explore and test the integration before writing application code.

Apidog lets you send HTTP requests, inspect responses, organize test cases, and configure separate environments for different API keys and settings.

A typical workflow looks like this:

1. Import the Resend API specification

Resend provides API reference documentation at resend.com/docs. Import the API specification into Apidog to organize the available endpoints and view their request and response schemas.

2. Configure environments

Create development and production environments. Store your RESEND_API_KEY as an environment variable and reference it in requests with:

{{RESEND_API_KEY}}

You can switch between environments without manually replacing credentials.

3. Test the sending request

Before implementing the integration in your application, run the POST /emails endpoint with the payload you plan to use.

Verify:

The response status
The returned email ID
Required-field validation
Invalid-address behavior
Other edge cases relevant to your application

4. Automate API tests

Use Apidog's test runner to chain requests and assert response values. For example, a test can:

Send a test email
Retrieve it by ID
Verify its status

This catches integration problems before they reach production. Combined with the Resend CLI for local development, you have a terminal workflow for quick checks and an API testing environment for repeatable integration tests.

Resend pricing

The CLI is free and open source. Pricing applies to the Resend platform:

Plan	Price	Monthly emails	Daily limit	Log retention
Free	$0/month	3,000	100/day	1 day
Pro	$20/month	50,000	No limit	3 days
Scale	$90/month	100,000	No limit	7 days
Enterprise	Custom	Custom	Custom	Custom

Important free-tier details:

The 100-email-per-day limit makes the free plan suitable for testing and small projects, not production traffic.
Analytics such as open and click tracking require a paid plan.
Log retention is limited to one day, so old email status may not be retrievable after 24 hours.
The rate limit is two requests per second for all plans, shared across your team.
Overage on paid plans is capped at five times the monthly quota to help prevent unexpected bills.

Dedicated IPs are available as a $30/month add-on on the Scale plan when sending more than 500 emails per day.

FAQ

Do I need Node.js to install the Resend CLI?

Not when using cURL or Homebrew, which install prebuilt standalone binaries. The npm installation requires Node.js 20 or later.

Why can't I send from any email address?

Resend requires a verified domain. You must own the domain, add the SPF, DKIM, and DMARC records provided by Resend, and complete verification. Free email providers such as Gmail are not supported as sender addresses.

Can I send to any email address on the free plan?

Yes. The free plan does not restrict recipients, but it limits you to 3,000 emails per month and 100 emails per day.

How does natural-language scheduling work?

The CLI parses phrases such as tomorrow at 9am, in 2 hours, and next Friday at 3pm, as well as standard ISO 8601 timestamps. Unless you specify otherwise, times are interpreted in your system's local timezone.

What happens when I pipe output?

The CLI detects when output is being piped and automatically switches to JSON-only output without spinners or prompts. You do not need to pass --json explicitly.

Can I use the CLI with multiple Resend accounts?

Yes. Run resend login multiple times to store different profiles. Then use resend auth switch to change profiles, or pass --profile <name> to a specific command.

Is the Resend CLI open source?

Yes. It is MIT licensed and hosted at github.com/resend/resend-cli.

What's the difference between `--quiet` and `--json`?

Both produce JSON output. --json forces JSON mode, while --quiet suppresses spinners and progress indicators and also implies JSON mode. In practice, they use the same output format; --quiet additionally removes non-data output.

Additional resources

Resend CLI GitHub repository
Resend documentation
Resend pricing
Resend changelog
Apidog free API client

How to install and use the Context7 CLI

Preecha — Thu, 27 Aug 2026 14:01:55 +0000

Context7 injects up-to-date library documentation directly into your AI coding assistant's context, helping it avoid generating code from stale training data. The ctx7 CLI runs with npx ctx7 without installation and connects to Claude Code, Cursor, or OpenCode with a single ctx7 setup command.

Try Apidog today

What is Context7 and why does it matter?

AI coding assistants can generate code that looks correct but uses APIs that no longer exist:

Function signatures may be outdated.
Import paths may have changed.
Examples may target an older major version.
Deprecated APIs may still appear in generated code.

This happens because LLMs are trained on data with a cutoff date. They may not know about recent changes, such as a framework changing its layout system or a library deprecating a large part of its API.

Context7 solves this by indexing documentation for more than 9,000 libraries and serving it to your AI assistant in real time. When you ask your coding agent a question, Context7 fetches current, version-specific documentation and adds it to the model's context before it generates a response.

The result is code that is more closely aligned with the APIs and documentation available today.

The ctx7 CLI is Context7's command-line interface. It can:

Fetch library documentation from your terminal
Manage AI coding skills, which are reusable prompt files for your agent
Configure the Context7 MCP server for Claude Code, Cursor, or OpenCode

If you're building API integrations alongside your development work, Apidog handles the API testing side. It's a free client for sending, organizing, and automating API requests. Context7 keeps your AI assistant's knowledge current, while Apidog helps you verify the API calls your application makes.

Install `ctx7`

The only requirement is Node.js 18 or later. Check your installed version:

node --version

Run without installing

Use npx to try the CLI without installing it globally:

npx ctx7 --help
npx ctx7 library react

npx downloads the latest version when you run the command. This is convenient for occasional use.

Install globally

For regular use, install ctx7 globally:

npm install -g ctx7
ctx7 --version

Global installation lets you run commands locally without the npx download overhead.

Set up Context7 for your AI coding agent

The ctx7 setup command connects Context7 to your AI coding environment. It authenticates through OAuth, generates an API key, and writes the configuration to the appropriate location.

Run the interactive setup

ctx7 setup

The CLI prompts you to select your agent and preferred mode:

CLI + Skills
MCP

To accept the default options without prompts:

ctx7 setup --yes

Target a specific agent

Use an agent-specific flag when you already know which environment you want to configure:

ctx7 setup --claude     # Claude Code (~/.claude/skills or MCP config)
ctx7 setup --cursor     # Cursor (~/.cursor/skills or MCP config)
ctx7 setup --opencode   # OpenCode

Use an existing API key

If you already have a Context7 API key from context7.com/dashboard, pass it during setup:

ctx7 setup --api-key YOUR_API_KEY

Configure a project instead of your whole system

By default, ctx7 setup installs configuration globally. To configure only the current project:

ctx7 setup --project

Choose between CLI + Skills and MCP

Context7 supports two setup modes.

CLI + Skills mode

CLI + Skills mode installs a SKILL.md file that instructs your AI agent to fetch documentation by running ctx7 commands.

When the agent needs library documentation, it can run commands such as:

ctx7 library react
ctx7 docs /facebook/react "useEffect cleanup"

No MCP server is required.

Install the skill for a specific agent:

ctx7 setup --cli --claude
ctx7 setup --cli --cursor
ctx7 setup --cli --universal

The universal option installs the skill at:

~/.config/agents/skills

MCP Server mode

MCP mode registers Context7 as a Model Context Protocol server. Your agent can then call resolve-library-id and query-docs natively, without running CLI commands explicitly.

An MCP configuration looks like this:

{
  "url": "https://mcp.context7.com/mcp",
  "headers": {
    "CONTEXT7_API_KEY": "YOUR_API_KEY"
  }
}

You can also add Context7 to Claude Code from the command line:

claude mcp add --scope user context7 -- npx -y @upstash/context7-mcp --api-key YOUR_API_KEY

MCP mode makes documentation fetching less visible in your workflow because the agent calls the tools directly.

Authenticate with Context7

Use these commands to manage your Context7 session:

ctx7 login    # OAuth browser login
ctx7 whoami   # Confirm your current session
ctx7 logout   # Remove stored credentials

You can also provide your API key through an environment variable:

export CONTEXT7_API_KEY=your_key_here

Disable telemetry

Context7 collects anonymous usage data by default. To disable it:

export CTX7_TELEMETRY_DISABLED=1

Fetch library documentation from the terminal

You can use ctx7 as a standalone documentation lookup tool, even without an AI coding agent.

Two commands provide the main workflow:

Resolve a library name.
Fetch documentation for a topic.

Resolve a library

Search the Context7 index with ctx7 library:

ctx7 library react
ctx7 library nextjs "app router setup"
ctx7 library prisma "database relations"
ctx7 library express --json

The command returns the library's canonical ID and metadata, including snippet count, source reputation, benchmark scores, and version identifiers.

For example:

Library: /vercel/next.js
Snippets: 4,820
Reputation: high
Version: 15.2.0

Fetch documentation

Pass the canonical library ID to ctx7 docs with a topic query:

ctx7 docs /facebook/react "useEffect cleanup"
ctx7 docs /vercel/next.js "middleware authentication"
ctx7 docs /prisma/prisma "one-to-many relations"
ctx7 docs /facebook/react "hooks" --json

The command returns documentation snippets relevant to your query from the current indexed version.

If you already know the library ID, skip the search step and call ctx7 docs directly.

You can also pipe the output into a file or another command for further processing:

ctx7 docs /facebook/react "hooks" --json > react-hooks.json

Manage AI coding skills

Skills are SKILL.md files that give an AI agent specialized knowledge or behavior. Think of them as instruction manuals for a particular task or library.

Context7 provides a registry of community-contributed skills. You can search for skills, install them, generate custom skills, and remove installed skills.

Search for skills

ctx7 skills search pdf
ctx7 skills search "stripe payments"
ctx7 skills search "react testing"

Install a skill

Install a skill for your current environment:

ctx7 skills install /anthropics/skills pdf

Target a specific agent:

ctx7 skills install /anthropics/skills pdf --cursor
ctx7 skills install /anthropics/skills pdf --claude

To make the skill available across all projects, install it globally:

ctx7 skills install /anthropics/skills pdf --global

Get skill suggestions for a project

The suggest command scans your project directory, detects the libraries and frameworks you're using, and recommends relevant skills:

ctx7 skills suggest

This is useful when starting a project and building an initial set of agent instructions.

List installed skills

ctx7 skills list              # List all installed skills
ctx7 skills list --claude     # List Claude Code skills
ctx7 skills list --cursor     # List Cursor skills

Remove a skill

ctx7 skills remove pdf

Generate a custom skill

With a paid account, you can generate a custom skill from a library in the Context7 index:

ctx7 login
ctx7 skills generate

The CLI walks you through an interactive prompt where you select a library and describe what you want the skill to teach your agent. Context7 then generates a SKILL.md file based on the library's current documentation.

Generated skills are portable. The SKILL.md format follows the Agent Skills standard, so a skill generated for Claude Code can also work in Cursor, VS Code Copilot, OpenCode, and other Agent Skills-compatible tools.

Free accounts include 6 skill generations per week. Pro accounts include 10.

Command aliases

Use these aliases for shorter commands:

Full command	Alias
`ctx7 skills install`	`ctx7 si`
`ctx7 skills search`	`ctx7 ss`
`ctx7 skills generate`	`ctx7 skills gen` or `ctx7 skills g`

Use Context7 in AI prompts

After setting up Context7, you can use it in several ways during development.

Use the `use context7` pattern

In MCP mode, append use context7 to prompts where you need current documentation:

Create a Next.js middleware that checks for a valid JWT in cookies and redirects
unauthenticated users to /login. use context7

Set up a Prisma schema with user and post models and a one-to-many relation. use context7

How do I configure the App Router layout in Next.js 15? use context7

The agent calls Context7's resolve-library-id and query-docs tools, fetches the relevant documentation, and uses it to ground the response.

Reference a specific library

When a prompt involves multiple libraries, specify the library IDs explicitly:

Implement Supabase authentication in a Next.js app.

Use library /supabase/supabase for Supabase and /vercel/next.js for
Next.js routing.

This skips the library-matching step and sends the request directly to the specified documentation sources.

Automatically invoke Context7

You can add an instruction to your AI agent so it fetches documentation automatically whenever it generates code that uses a third-party library.

For Claude Code, add this to CLAUDE.md:

Always use Context7 MCP tools when generating code that uses third-party libraries.
Resolve the library ID and fetch current docs before writing any implementation.
Do this without waiting for me to ask.

For Cursor, add the equivalent rule under Settings > Rules for AI:

When writing code that uses external libraries or frameworks, always invoke
Context7 to fetch current documentation before generating the implementation.

Pair Context7 with Apidog for API confidence

Context7 keeps your AI assistant's library knowledge current, but current documentation is only part of an API integration workflow. You also need to verify that the HTTP requests and responses behave as expected.

Apidog is a free API client for:

Sending requests
Inspecting responses
Managing environments
Storing API keys as variables
Running repeatable test suites
Adding response assertions

A practical workflow looks like this:

Use Context7 to give your AI agent current documentation for the framework or SDK.
Use Apidog to call the third-party API directly.
Inspect the response structure and status codes.
Compare the tested request with the payload your application generates.
Add repeatable tests for the integration.

For example, when building a Next.js application that calls a third-party API, Context7 can provide current Next.js documentation so the generated code uses the correct APIs. Apidog lets you test the third-party endpoint directly, verify the response structure, and confirm that your payload matches the API's expectations.

The same approach works when integrating a library with its own HTTP API. Use Context7 to look up the current SDK documentation, then use Apidog to test the raw endpoints and understand their behavior before writing application code.

When debugging an integration, send the exact request your application constructs in Apidog. Inspect the raw response to determine whether the issue is in your request logic or in the API's behavior.

You can also create Apidog environments with API keys stored as variables, switch between development and production values, and run assertions against every response. Context7 provides current documentation, while Apidog helps verify actual API behavior.

Pricing and rate limits

The ctx7 CLI is free to use. Rate limits and feature access depend on your Context7 plan:

Plan	Price	API calls/month	Rate limit	Private repositories
Free	$0	1,000	60 requests/hour	No
Pro	$7/seat/month	5,000/seat	60/hour/seat	Yes ($15/1M tokens to parse)
Enterprise	Custom	5,000/seat	Custom	Yes ($25/1M tokens)

Free-tier notes

After reaching the monthly limit, you receive 20 bonus API calls per day until the month resets.
Private repository access requires Pro or higher.
Skill generation includes 6 generations per week on Free and 10 per week on Pro.
Pro supports a maximum of 20 members.

One important limitation is that Context7 routes queries through Upstash's servers. It does not provide an offline mode, so it won't work in an environment without internet access.

Documentation responses can also be large and consume part of your LLM's context window. On complex projects with many library queries, this usage can add up.

Get a free API key at context7.com/dashboard. An API key provides higher rate limits than unauthenticated requests.

FAQ

Does Context7 send my code to its servers?

No. Only the library name and query text are sent to Context7's servers. Your code, conversation history, and sensitive data are not sent. Your codebase remains with your LLM provider.

What libraries does Context7 support?

The index covers more than 9,000 public libraries and frameworks. Search the index at context7.com to check whether a library is available. New libraries can be submitted through /add-library in the Context7 interface.

How current is the documentation?

Libraries are re-indexed periodically. Very recent releases, including releases from the past few days, may not be available yet. For stable libraries, the documentation is typically up to date with the latest release.

Does it work without an API key?

Basic usage works without an API key, but with lower rate limits. For regular use, register at context7.com and set CONTEXT7_API_KEY for higher throughput.

Which editors and agents does it support?

Context7 works with Claude Code, Cursor, OpenCode, VS Code Copilot, Windsurf, Claude Desktop, and other clients that support MCP or the Agent Skills standard.

What's the difference between CLI + Skills mode and MCP mode?

In CLI + Skills mode, a skill file tells your agent to run ctx7 commands explicitly when it needs documentation.

In MCP mode, your agent calls Context7's tools natively through the MCP protocol. MCP mode is more transparent and does not require an explicit use context7 prompt once configured.

Can I use `ctx7` without an AI coding agent?

Yes. The ctx7 library and ctx7 docs commands work as standalone terminal tools, so you can look up library documentation without an AI coding agent.

Additional resources

Context7 GitHub repository
Context7 documentation
CLI documentation
Plans and pricing
API key dashboard
Apidog free API client

How Can You Install Firecrawl CLI and Use Firecrawl CLI

Preecha — Thu, 27 Aug 2026 13:01:24 +0000

Firecrawl CLI: A Practical Guide to Scraping, Searching, Crawling, and Browser Automation

Firecrawl CLI is a terminal-native tool for AI agents and developers. It can scrape, search, map, crawl, and automate browser sessions while saving clean Markdown, JSON, screenshots, and HTML directly to your filesystem. Run it with npx firecrawl-cli without a permanent installation, or install it globally and connect it to Claude Code, Cursor, or OpenCode with a single initialization command.

Try Apidog today

AI agents need reliable, current web data, but custom scrapers often break on JavaScript-rendered pages, dynamic sites, and protected flows. Firecrawl CLI combines web scraping, search, site mapping, recursive crawling, and cloud browser sessions in one tool.

The CLI writes results to local files instead of sending large payloads directly to your terminal. That makes it easy to search output with standard shell tools, keep LLM context focused, and build repeatable research pipelines.

This guide covers:

Preparing your environment
Installing and authenticating Firecrawl CLI
Scraping pages and selecting output formats
Searching and mapping websites
Crawling sites recursively
Automating browser sessions
Integrating with AI coding agents
Troubleshooting and operational best practices

Why Use Firecrawl CLI?

Firecrawl CLI renders JavaScript through cloud browsers and is designed for sites that basic HTTP clients, Cheerio-based scrapers, or simple Puppeteer scripts may not handle reliably. It returns LLM-friendly Markdown by default, removing much of the navigation, advertising, and boilerplate content that consumes context-window space.

The CLI supports:

Web scraping
Web search with optional result scraping
URL discovery through site maps
Recursive site crawling
Screenshots and full-page screenshots
Cloud browser sessions
Markdown, JSON, HTML, links, and image outputs
Local file output for shell scripts and agent workflows

For example, adding --only-main-content to a scrape can significantly reduce irrelevant output:

firecrawl scrape https://example.com --only-main-content

Prepare Your Environment

Firecrawl CLI depends on modern Node.js and npm features. Verify that Node.js 18 or later is installed:

node --version

If the version is too old, update Node.js with your package manager or with nvm.

Create a dedicated workspace for output files:

mkdir firecrawl-cli-projects
cd firecrawl-cli-projects

A separate directory keeps generated datasets organized and makes them easy to track with Git.

If you do not want telemetry enabled, set the environment variable before running the CLI:

export FIRECRAWL_NO_TELEMETRY=1

Install Firecrawl CLI

Initialize Firecrawl CLI for AI Agents

The initialization command is the quickest way to install Firecrawl CLI, authenticate, and configure agent skills:

npx -y firecrawl-cli@latest init --all --browser

The command opens a browser for Firecrawl account login or signup, stores your API key, and configures compatible agent integrations. Restart your coding agent after initialization so it can detect the new capabilities.

Install Globally with npm

For frequent use across multiple projects, install the CLI globally:

npm install -g firecrawl-cli

Verify the installation:

firecrawl --version

A global installation lets you run firecrawl from any directory without the npx startup overhead.

Authenticate and Inspect Configuration

Authenticate with the browser-based login flow:

firecrawl login

You can also provide an API key directly through an environment variable:

export FIRECRAWL_API_KEY=fc-your-key-here

Check authentication and account status:

firecrawl --status

This displays the current authentication state and available account information, such as credits and concurrency limits.

To inspect the complete local configuration, run:

firecrawl view-config

Switch accounts by logging out and signing in again:

firecrawl logout
firecrawl login

For a local or self-hosted Firecrawl instance, specify a custom API URL:

firecrawl --api-url http://localhost:3002

Scrape a Web Page

Extract the primary content from a page with:

firecrawl scrape https://example.com --only-main-content

By default, Firecrawl CLI returns clean Markdown. Save the result to a specific file with -o:

firecrawl scrape https://example.com \
  --only-main-content \
  -o output.md

Using a named output file is useful when you want to process the result in a later shell step or commit it to a dataset repository.

Request Multiple Formats

You can request several representations in one operation:

firecrawl scrape https://example.com \
  --format markdown,json,html,links,images \
  --pretty

This is useful when an agent needs readable content alongside structured metadata or when you want to inspect the page's links and images separately.

Capture Screenshots

Capture a viewport screenshot:

firecrawl scrape https://example.com --screenshot

For a full-page image, use:

firecrawl scrape https://example.com --full-page-screenshot

Wait for Dynamic Content

If a page loads content asynchronously, add a wait timer:

firecrawl scrape https://example.com --wait-for 5000

The value is specified in milliseconds. Increase it when important content appears only after client-side rendering completes.

Filter Page Content

Limit extraction to relevant HTML elements:

firecrawl scrape https://docs.example.com \
  --include-tags main,article \
  --exclude-tags nav,footer,script

Use --timing when diagnosing slow requests or comparing different extraction settings:

firecrawl scrape https://example.com --only-main-content --timing

Search the Web

Search for a topic and scrape the top results in one command:

firecrawl search "latest AI agent benchmarks" \
  --scrape \
  --limit 8 \
  --scrape-formats markdown

Firecrawl CLI saves the search and scraped results locally. You can then inspect them with standard command-line tools:

find . -type f -maxdepth 2
grep -R "benchmark" .

Depending on the research task, you can also filter by recency, location, or source type. Combine search with mapping and browser sessions when the initial results require deeper verification.

Map a Website

Use map to discover URLs before extracting content from a site:

firecrawl map https://example.com -o sitemap.json

The command returns a structured list of URLs and associated metadata. Filter the resulting list before sending selected URLs to scrape or crawl.

A map-first workflow helps you understand a site's structure and keeps large extraction jobs focused on the pages you actually need.

Crawl a Site Recursively

Start a recursive crawl with progress reporting:

firecrawl crawl https://example.com \
  --wait \
  --progress \
  -o crawl-output.json

Firecrawl CLI follows internal links, extracts page content, and stores the results locally. For larger sites, configure limits such as crawl depth, maximum pages, and concurrency to control runtime and usage.

The --progress option provides visibility into a running job, while --wait keeps the command active until the crawl completes.

A practical crawl workflow is:

firecrawl map https://example.com -o sitemap.json
# Filter sitemap.json for the sections you need.
firecrawl crawl https://example.com --wait --progress -o crawl-output.json

Start with a small scope, validate the output, and then expand the crawl.

Automate Browser Sessions

Use cloud browser sessions for interactive pages and multi-step flows.

Launch a session:

firecrawl browser launch-session

The command returns a session ID. Use that ID for browser actions:

firecrawl browser execute \
  "open https://news.ycombinator.com" \
  --session <id>

Click an element:

firecrawl browser execute \
  "click .titleline > a" \
  --session <id>

Extract the current page:

firecrawl browser execute \
  "scrape" \
  --session <id>

Browser sessions support navigation, clicking, typing, and extraction after dynamic interactions. Close sessions when they are no longer needed so resources are released.

This approach replaces a large amount of custom Puppeteer orchestration with simple, agent-readable commands.

Configure Global Options

Persist common settings with the config command:

firecrawl config \
  --api-url https://your-custom-endpoint \
  --concurrency 5

You can also configure output preferences and headers where supported by your installation. Keep the API key in an environment variable or shell profile rather than hard-coding it in scripts:

export FIRECRAWL_API_KEY=fc-your-key-here

Before starting a large search or crawl, check account status:

firecrawl --status

This helps you review available credits and concurrency limits before launching a long-running job.

Integrate Firecrawl CLI with AI Coding Agents

Initialize the Firecrawl CLI skill for compatible agents:

npx -y firecrawl-cli@latest init --all

In CLI-and-skills mode, the agent runs Firecrawl commands explicitly when web data is needed. In MCP mode, the agent can call the configured tools directly.

Because Firecrawl CLI stores results as local files, an agent can receive a file path and inspect only the relevant sections instead of loading an entire response into context. This keeps research workflows more predictable and reduces unnecessary prompt data.

A simple agent-oriented workflow looks like this:

firecrawl search "topic to research" \
  --scrape \
  --limit 5 \
  --scrape-formats markdown \
  -o research.json

grep -R "key phrase" .

The exact agent integration depends on the coding tool and its configuration, but the underlying workflow remains the same: fetch current data, save it locally, and pass focused files or excerpts to the agent.

Troubleshoot Common Problems

Authentication Errors

Run the login flow again:

firecrawl login

If you are switching accounts or keys, clear the existing credentials first:

firecrawl logout
firecrawl login

Rate Limits or Concurrency Errors

Reduce concurrency in your configuration:

firecrawl config --concurrency 2

Check account status and available limits before retrying:

firecrawl --status

Missing Content on JavaScript-Heavy Pages

Increase the wait time:

firecrawl scrape https://example.com --wait-for 10000

Also try extracting only the primary content:

firecrawl scrape https://example.com --only-main-content

Use timing information to compare different settings:

firecrawl scrape https://example.com --wait-for 10000 --timing

Unexpected or Empty Output

Test the page with a broader extraction first:

firecrawl scrape https://example.com --format markdown,json,html

Then add content filters after you understand the page structure:

firecrawl scrape https://example.com \
  --include-tags main,article \
  --exclude-tags nav,footer,script

Best Practices

Follow these practices to keep Firecrawl CLI workflows efficient and reproducible:

Use --only-main-content when you need concise Markdown.
Give output files descriptive names.
Store results in a dedicated directory.
Test a small set of pages before starting a full crawl.
Use a search → map → scrape workflow for focused research.
Use crawl when you need broad internal-link coverage.
Set concurrency deliberately for large jobs.
Use --timing when diagnosing performance issues.
Version-control output directories when reproducibility matters.
Review credit usage regularly.
Keep API keys in environment variables instead of source files.
Close browser sessions after interactive work is complete.

Test Firecrawl API Requests with Apidog

Apidog can complement Firecrawl CLI when you need to inspect or validate API requests before automating them in a terminal workflow. Import Firecrawl endpoints such as scrape, search, and crawl into an Apidog collection, then use variables for the API key and other request parameters.

This lets you inspect:

Request headers
API key handling
Custom parameters
Response shapes
Different extraction options

You can also mock responses and run automated tests before moving a request into a shell script or agent workflow. This is useful when debugging complex options or validating an integration independently from the CLI.

Learn more at Apidog.

Conclusion

Firecrawl CLI provides a terminal-first workflow for scraping, searching, mapping, crawling, and browser automation. Its local file output makes results easy to inspect with shell tools, pass to AI coding agents, and preserve as reproducible datasets.

Start with the initialization command:

npx -y firecrawl-cli@latest init --all --browser

Then authenticate, run a small scrape, and expand into search, mapping, crawling, or browser automation as your workflow requires. Careful use of format selectors, content filters, wait timers, and concurrency settings can improve both output quality and efficiency.

Additional Resources

How Can You and Use Google Workspace CLI

Preecha — Thu, 27 Aug 2026 02:01:50 +0000

Automate Google Workspace from the command line with `gws`

Google Workspace CLI (gws) is an open-source command-line tool that provides unified access to Drive, Gmail, Calendar, Sheets, Docs, Chat, Admin, and other Google Workspace APIs. It builds commands dynamically from Google’s Discovery Service, so you can automate Workspace tasks without maintaining separate SDKs, custom OAuth flows, or hand-written curl scripts.

Try Apidog today

Why use Google Workspace CLI?

Automating Google Workspace often requires you to:

Configure OAuth scopes and credentials
Learn separate APIs for each Workspace service
Handle pagination manually
Maintain multiple SDKs
Update scripts when API methods change
Define custom tools for AI agents

Google Workspace CLI provides a single, Rust-powered interface that discovers Workspace API methods at runtime. It was released in early 2026 by the Google team and announced by Addy Osmani.

The CLI provides:

JSON output suitable for scripts and agents
Dry-run support
Pagination helpers
Dynamically discovered API commands
More than 40 task-oriented + helpers, such as gws gmail +send
Agent skills for Claude Code, Cursor, OpenClaw, and Gemini CLI

If you also need to inspect requests, debug OAuth scopes, or verify payloads, Apidog can handle the API testing side of the workflow.

Install Google Workspace CLI

Google Workspace CLI requires Node.js 18 or later.

Check your installed version:

node --version

Run without installing

Use npx for a quick test or one-off script:

npx @googleworkspace/cli --help
npx @googleworkspace/cli drive files list --params '{"pageSize":1}'

This downloads and runs the latest package without installing gws globally.

Install globally

For regular use, install the package globally:

npm install -g @googleworkspace/cli
gws --version

The npm package includes prebuilt binaries, so you do not need to compile the Rust project locally.

You can also install the CLI from GitHub Releases, with Homebrew, or through Nix:

brew install googleworkspace/cli

Configure authentication

Run the guided setup:

gws auth setup

The setup flow opens a browser and handles:

Creating a Google Cloud project if needed
Enabling the required Workspace APIs
Completing the initial OAuth flow
Saving credentials in your operating system’s keyring

Stored credentials are encrypted with AES-256-GCM.

Configure only the current project

By default, setup applies globally. To create project-specific configuration, run:

gws auth setup --project

Check or change the authenticated account

gws auth login

Inspect the current user and granted scopes:

gws auth whoami

Log out:

gws auth logout

Use Google Workspace CLI in CI or headless environments

Export credentials to a file:

gws auth export --unmasked > creds.json

Then point the CLI to that file:

export GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE=/path/to/creds.json

Treat the exported file as a secret. Do not commit it to source control.

You can also reuse an access token from gcloud:

export GOOGLE_WORKSPACE_CLI_TOKEN="$(gcloud auth print-access-token)"

Disable telemetry

To disable anonymous usage collection:

export GOOGLE_WORKSPACE_CLI_NO_TELEMETRY=1

Discover available commands

Google Workspace CLI discovers commands dynamically rather than relying on a fixed command list.

Start with:

gws --help

You can then explore the available services and methods from the command line.

Work with Google Drive

List files

List up to 10 files whose names contain report:

gws drive files list \
  --params '{"pageSize":10, "q":"name contains report"}'

Because the output is JSON, you can pipe it into tools such as jq:

gws drive files list \
  --params '{"pageSize":10}' \
  | jq

Upload a file

Use the +upload helper to upload a local file:

gws drive +upload ./budget.xlsx --name "2026 Budget"

Work with Gmail

Send an email

gws gmail +send \
  --to colleague@example.com \
  --subject "Update" \
  --body "See attached." \
  --attach ./file.pdf

Reply to a message

gws gmail +reply \
  --message-id <ID> \
  --body "Thanks!"

Replace <ID> with the Gmail message ID.

Triage the inbox

gws gmail +triage

Work with Google Calendar

Create an event

gws calendar +insert \
  --summary "Sprint Planning" \
  --start "2026-03-20T10:00" \
  --end "2026-03-20T11:00" \
  --attendees "team@example.com"

Show today’s agenda

gws calendar +agenda --today

Work with Google Sheets

Append a row to a spreadsheet:

gws sheets +append \
  --spreadsheetId <ID> \
  --range "Sheet1!A:C" \
  --values "Task X,Done,2026-03-16"

Replace <ID> with the spreadsheet ID from the Google Sheets URL.

Work with Google Docs

Insert text into a document:

gws docs +write \
  --documentId <ID> \
  --text "New section added via Google Workspace CLI"

Replace <ID> with the document ID.

Work with Google Chat

Post a message to a Chat space:

gws chat +send \
  --space <SPACE_ID> \
  --text "Deployment complete 🚀"

Replace <SPACE_ID> with the target Chat space ID.

Preview commands before executing them

Add --dry-run to preview the API call without executing it:

gws gmail +send \
  --to colleague@example.com \
  --subject "Update" \
  --body "See attached." \
  --dry-run

This is useful when:

Testing commands generated by an AI agent
Checking parameters before modifying Workspace data
Debugging request payloads
Reviewing automation in CI

Handle pagination

Use --page-all to retrieve all pages as newline-delimited JSON:

gws drive files list \
  --params '{"pageSize":100}' \
  --page-all

NDJSON output is convenient for streaming and processing large result sets.

Configure default behavior

Persist default parameters with an environment variable or a .env file:

export GOOGLE_WORKSPACE_CLI_DEFAULT_PARAMS='{"prettyPrint":true}'

The CLI also supports output options such as:

gws drive files list --params '{"pageSize":10}' --json

gws drive files list --params '{"pageSize":10}' --yaml

You can also adjust timeouts or force file-based keyring storage.

View the current configuration with:

gws config

Connect Google Workspace CLI to an AI coding agent

After authentication, install the bundled agent skills:

npx skills add https://github.com/googleworkspace/cli

You can also use an agent-specific installer for tools such as Claude Code or Cursor. Restart the agent afterward so it can discover the installed skills.

Prompt the agent to use `gws`

Be explicit in your prompts:

List my recent Drive files using Google Workspace CLI.

Send a follow-up email via Google Workspace CLI.

Show today's Calendar agenda with gws, then summarize the meetings.

Add an automatic invocation rule

Add a rule like the following to CLAUDE.md, Cursor rules, or your agent’s instruction file:

Whenever a task involves Gmail, Drive, Calendar, Sheets, Docs, or Chat,
use Google Workspace CLI commands before responding. Resolve the service
and method first.

This lets the agent use gws for Workspace operations and return file paths or JSON results without loading unnecessary data into its context.

Verify Workspace API calls with Apidog

Google Workspace CLI executes Workspace operations from the terminal. When you need to inspect a raw payload or troubleshoot authentication, use Apidog to reproduce and validate the underlying API request.

Practical workflows include:

Test a Sheets.values.append payload before an agent writes to a spreadsheet
Inspect Gmail send requests while debugging OAuth scopes
Store user tokens or service-account credentials as environment variables
Switch between accounts and compare responses
Add assertions for repeatable API checks

A useful workflow is:

Build or preview the command with gws --dry-run.
Reproduce the request in Apidog.
Inspect the URL, headers, body, and response.
Confirm the required OAuth scopes.
Run the final gws command.
Save the API request as a repeatable test when appropriate.

Google Workspace CLI provides live Workspace access, while Apidog provides a visual environment for request inspection and repeatable API testing.

FAQ

Does Google Workspace CLI send my data externally?

No. Calls go directly to Google APIs, and your content remains in your Google account.

Which services does Google Workspace CLI support?

It supports Workspace APIs discovered dynamically, including Drive, Gmail, Calendar, Sheets, Docs, Chat, Admin, and Script.

How current are the commands?

Google Workspace CLI queries Google’s live Discovery Service, so newly exposed methods can appear without waiting for a CLI update.

Does it require an API key?

It uses standard Google OAuth or service-account authentication. You do not need a separate API key beyond the required authentication credentials.

Which agents and editors does it support?

Google Workspace CLI can be used with Claude Code, Cursor, OpenClaw, Gemini CLI, VS Code extensions, and tools compatible with MCP or Agent Skills.

What is the difference between raw commands and `+` helpers?

Raw commands map to Discovery API methods, such as drive.files.list.

Commands prefixed with + are shortcuts for common tasks, such as:

gws drive +upload
gws gmail +send
gws calendar +agenda

Can I use Google Workspace CLI without an AI agent?

Yes. You can use it directly for shell scripts, CI jobs, scheduled automation, and day-to-day terminal tasks.

Additional resources

Google Workspace CLI GitHub repository → https://github.com/googleworkspace/cli
Full README and documentation → https://github.com/googleworkspace/cli/blob/main/README.md
Agent skills folder → https://github.com/googleworkspace/cli/tree/main/skills
Google Workspace API reference → https://developers.google.com/workspace
Quotas dashboard → https://console.cloud.google.com/apis/api
Apidog free API client → https://apidog.com?utm_source=dev.to&utm_medium=wanda&utm_content=blog-sync

Impeccable: The Claude Code Skill for Unique Frontend UI

Preecha — Thu, 27 Aug 2026 01:01:14 +0000

Impeccable is an open-source Claude Code skill created by Paul Bakaus to reduce generic, AI-generated frontend output. It includes 20 steering commands—including /audit, /polish, and /critique—seven domain-specific design references, and curated anti-patterns that tell the model what not to generate. The goal is straightforward: build interfaces that look intentionally designed rather than auto-generated.

Try Apidog today

Why AI-Generated Frontends Often Look the Same

Ask an AI coding assistant to build a dashboard, landing page, or settings panel without additional direction. The result often includes:

Inter or another default sans-serif font
A purple-to-blue gradient
Cards nested inside other cards
Gray text on colored backgrounds
Centered hero sections with a large number and small label
Glassmorphism used as a default depth effect

These patterns are functional, but they are also predictable. Large language models learn from the same common templates, so their frontend output tends to converge on the same visual language.

Impeccable is designed to interrupt that pattern. Anthropic's official frontend-design skill provides a foundation; Impeccable extends it with deeper design guidance, broader domain coverage, and explicit constraints that steer the model away from recurring AI-generated UI patterns.

If you plan to use /audit, /polish, or /overdrive in Claude Code, you can also use Apidog to validate the API endpoints your frontend depends on. Check request payloads, authentication tokens, response shapes, and mock data before UI and backend integration issues create extra rework.

What Impeccable Includes

Impeccable is an installable Claude Code skill made up of instructions, reference files, and slash commands. It augments how Claude Code approaches frontend implementation and review.

The skill has three core parts.

An Expanded `frontend-design` Skill

Impeccable's frontend guidance is divided into seven domain-specific reference files:

Each reference is intended to be used during implementation, not just read as general advice. For example, the typography reference covers:

Vertical rhythm
Font loading and Flash of Unstyled Text (FOUT)
size-adjust overrides
Appropriate and inappropriate uses of fluid typography with clamp()

This level of detail gives the model concrete decisions to apply while generating or revising frontend code.

A Context-Gathering Protocol

The /teach-impeccable command collects project-specific design context before design work begins. It asks you to define details such as:

Target audience
Primary use cases
Brand personality

The answers are saved to .impeccable.md in the project root and loaded in future sessions.

This step matters because a model without project context defaults to safe, average choices. Establishing the context once gives later commands a more specific design direction.

The 20 Commands for Improving AI-Generated Frontends

Run Impeccable commands as slash commands inside Claude Code:

/audit              → Accessibility, performance, and responsive quality check
/critique           → UX review covering hierarchy, clarity, and emotional resonance
/polish             → Final pass for alignment, spacing, and implementation details
/distill            → Remove complexity that does not earn its place
/normalize           → Align the interface with design-system standards
/animate            → Add purposeful motion
/colorize           → Introduce strategic color to a monochromatic interface
/bolder             → Push a safe or overly conservative design further
/quieter             → Tone down an overly aggressive design
/delight             → Add memorable moments of interaction
/typeset             → Improve font choices, hierarchy, and sizing
/arrange             → Fix layout, spacing, and visual rhythm
/harden             → Address error handling, internationalization, and edge cases
/optimize            → Improve frontend performance
/extract             → Pull out reusable components and design tokens
/adapt               → Adapt the interface for other devices or contexts
/onboard             → Design onboarding flows and empty states
/clarify              → Improve unclear UX copy
/overdrive           → Add technically ambitious effects
/teach-impeccable    → Save project-specific design context

Most commands accept an optional scope. For example:

/audit header
/polish checkout-form

The first command limits the audit to the navigation bar. The second focuses the polish pass on the checkout form. Scoped commands reduce the chance of changing frontend areas that already work.

Chain Commands for a Repeatable Review

A practical workflow is to run commands in sequence:

/audit
/arrange
/typeset
/polish

Each step addresses a different category of problems:

/audit identifies accessibility, performance, and responsive issues.
/arrange corrects layout and spacing.
/typeset improves the type hierarchy.
/polish performs the final visual pass before shipping.

Use Anti-Patterns to Prevent Generic UI

Impeccable's anti-pattern library is one of its most distinctive features. Instead of offering only broad style preferences, it names recurring failure modes and turns them into explicit constraints.

Typography Anti-Patterns

Avoid:

Inter, Roboto, Arial, or system defaults when they make the design indistinguishable from common templates
Monospace fonts used only to imply “developer vibes”
Large rounded icons above every heading, which creates a repeated template structure

Color Anti-Patterns

Avoid:

Gray text on colored backgrounds; use a darker shade of the background color when appropriate
The familiar AI palette of cyan on dark backgrounds, purple-to-blue gradients, and neon accents
Pure black (#000) and pure white (#fff); tint neutral colors instead

Layout Anti-Patterns

Avoid:

Wrapping every element in a card
Nesting cards inside cards
Repeating identical icon-heading-text card grids
Centering every element when a left-aligned or asymmetric layout would create stronger hierarchy

Motion Anti-Patterns

Avoid:

Bounce and elastic easing that makes interactions feel dated
Animating layout properties such as width, height, or padding

Prefer transform and opacity for motion where possible. This reduces layout work and generally produces smoother transitions.

Build System, Tests, and Tool Support

Impeccable is maintained as a software project rather than a collection of prompt files. It includes a build system, unit tests, and support for multiple AI development tools.

Build Provider-Specific Bundles

Source skill files are stored in source/skills/ and use YAML frontmatter based on the Agent Skills specification.

Build the provider bundles with:

bun run build

To remove existing output and rebuild everything:

bun run rebuild

The build system compiles the source into formats for:

Cursor
Claude Code
OpenCode
Gemini CLI
Codex CLI
VS Code Copilot
Kiro
Pi

Each provider receives the metadata format it expects. For example, Claude Code and OpenCode include metadata such as arguments and allowed tools, while Codex CLI uses argument hints with $ARGNAME placeholders. Gemini receives minimal frontmatter.

The transformations are implemented through the modular architecture in scripts/lib/transformers/.

Run the Unit Test Suite

The Bun-based test suite is located in tests/build.test.js:

bun test

The tests cover the complete build pipeline, including:

Orchestration and transformer arguments
Integration tests that create source files in a temporary directory
Output-file existence for every supported provider
Provider-specific transformations
Empty skill-list edge cases

The transformation tests also verify provider-specific output, such as:

{{args}} in Gemini output
$TARGET in Codex output
user-invokable: true in Claude Code output

If you modify a transformer, run bun test before contributing. This provides quick feedback across all supported tool formats.

Pair Impeccable with Apidog for API-Driven Frontends

Impeccable focuses on the UI layer. Apidog focuses on the API layer.

A polished frontend can still fail users when its API calls are undocumented, untested, or unreliable. Apidog helps validate the backend contract that the generated interface depends on.

With Apidog, you can:

Design APIs visually before implementing the backend
Generate mock servers from an API schema
Render realistic data in an AI-generated frontend during development
Run automated endpoint tests and catch regressions
Share interactive API documentation with the team

The division of responsibility is useful:

Use Impeccable to make the interface distinctive, accessible, and production-ready.
Use Apidog to validate the requests, responses, mocks, and documentation behind that interface.

Together, they address two common weaknesses in AI-assisted development: generic visual output and unreliable integration behavior.

Getting Started with Impeccable

Download the ready-to-use bundle from impeccable.style, choose your target tool, and extract it into the appropriate location.

For Claude Code, install at the project level:

cp -r dist/claude-code/.claude your-project/

Or install globally:

cp -r dist/claude-code/.claude/* ~/.claude/

Then run the setup command once:

/teach-impeccable

After the design context is saved, you can use the remaining commands in the project.

FAQ

How is Impeccable different from Anthropic's official `frontend-design` skill?

Impeccable builds on that foundation with seven domain-specific reference files, 20 steering commands, and an explicit anti-pattern library. The official skill is a starting point; Impeccable adds a broader system for guiding and reviewing frontend output.

Does Impeccable support tools other than Claude Code?

Yes. It supports Cursor, Claude Code, OpenCode, Gemini CLI, Codex CLI, VS Code Copilot, Kiro, and Pi. Its build system compiles one source format into provider-specific dialects.

What does `/overdrive` do?

/overdrive is intended for technically ambitious effects such as WebGL shaders, 60fps virtual tables, spring physics in dialogs, and scroll-driven reveals. Use it when the design calls for effects beyond conventional frontend patterns.

How does Impeccable handle unit testing?

The project includes a Bun-based suite covering the build pipeline, transformer correctness, and integration tests that generate real source files and verify provider outputs.

Run:

bun test

Can Impeccable help with API-driven frontends?

Impeccable handles UI quality. For the API layer, pair it with Apidog for visual API design, automated testing, and mock server generation.

Is Impeccable free to use?

Yes. Impeccable is open source under the Apache 2.0 license. Its source code is available on GitHub, and compiled bundles are available at impeccable.style.