Forem: Preecha

API Tool for Game Server Backend Teams

Preecha — Wed, 22 Apr 2026 09:48:56 +0000

TL;DR

Game server backends rely on multiple protocols: REST for player accounts and matchmaking, WebSocket for real-time game state, and gRPC for internal service communication. Most API tools focus only on REST. This article breaks down what game backend teams need from API tooling, how Apidog’s WebSocket and gRPC support fits in, and practical considerations for latency-sensitive testing.

Try Apidog today

Introduction

Game server backend development brings protocol complexity that typical API tools ignore. REST endpoints handle player profiles, inventory, and matchmaking; WebSocket connections manage real-time state, movement, and chat; gRPC links internal services. Using multiple API tools for a single backend drains productivity and slows down debugging.

Latency is another challenge. A 200ms REST response may be fine for a leaderboard, but in WebSocket-driven gameplay, that’s a broken experience. Game backend engineers need tooling that matches their protocol stack and surfaces latency issues.

This guide targets backend engineers at studios and indie developers building multiplayer backends, showing how to test REST, WebSocket, and gRPC APIs in a unified way.

The game backend protocol stack

Map your backend protocols before selecting tools:

REST: Administrative layer

REST covers stateless, cacheable endpoints:

Player authentication/session management
Player profiles/account management
Inventory/economy endpoints
Matchmaking queue operations
Leaderboards/statistics
Game configuration retrieval

These are low-frequency and tolerate higher latency. Standard REST API testing tools cover this well.

WebSocket: Real-time game state

WebSocket enables high-frequency, bidirectional comms:

Player position/movement updates (20-60/sec/player)
Game state sync
In-game chat/notifications
Matchmaking status updates
Server-to-client event pushes

Testing requires persistent connections, sending/receiving JSON or binary messages, and observing message streams over time.

gRPC: Internal services

Service-oriented backends often use gRPC for efficiency and strong typing:

Session manager ↔ game logic server
Auth service ↔ game server
Analytics ingestion
Internal leaderboard pipelines

gRPC testing needs .proto imports, method calls with typed payloads, and is fundamentally different from REST.

What’s usually not needed

Game backends rarely use binary WebSocket frames, MQTT, or UDP via API tools. These are often handled with custom test utilities.

REST testing for game backends

REST is the baseline. For game backends, focus on:

Environment management:

Test against local, dev, staging, and prod servers. Use environment variables for base URLs, tokens, and region endpoints.

Auth header automation:

Game backends use JWT or custom tokens. Automate token refresh with pre-request scripts that fetch and inject tokens.

Chained requests:

Matchmaking flows often require sequential requests (create player → enqueue → poll status → get match). Use request chaining to pass outputs between calls.

Assertions:

Check leaderboard order, inventory after purchases, and error responses with assertion scripts.

Apidog supports:

Pre/post request JavaScript scripting
Environment variable injection
Chained requests
Test assertions All available in the free tier.

WebSocket testing for game backends

WebSocket testing is where most tools fall short.

What good WebSocket testing needs

Connect to WebSocket server with custom headers (auth/session IDs)
Send messages or sequences
Observe incoming messages in real time
Verify message order/timing after actions
Test connection stability (reconnect, heartbeats, drops)

How Apidog helps

Apidog offers a dedicated WebSocket interface:

Enter ws:// or wss:// URL, add headers, and connect
Send JSON messages directly (e.g. { "type": "join_room", "room_id": "abc123" })
Incoming messages appear in a formatted log
Supports sending raw binary (hex/base64) payloads for games using binary protocols
Custom headers for authentication (via handshake)

Limitations:

Apidog’s WebSocket testing is interactive/manual. For automated sequence or latency assertions (e.g., “receive message B within 500ms of sending A”), you’ll need custom scripts or test frameworks.

gRPC testing for game backends

gRPC testing requires .proto service definitions.

Workflow with Apidog

Import your .proto files.
Apidog parses and lists all RPC methods.
Select a method; a typed form for the request appears.
Fill in fields, send request, inspect response.

Streaming RPCs:

Apidog supports unary and server-side streaming. Client/bidirectional streaming support is more limited—check Apidog docs for latest status.

TLS support:

gRPC over TLS with configurable certificate verification is supported.

Latency testing considerations

API tools don’t directly solve game-specific latency needs, and Apidog is no exception, but you can still get useful data.

Measuring latency with Apidog

REST: Response time is displayed for each request. Repeat runs to observe variance.
WebSocket: No automatic round-trip latency. Timestamp messages manually and compute deltas from server responses.

When to use other tools

For load/performance testing:

Use k6 or Locust for REST under load
Use WebSocketBenchmark or custom scripts for concurrent WebSocket tests
Gatling for scenario-based loads
Custom tools for protocol-specific latency (e.g., physics update to client broadcast round-trip)

Apidog is best for development/debugging—not load or stress testing.

Practical game backend testing setup

Workspace structure:

- auth/
- matchmaking/
- inventory/
- leaderboards/
- player-profiles/
- websocket-connections/
- internal-services/   # for gRPC

Environments:

Set up local, dev, staging, and prod.

Centralized environment vars:

BASE_URL = http://localhost:3000
WS_URL = ws://localhost:3000/game
GRPC_HOST = localhost:50051
PLAYER_TOKEN = {{generated via pre-request script}}
TEST_PLAYER_ID = player_001
TEST_ROOM_ID = room_test_001

Auth token automation:

Write a collection-level pre-request script to fetch and store JWT tokens. Apply to all requests for seamless token refresh.

WebSocket session flows:

Create a document per major flow (join session, matchmaking, reconnection). Each establishes the connection with correct headers and documents expected message sequences.

gRPC service testing:

Import .proto files, test each RPC with valid and invalid inputs. Pay attention to error codes for invalid player IDs or session tokens.

FAQ

Does Apidog support WebSocket binary frames for custom protocols?

Yes. You can send hex- or base64-encoded binary payloads. For highly custom non-standard framing, you may need a custom tool.

Can Apidog test gRPC bidirectional streaming?

Apidog supports unary and server streaming. For bidirectional streaming, support may be limited—check docs. For advanced cases, use grpcurl or BloomRPC.

How to test across server regions?

Create one Apidog environment per region with region-specific URLs/addresses. Switch environments to run the same suite against different regions.

How to test matchmaking flows needing multiple clients?

Apidog tests one client at a time. For multi-client scenarios, use two sessions or custom integration tests with your language’s HTTP/WebSocket libraries.

Does Apidog support custom WebSocket headers for authentication?

Yes. Add custom headers (e.g., auth tokens) before connecting.

Can Apidog replay a WebSocket message sequence automatically?

No. For automated message sequence replay, use a framework like Playwright (with WebSocket support) or custom scripts with ws (Node.js) or websockets (Python).

Game backend teams need API tools that cover REST, WebSocket, and gRPC in one workflow. Apidog consolidates these protocols, streamlining development and debugging. While it won’t replace your load-testing or low-level binary debugging tools, it covers everyday testing needs for game backend engineering—without the context switching.

API Platform for IoT Development

Preecha — Wed, 22 Apr 2026 09:06:51 +0000

TL;DR

IoT APIs have unique requirements: limited bandwidth, binary payloads, device-focused authentication, and non-HTTP protocols. This post explains what IoT developers need from API tools, where standard tools like Apidog fit, where they don’t (like MQTT), and how to test the HTTP-facing layer of your IoT backend.

Try Apidog for Free

Introduction

IoT development involves two main API layers. Device-facing protocols (MQTT, CoAP, custom binary, WebSocket) focus on efficiency for constrained devices and networks. Platform-facing APIs (REST) handle provisioning, firmware updates, telemetry ingestion, and management dashboards.

Most API tools only cover the platform-facing REST layer—not device protocols like MQTT. Don’t expect a standard API platform to handle MQTT natively. The best approach: use standard API tools for HTTP/WebSocket, and specialized tools for MQTT or CoAP.

This article maps IoT protocol needs, shows what Apidog covers, and provides actionable steps for testing the HTTP layer of your IoT backend.

The IoT Protocol Landscape

MQTT: Core protocol for device-cloud messaging

MQTT is the main protocol for device-to-cloud communication. Designed for unreliable, bandwidth-limited environments, it uses a publish/subscribe model with topics, QoS, retained messages, and LWT.

Apidog does not support MQTT natively. For MQTT testing, use:

MQTT Explorer: Desktop GUI for broker/topic inspection
MQTTX: Cross-platform GUI and scripting
mosquitto_sub/mosquitto_pub: CLI tools from Mosquitto
HiveMQ Broker: Free tier with web client

Tip: Always plan for a dedicated MQTT tool alongside your HTTP API tool.

HTTP/REST: Managing devices and data

Every IoT platform exposes REST APIs, even if devices use other protocols for telemetry. Typical REST use-cases:

Device provisioning: Registration, cert creation, identity assignment
OTA firmware updates: Check for and deliver firmware
Configuration: Push new settings to devices/groups
Telemetry ingestion: Many accept HTTP POST telemetry
Device management: Fleet status, remote commands, grouping
Data queries: History, logs, alerts
Webhook setup: Outbound event notifications

REST APIs are fully testable with tools like Apidog.

WebSocket: Real-time bidirectional communication

WebSocket bridges the gap between REST and MQTT for real-time, two-way messaging:

Device command streams
Live telemetry updates to dashboards
Bidirectional config updates

Apidog supports WebSocket testing, including custom connection headers for most IoT scenarios.

CoAP: For the most constrained devices

CoAP is an HTTP-like protocol for microcontrollers and tight bandwidth constraints, running over UDP.

Not supported by Apidog. Use:

copper4cr: Browser extension
libcoap: CLI tools

Binary Payloads

IoT devices often use binary encodings (Protocol Buffers, MessagePack, CBOR, or custom formats) instead of JSON.

Apidog allows raw binary HTTP request bodies, supporting hex or base64-encoded payloads for platforms that accept binary over HTTP.

Device Authentication Patterns in IoT

IoT device auth differs from standard web API auth. While OAuth2 and API keys are supported by most tools, IoT adds:

Mutual TLS (mTLS)

Cloud IoT platforms (AWS, Azure, Google) use mTLS for device authentication. Each device has a client certificate.

Testing mTLS in Apidog:

Load device certificate and private key in SSL settings
Connect to endpoints requiring mTLS authentication

Device-specific API Keys

Some platforms issue per-device keys or token pairs. Use as Bearer tokens or API key headers—Apidog handles both.

JWTs with Device Claims

Platforms may issue JWTs with device info. Use Bearer auth; handle token refresh via pre-request scripts if needed.

Custom Header Auth

Some platforms use proprietary headers (e.g., X-Device-Token). Apidog supports arbitrary custom headers.

Testing IoT REST APIs with Apidog

Device Provisioning Flows

Provisioning usually involves multiple REST steps:

POST device registration (serial, model, firmware)
Receive device ID/credentials in response
Configure device with credentials
GET to verify registration

Implementation:

Use chained requests in Apidog
Extract device ID with a post-request script and set as environment variable
Use the variable in subsequent requests for full flow automation

OTA Firmware Update Endpoints

Common OTA steps:

GET /devices/{id}/update-check
GET /devices/{id}/firmware
POST /devices/{id}/update-status

Test with Apidog:

Inspect firmware binary responses (headers, content)
Validate correct download and reporting flows

Telemetry Ingestion (HTTP)

Many platforms accept telemetry as HTTP POST, often in binary.

To test binary ingestion:

Set body type to raw
Choose binary format
Paste hex or base64-encoded payload
Set Content-Type: application/octet-stream (or required type)
Send and check response

Protobuf: Encode test payload with your language’s protobuf library, then paste the binary.

SSL Certificate Testing

IoT backends often use self-signed or pinned certs.

Apidog SSL settings let you:

Disable SSL verification for dev/self-signed certs
Load custom CA for private deployments
Load client certificate for mTLS

WebSocket Testing for IoT Device Streams

Common real-time use-cases:

Device shadow/twin updates (AWS IoT, Azure IoT)
Live telemetry to dashboards
Command delivery to devices

Test with Apidog:

Connect using required auth headers (Bearer/API key)
Send subscription messages if needed
Monitor incoming messages
Send test commands and observe device response
Specify subprotocols via Sec-WebSocket-Protocol if required

What to Use for MQTT Testing

Since Apidog doesn’t support MQTT:

MQTTX: Full-featured GUI, scripting, TLS/mTLS, all protocol versions
MQTT Explorer: Visualize topic trees and broker state
mosquitto_pub/sub: CLI tools for quick, scripted tests
CI/CD: Use language-native MQTT libraries (e.g., paho-mqtt for Python, MQTT.js for Node)

Practical IoT Backend Testing Setup

Environment configuration:

Environments:
  local-dev:
    base_url: http://localhost:8080
    ssl_verify: false
  staging:
    base_url: https://iot-staging.example.com
    ssl_verify: true
  prod:
    base_url: https://api.iot.example.com
    ssl_verify: true

Variables:
  device_id: dev_test_001
  device_serial: SN-TEST-00001
  auth_token: {{fetched via pre-request script}}
  firmware_version: 2.1.4

Folder structure:

- provisioning/         # Registration/credential flows
- telemetry/           # Ingestion endpoint tests (JSON, binary)
- ota/                 # Firmware update flows
- device-management/   # Device CRUD operations
- websocket/           # Real-time stream tests
- error-cases/         # Invalid/malformed tests

Binary payload test checklist:

Valid binary payload
Truncated/incomplete payload
Wrong Content-Type
Max-size payload
Correct/incorrect auth

FAQ

Does Apidog support MQTT testing?

No. Use MQTTX, MQTT Explorer, or mosquitto CLI for MQTT. Apidog covers HTTP and WebSocket, not MQTT.

Can Apidog test CoAP endpoints?

No. CoAP is UDP-based; use copper4cr or libcoap.

How to test binary protobuf payloads in Apidog?

Encode with your protobuf library, convert to hex/base64, paste into raw binary body, set appropriate Content-Type.

Does Apidog support mTLS/device certificate authentication?

Yes. Load client cert and key in SSL settings.

Can Apidog test AWS IoT, Azure IoT Hub, or Google Cloud IoT?

Yes—for their HTTP/REST APIs. Use MQTTX for MQTT connections.

Best approach for low-bandwidth binary telemetry testing?

Create test fixtures (valid, truncated, malformed payloads), store as environment variables or files, send via Apidog, check responses.

No single tool covers every IoT protocol. Use Apidog for HTTP/WebSocket (provisioning, management, telemetry, binary, mTLS), and MQTTX/mosquitto for MQTT. Knowing when to use which tool is key to efficient IoT development.

Thunder Client Pro Paywall: What Changed and Your Best Alternatives

Preecha — Wed, 22 Apr 2026 08:41:05 +0000

TL;DR

Thunder Client has moved git sync—saving your collections as JSON files in your project—behind a Pro paywall. Free users can still send requests, but collections are now stored in VS Code's extension storage, not in your project or git. Your best free alternatives: REST Client (file-based, git-friendly), Apidog (cloud sync, free workspace), or sticking with an old Thunder Client version (limited support).

Try Apidog today

Introduction

Thunder Client was popular with developers because it was a lightweight, free, git-friendly API client inside VS Code—collections lived as JSON files in your project directory, making them version-controlled alongside your code.

With git sync now restricted to the Pro tier, this core value is gone for free users. Below, you’ll find what changed, what’s missing, and how to migrate in 2026.

The timeline: how the paywall happened

Originally, Thunder Client was a free VS Code extension, storing collections as JSON in a .thunder-tests directory—naturally git-tracked.

With the introduction of the Pro tier, several features moved behind the paywall:

Git sync: Collections as JSON in your project directory (now Pro-only).
Team sharing: Share collections via git.
CLI runner: Run collections from the command line for CI/CD.

The free tier still covers basic request sending, local collections, and environment variables. But if you relied on git for API collections, your workflow is affected unless you upgrade to Pro.

What free users actually lost

After updating Thunder Client as a free user, these changes take effect:

Collection location: Collections move from project JSON files to VS Code’s internal extension storage:
- Not visible in your project directory
- Not tracked by git
- Not shared with teammates via repository
- Tied to your local VS Code install
Git history: Request changes and history are no longer tracked in git.
Code review integration: You can't review API collection changes via pull requests; sharing now requires manual export/import or Pro subscription.

Option 1: Stay on an older Thunder Client version

You can freeze Thunder Client at an older version to keep git sync:

Disable auto-update: Right-click Thunder Client in VS Code extensions panel > "Disable Auto Update".
Install specific version: Download .vsix from the extension’s release history and install manually.

Limitations:

No bug fixes or security updates.
Potential incompatibility with future VS Code versions.
Maintenance hassle.
Storage formats may change, reducing usefulness over time.

This is a short-term workaround, not a long-term solution.

Option 2: Switch to REST Client

REST Client by Huachao Mao is the top free, file-based replacement.

Uses .http files—plain-text requests in your project, tracked by git.

Example request:

GET https://api.example.com/products HTTP/1.1
Authorization: Bearer {{token}}
Accept: application/json

Requests are version-controlled, diffable, and code-reviewable.

Migration steps:

Install REST Client extension in VS Code.
Export Thunder Client collections as JSON.
Manually rewrite your key requests as .http files.
Remove or archive your old Thunder Client collections.

No automated converter exists, but moving requests is usually straightforward.

Downside: REST Client has no GUI—you author requests as plain text.

Option 3: Switch to Apidog

Apidog solves the git sync problem via cloud workspaces, not plain files. Free tier supports up to 3 users, with synced collections across devices.

Migration steps:

Export Thunder Client collections (File > Export).
Create a free Apidog account at apidog.com.
In Apidog, click “Import” and upload your JSON export.
Install the Apidog VS Code extension.
Sign in to your Apidog account in the extension.
Your imported collections appear inside VS Code.

Benefits over Thunder Client free:

Cloud sync across devices
Team sharing (up to 3 users free)
Request history & API documentation
Desktop app with the same workspace

Trade-off: Collections are in Apidog’s cloud, not local files in git. If you need git-based storage, REST Client is better.

Comparing the migration paths

Option	Git sync	Free	GUI	Migration effort
Old Thunder Client (frozen)	Yes (old ver.)	Yes	Yes	Low (unsustainable)
REST Client	Yes (.http)	Yes	No	Medium
Apidog	Yes (cloud)	Yes (3 users)	Yes	Low–Medium
Thunder Client Pro	Yes	No (~$10-15/mo)	Yes	None

FAQ

When did Thunder Client move git sync to Pro?

Free users lost .thunder-tests storage after updating.

Can I export my collections before migrating?

Yes. In Thunder Client, right-click a collection and export as JSON. Always export before switching tools.

Is REST Client harder to use?

It depends. If you prefer editing files and having versioned requests, it’s straightforward. If you rely on a GUI, expect an adjustment period.

Does Apidog store collections in my git repository?

No, Apidog stores collections in the cloud. For git-based storage, use REST Client.

Will Thunder Client free tier lose more features?

There’s no official announcement, but the move to paywalled git sync suggests the free tier could change again. For stability, consider migrating.

Fastest migration to Apidog?

Export from Thunder Client, create a free Apidog account, import your JSON, and install the VS Code extension. Most migrations take under 30 minutes.

Thunder Client’s free tier no longer supports git-based collections. For a file-based workflow, use REST Client. For cloud sync and team sharing, Apidog offers what Thunder Client once did—choose based on your team’s needs.