01
Schema Service structure enters the workbench first
Reflection, local Proto folders, and Git Proto repositories feed one discovery path before a request is sent.
Reflection + ProtoRun one gRPC call, replay the whole chain
Keep Auth, Metadata, runtime variables, and trace IDs inside one local workflow. Tokens, user IDs, and trace IDs move with the chain instead of living in copy-paste steps.
1234
{
"username": "admin",
"password": "admin123"
} LoginRequest schema synced 5 fields
usernamestring · required
admin static passwordstring · required
admin123 secret remember_mebool · optional
true default trace_idstring · runtime
{{session.traceId}} runtime metadatamap<string,string>
+ 3 entries chain 12345
{
"token": "jwt.user-1.1777898990",
"expires_in": "86400",
"user_id": "user-1"
} macOS Windows Linux
RPCORA vs Postman vs Insomnia vs Apifox
See the difference before downloading.
Postman, Insomnia, and Apifox all send gRPC requests, and Apifox also supports importing services through Server Reflection. RPCORA is different because local privacy, Git repositories, Proto folders, server reflection, API trees, context handoff, chain replay, and Doctor evidence are the default workflow.
✓ Direct path · △ Supported through broader platform features or extra setup · × Documented limitation
| Experience | RPCORA | Postman | Insomnia | Apifox |
|---|---|---|---|---|
| Execution gRPC execution | All four RPC types | All four RPC types | All four RPC types | All four RPC types |
| Local privacy Request / Schema / response data path | Local workspace stores requests, schemas, responses, and chain context | Strong cloud sync/collaboration; sensitive data needs Local Vault and access controls | Local Vault / Git / Cloud options; project storage must be explicit | SaaS data is cloud-stored; private deployment/offline space must be selected |
| Discovery tree Automatic service tree | Git / Proto folder / Reflection enter a local API tree | Definition / Reflection populates methods, not a tree-first flow | Proto folder / Reflection / BSR, then select RPC | Proto / URL / Reflection imports services and methods |
| Discovery tree Git repository Proto source | repo + branch + subdir import into the tree | gRPC schema uses Protobuf API, file, URL, or Reflection | Git Sync stores projects; gRPC schema uses file/Reflection/BSR | Git is mainly OpenAPI backup; gRPC schema uses file/URL/Reflection |
| Discovery tree Local Proto folder import | Scan folder, preview diff, apply to API tree | .proto import with import paths | Single file or folder upload | Local file import; dependency directories may need manual setup |
| Discovery tree Server Reflection import | server URL creates a service tree | Auto-loads definition when URL supports it | Sync Reflection, then select an RPC | Server Reflection import |
| Discovery tree Fallback after Reflection fails | Switch to Proto folder/Git in the same tree flow | Select or import a Protobuf API | Upload Proto or use BSR | Switch to local file or URL import |
| Request editing Schema-aware request editing | Payload organized by message fields | JSON message with Protobuf type help | Schema-based JSON Body | JSON message plus request/response parameters |
| Request editing Example generation and parameter fill | Generate examples from tree selection and keep existing values | Can generate an example message | Edit request body from schema | Auto-generate message body and dynamic values |
| Request editing Auth / Metadata / TLS context | Resolved before send and kept as diagnosis evidence | Auth, Metadata, and TLS settings | Auth, certificates, and environments without aggregated diagnosis | Auth, Metadata, TLS, variables, and environments |
| Chain context Multi-step chain replay | Built-in Chains replay path | Collections, variables, and gRPC scripts | Official gRPC FAQ lists request chaining as unsupported | Test scenarios can orchestrate flows; more test-platform oriented |
| Chain context token / userId / traceId handoff | Runtime values move between steps | Variables and scripts | Environment values; gRPC request chaining is documented unsupported | Dynamic values, extracted variables, and test steps |
| Chain context Reuse after saving a request | Tree requests can become Chain steps directly | Save to collection for reuse and sharing | Requests can be saved; gRPC history persistence is documented unsupported | Save URL, message, and Metadata on the method |
| Diagnosis handoff Failure diagnosis and handoff evidence | Doctor + redacted chain report | Response, Metadata, Trailers, and Test results | Single response view; limited gRPC testing and history support | Debug timeline, variables, and test reports |
| Diagnosis handoff Handoff to another engineer | failed step, schema source, and context in one redacted report | Strong collaboration and comments | Local / Git / Cloud sharing depends on storage mode | Strong collaboration, docs, and sharing |
This compares daily gRPC debugging experience, not the full API platform surface. Use Postman for API lifecycle management, Apifox for an integrated team API collaboration platform, Insomnia for a lean general API client, and RPCORA when requests, schemas, responses, and debug context should stay on the machine while you build Proto/Reflection trees, debug local chains, and keep diagnosis evidence.
gRPC Workbench
Turn gRPC debugging into a traceable desktop workflow.
02
Context Auth and variables move with the call
Environment variables, Auth, Metadata, TLS, and runtime bindings resolve before send time.
Runtime bindings03
Evidence Failures become usable evidence
Chain steps, gRPC status, duration, schema source, and Doctor results form a redacted debugging report.
Doctor report Product Demos 3 short demos · about 1 minute
See how RPCORA completes a gRPC debugging run.
Connect to a service, read schema, compose Payload, Metadata, and Auth, then run the request and inspect the response. When Reflection is unavailable, import a Proto folder and keep debugging.
01Discover service02Compose request03Run debug
Workflow
From service discovery to chain replay, RPCORA keeps the context intact.
A single request is not an isolated action. RPCORA connects schema, Payload, Auth, Metadata, runtime variables, and diagnosis so each debug run can become the next replayable path.
Local workspaceUnary chain replayDoctor evidence
RPCORA / run desk Reflection connected
Discover service
Connect to a target and read service, method, request, and response types.
Compose payload
Handle required fields, oneof, maps, and arrays inside the Request Body Composer.
Bind runtime values
Bind upstream responses, environment variables, and Metadata into downstream requests.
Replay chain
Run saved requests in order, find the failed step, and produce Doctor results.
01messageuser.v1.GetUserRequest
02user_idenv.USER_ID
03with_profiletrue
04trace_id{{session.traceId}}
05metadata+ 3 entries
No errors6/6 fields filled
Evidence
A report should be runnable evidence, not a screenshot.
When a call fails, RPCORA keeps resolved context, Doctor checks, and chain reports in one evidence panel. You can see where the failure happened, which context was present, and what to inspect next.
Inspect variables before sending
{{session.token}}, {{profile.user_id}}, trace IDs, and other context are visible before runtime.
Context readyTurn failures into workable clues
Target, TLS, Metadata, Reflection, Proto fallback, and gRPC status stay separated.
4 checks passedShare redacted evidence with the team
Reports keep chain steps, duration, error summary, and next actions while hiding sensitive values.
Redacted Doctor Report redacted
step03 · profile.UserService/GetUser
schemaReflection · user.v1.GetUserRequest
metadataauthorization: Bearer ******
statusOK · 120ms
For Teams
Built for people who debug services every day.
Local and internal service debugging
Run a single gRPC method, save reusable requests, and replay the context behind authenticated business calls.
Replay critical paths consistently
Fix login, query, create, and verify steps into a chain, then share a redacted failure report with engineers.
Inspect TLS, metadata, and schema problems
Quickly separate target, certificate, permission, reflection, Proto, and response-shape failures.
Why RPCORA
RPCORA is not another request panel. It keeps gRPC debugging context on one path.
RPCORA is built for real service debugging: understand schema, run the request, then keep context, replay paths, and diagnosis evidence inside the local workbench.
gRPC debugging starts with schema
RPCORA treats services, methods, message types, Metadata, TLS, and gRPC status as first-class debugging context instead of a generic URL form.
Runtime context moves between calls
Login, auth, user IDs, trace IDs, and environment variables can move across saved requests, turning a working call into a repeatable business path.
Debugging output becomes shareable evidence
Doctor and chain reports organize failed steps, schema source, runtime variables, duration, and gRPC status for backend, QA, and platform teams.
Inputhost:port + schema
ResolveMetadata · Auth · TLS
Replaytoken → userId → traceId
ShareDoctor report · redacted
Use RPCORA When
When gRPC debugging depends on context, chains, and evidence, RPCORA becomes the clearer path.
When debugging needs full gRPC context
Discovery, Payload, Metadata, Auth, TLS, response status, and runtime variables stay in one desktop workbench.
When one call should become a replayable chain
Save working requests as steps, then connect login, auth, query, and verification into a stable replay path.
When results need to travel to another engineer
Doctor and chain reports explain the failed step, runtime context, and practical next action with structured evidence.
Community
Join the RPCORA QQ community for real debugging discussions.
Use it for desktop app feedback, gRPC workflow questions, and Proto, Reflection, TLS, or Auth debugging cases.
RPCORA Technical Community QQ group 739750887
Scan with QQ to join
Download
Download RPCORA, run one gRPC method, then replay the chain.
Start small: install the desktop app, run one request in APIs, save it, then replay a two-step chain.
Available now Download · 208.6 MB Available now Download · 98.4 MB Available now Download · 118.6 MB
macOS
For Apple Silicon and Intel Mac. Recommended for regular installation.
Windows
For Windows x64 desktops with the standard installer flow.
Linux
Single-file AppImage package. Make it executable before launching.