Swastik Codes — a faster, lighter API platform for every protocol

The problem

API teams end up running a stack of separate tools: a REST client, a gRPC tool, a WebSocket tester, an MQTT app, a mock server and a monitoring service, each with its own copy of the environments and secrets.

The popular desktop clients have also grown heavy. Most ship a full copy of Chromium, so a tool for sending HTTP requests takes hundreds of megabytes to download, several processes to run and seconds of CPU before the first window appears.

---

Faster and lighter — measured

The desktop app sends requests from a native Rust engine instead of a bundled browser. On 23 October 2026 it was measured against Postman, Bruno, Insomnia and Hoppscotch. Each app ran alone in an identical Ubuntu 24.04 container with a fresh profile, and the figures are the median of three runs. Swastik Codes came out lightest and fastest on every desktop measure.

• Memory: 434 MB after 60 seconds — 26% less than Postman (585 MB) and 46% less than Hoppscotch (800 MB)
• Startup CPU: 2.7 seconds — 4.7 times less than Postman (12.6 s) and nearly 20 times less than Insomnia (53.3 s)
• Window on screen in 0.4 seconds — Postman took 1.1 s and Bruno 4.6 s
• 3 processes, against 9 for Postman and 8 for Insomnia
• An 11 MB Windows installer — 18 times smaller than Postman's 204 MB

This is the product's own benchmark, run with software rendering on a server without a GPU, so absolute numbers on a desktop will differ. The full method is published at swastik.codes/benchmarks.

---

A web app that loads in 382 KB

The browser version is just as lean. On a cold load in Chromium it transfers 382 KB, against 6.6 MB for hoppscotch.io. Postman's web app was left out because it needs a sign-in before anything loads.

---

One client, eight protocols

Every protocol lives in the same collections and shares the same environments, variables and tests, so a team does not need a separate tool for each one.

• HTTP / REST — every method, body type and auth scheme, with code snippets for each request
• GraphQL — queries, mutations and variables written against the endpoint's schema
• gRPC — service calls alongside REST endpoints in the same collection
• WebSocket — open a connection, send messages and watch replies arrive
• Socket.IO — emit and listen to events like any other endpoint
• Server-Sent Events — subscribe to a stream and read events as they are pushed
• MQTT — publish and subscribe to topics on a broker
• MCP — test Model Context Protocol servers, or serve a collection to AI coding assistants

---

The whole API lifecycle

One collection holds the request being debugged, the tests that guard it, a mock for the frontend team and a monitor that raises an alert when it breaks.

• API tests — pre-request and test scripts, assertions, JSON Schema checks and a request-sending helper
• Collection runner — folders or whole collections with iterations, data files and delays, with exportable reports
• Load tests — virtual users under several traffic profiles, with live latency percentiles
• Mock servers — saved examples served from a public URL, with request matching, delays and templates
• Monitors — scheduled runs with retries, and alerts by email or signed webhook
• API design — multi-file OpenAPI and AsyncAPI specs with linting, versioning and collection sync
• Published docs — a collection published as public documentation, with secrets removed
• Flows — visual request chains with conditions, loops, delays and webhook triggers

---

Testing that finds what you missed

Passing tests only cover the cases someone thought to write. These checks look for the rest.

• Staging versus production — two environments' responses compared field by field, ignoring IDs, timestamps and any other fields you choose
• Flaky tests and coverage gaps — repeated runs expose unstable tests, and untested requests and error codes are listed
• Security checks — probes for unauthenticated endpoints, permissive CORS, leaky error messages and crashes on invalid input
• An access matrix for every role — each role checked against each endpoint, with unauthorised access flagged
• Breaking changes stopped in review — the API read from code, compared with the main branch, and CI failed on a breaking change
• Docs that tell you when they are wrong — responses checked against saved examples, with missing, new or changed fields flagged

---

Fixes for everyday API pain

The team went through reviews, GitHub issues and surveys about API tools, and built fixes for the complaints that came up most.

• Localhost from the browser — a local bridge lets the web app reach your machine and private networks, with no extension and no open port
• Run as admin, user or guest — one request sent as any role, with automatic sign-in and token refresh
• A secret guard that is on by default — plain-text tokens are flagged, with an offer to move them into a variable or the vault
• From your code to a collection — API routes scanned from the codebase and kept in sync on every push, including private GitHub repositories
• One catalog of the team's APIs — a searchable directory with owners, status, docs and monitors
• Your collection inside your AI assistant — a read-only-by-default MCP server with redaction and logging

---

Bring your Postman collections

Switching does not mean rewriting. Postman collections, environments, globals and full data dumps import directly, and scripts written against Postman's pm.* API run unchanged in the sandbox. swc.* is the native equivalent.

In CI, swc run accepts Newman-compatible flags, so moving a pipeline off Newman is a small edit. Nothing is locked in: collections export back to Postman or OpenAPI at any time.

---

Built for teams

API changes are reviewed the same way code is.

• Teams and workspaces — personal, team and public workspaces with invitations, presence and sync across devices
• Roles — admin, editor and viewer
• Versions, forks and pull requests — version history, forks, approval reviews and merge checks
• Comments and notifications — threaded comments with mentions, and HMAC-signed workspace webhooks

---

Careful with credentials

An API client holds the keys to every system it tests, so the defaults are conservative.

• Variable current values and the encrypted vault stay on the device and are never uploaded, even in a cloud workspace
• Local workspaces stay in the browser; cloud workspaces sit on access-controlled servers
• The hosted web app blocks loopback and private addresses; those are reached only through your own bridge or the desktop app
• GitHub sign-in reads only the profile and verified email
• Load tests are capped in virtual users and duration, and are only for systems you own or are authorised to test

---

Inside VS Code

The Swastik Codes extension, on the Visual Studio Marketplace, brings the same workspaces into the editor. It runs on Windows, macOS and Linux (VS Code 1.90 or later) and includes swc, so nothing else needs installing.

• Collections and environments in the sidebar; requests sent and read next to the code
• Collections run as tests in VS Code's Test Explorer, with each pm.test listed under its request
• Project Sync turns the routes in the open folder into a collection and keeps it current on save
• Tokens and passwords kept in the system keychain on this computer only, never uploaded

---

The swc command-line tool

swc runs on macOS, Linux and Windows. One command installs it (curl -fsSL https://swastik.codes/install.sh | sh, or install.ps1 in PowerShell), or it comes from npm as @swastik-codes/cli. It covers the jobs that belong in a terminal or a pipeline.

---

Where it runs, and what it costs

Swastik Codes is free today, with no paid plans. Any future paid features will be announced in advance. The web app needs a free account, made with GitHub or email; the desktop app and swc work without one.