How to test gRPC from your phone

The six steps

• 1. Get your endpoint details — You need the host and port (e.g. api.example.com:443) and whether the server speaks TLS or plaintext. Production gRPC is almost always TLS on 443; local dev servers are usually plaintext on 50051.
• 2. Create a gRPC request in ReqPad — Open ReqPad, switch the protocol selector to gRPC and enter the endpoint. ReqPad is the only mobile API client with gRPC and Socket.IO support, so this is the step where other mobile tools stop being an option.
• 3. Load the schema — reflection or .proto — If the server has gRPC reflection enabled, ReqPad discovers services and methods automatically. If not, import the .proto file — the same one your backend repo already has.
• 4. Pick the method and write the message — Choose service and method, then fill in the request message. Fields, types and nesting come from the schema, so you are not guessing at shapes.
• 5. Add auth metadata — gRPC auth travels in metadata, the HTTP/2 equivalent of headers — typically authorization: Bearer <token>. Add it to the request before sending.
• 6. Send and read the result — Send the call and inspect the response message and the gRPC status. Remember gRPC has its own status codes (OK, UNAVAILABLE, UNAUTHENTICATED, DEADLINE_EXCEEDED…) — a transport-level 200 can still carry a failed call.

The two errors everyone hits first

UNAVAILABLE on the first call — almost always TLS vs plaintext. Production endpoints on 443 want TLS; dev servers on 50051 usually do not. Flip the connection security setting before debugging anything else.

UNAUTHENTICATED with a valid token — your token is fine, its delivery is not. gRPC does not read HTTP query params or cookie jars; the token must be in metadata, usually as authorization: Bearer …, lowercase key included. Decode the token first with our JWT decoder to rule out expiry before blaming the transport.