Documentation menu

Testing gRPC APIs

Call gRPC services without .proto files — SchemaClient discovers services via server reflection, sends requests as plain JSON, and shows real gRPC status codes.

Updated

Most gRPC testing pain is not the calls — it is the ceremony of collecting .proto files before you can send anything. SchemaClient skips that entirely: it asks the server to describe itself over gRPC server reflection, the same mechanism grpcurl uses, so a host and port is all you need to start.

Switch the request to gRPC

In the URL bar, flip the protocol picker to gRPC. The URL field goes unused — a gRPC target is not a URL — and the gRPC panel takes over: a target field (host:port, e.g. 127.0.0.1:50051), a TLS toggle, and a Reflect button. TLS off means plaintext HTTP/2, which is what most local dev servers speak.

Reflect to discover services

Click Reflect. SchemaClient queries the server's reflection service and fills two dropdowns: the services it exposes and the methods on each. Selecting a method shows its input and output message types, and streaming methods are labeled (streaming) so you know before you try.

The one requirement is that the server has reflection enabled. Most servers can turn it on in a line or two — in Python with grpcio-reflection:

from grpc_reflection.v1alpha import reflection

reflection.enable_server_reflection(
    (SERVICE_NAME, reflection.SERVICE_NAME),  # your service + the reflection service
    server,
)

Go and Java have equivalent one-liners. There is deliberately no .proto import as a fallback — reflection is the only discovery path, so a server that does not reflect cannot be called from SchemaClient today.

Write the request as JSON

The Request sub-tab is a JSON editor: you write the request message as plain JSON using the standard proto3 JSON mapping — no binary encoding to think about.

{ "id": 1 }

If the JSON does not match the method's input message, the error names the message type it expected, instead of an opaque serialization failure.

The Metadata sub-tab is a key-value table sent as gRPC metadata — gRPC's version of headers. Keys are lowercased ASCII, which is what the wire format requires.

Send and read the response

Send performs a unary call and the result lands in the normal response viewer. A successful call reads like a 200-level success with the response message pretty-printed as JSON. A failed call shows the real gRPC status code name — UNAVAILABLE, UNAUTHENTICATED, and friends — with the server's error message, and the status name also appears as a grpc-status header row.

Current limitations

  • Unary calls only. Streaming methods are listed and labeled, but sending one is refused with a clear message rather than half-working. Client and server streaming are not supported yet.
  • Reflection is required. No reflection, no calls — see above.
  • gRPC does not go through the SchemaClient tunnel. Point the target directly at the server instead.

Contract-check gRPC messages

The schema language pins schemas to a gRPC method with the @grpc annotation:

@grpc("UserService.GetUser")
schema Request { id: UUID }

@grpc("UserService.GetUser")
schema Response { user: User }

The schema editor autocompletes and compiles @grpc blocks today, and the gRPC panel has a schema selector for attaching one to a request — but the automatic response check is not wired up for gRPC yet. Live validation currently covers REST bodies and WebSocket/SSE streams; gRPC response checking is in progress, not shipped. The annotation syntax and type system are covered in the schema language reference, and once the check lands the methodology will be the same as validating REST responses — catch shape drift before your clients do.

Frequently asked questions

Do I need .proto files to test gRPC in SchemaClient?

No. SchemaClient discovers services and methods through gRPC server reflection, the same mechanism grpcurl and Postman use. The trade-off: the server must have reflection enabled — there is no .proto import fallback, so a non-reflecting server cannot be called.

Does SchemaClient support gRPC streaming?

Not yet. Streaming methods show up in the method list labeled (streaming), but sending one is refused with a clear message. Only unary calls work today — client and server streaming are planned, not shipped.

Why does Reflect find no services on my gRPC server?

Almost always one of three things: the server does not have reflection enabled, the target host:port is wrong, or the TLS toggle disagrees with the server (plaintext server with TLS on, or the reverse). Most Go, Java, and Python servers can enable reflection in one or two lines.