Start by running one gRPC request in APIs.
Docs RPCORA Documentation
RPCORA Documentation
From one request to chain replay
A practical onboarding path for connecting services, resolving schema, composing requests, saving chains, and reading Doctor evidence.
- 01Enter gRPC target
- 02Discover service.method
- 03Save request and replay chain
127.0.0.1:50051 user.UserService/GetUser metadata.authorization = Bearer ...
Quickstart
Recommended order
Start with the smallest working path, then add Auth, Metadata, environment variables, and Chains.
Use a host:port target, such as 127.0.0.1:50051 or grpc.internal.company:443.
If Reflection fails, import a local Proto directory or a Git Proto repository.
Save the request, then open Chains and add saved requests in sequence.
Configure an extractor on an upstream step, such as body.token -> session.token.
Use runtime variables like {{session.token}} in downstream requests, then run the whole chain.
Suggested path Run one request in APIs -> save it -> compose steps in Chains -> inspect Doctor evidence.
Concepts
Understand the four core concepts first
Single request debugging
Select service.method, configure Payload, Metadata, Auth, TLS, and inspect response, status, and duration.
Reflection or Proto
Use Reflection for direct service discovery, or Proto when Reflection is unavailable or schema should be pinned.
Connect requests into paths
Saved unary requests can run in sequence and extract upstream response values into downstream runtime variables.
Diagnose failed calls
Doctor organizes target, TLS, Metadata, schema source, and gRPC status into workable evidence.
Target & Schema
Use a gRPC target, then choose how RPCORA reads schema
Use a gRPC target, not an HTTP URL
Correct:
127.0.0.1:50051
api.example.com:443
grpc.internal.company:8443
Wrong:
/v1/user/login
/api/order/create
https://api.example.com/v1/user/login
When to use Reflection or Proto
R
ReflectionFor development environments or services with Server Reflection enabled, RPCORA can discover services and methods directly.
P
ProtoFor production, third-party, or Reflection-disabled services, import a local Proto directory or Git Proto repository.
Chain Replay
Turn working requests into replayable chains
Chains fit paths such as login then query, create then fetch, or generate then verify.
Step 1Save the upstream request
Confirm the response shape first, such as a login call returning a token.
Step 2Configure extractors
Extract values from Body, Metadata, Trailers, or Status, such as body.token -> session.token.
Step 3Inject downstream context
Use runtime variables such as {{session.token}} in downstream Payload, Metadata, or Auth.
Step 4Run the full chain
When a step fails, inspect the failed step, resolved context, and Doctor diagnosis.
Doctor
Diagnosis is organized as evidence
Requirements
Runtime requirements
- Node.js 20.x or later for local development.
- Desktop runtime targets macOS, Windows, and Linux.
- The debug target should be a real gRPC service address, such as 127.0.0.1:50051.
- Reflection gives the best experience; when disabled, use Proto files or a Git Proto repository.
FAQ
Frequently asked questions
What is RPCORA best suited for?
RPCORA is built for local, internal, and microservice gRPC debugging, especially when Reflection/Proto, Metadata/Auth, runtime variables, and chain replay are part of the workflow.
Can RPCORA work without Server Reflection?
Yes. When Reflection is unavailable, import a local Proto directory or Git Proto repository to select methods, compose request bodies, and run calls.
Why use Chains?
Many business calls depend on login, auth, tenant, user ID, or trace context. Chains run saved requests in sequence and inject upstream values into downstream calls.
How should sensitive tokens be handled?
RPCORA is a local-first desktop workbench, so workspaces, requests, environments, history, and settings stay local first. Shared reports should use redacted content.