Skip to main content

Server To Server

Server RPCs​

Unlike client calls, server-to-server calls will never have a user ID, so for any functions you do not want accessible from clients just return an error if a user ID is found in the context.

Additionally, it can be useful to create HTTP REST handlers which can be used by web services and ease integration into custom server environments.

This can be achieved by using an RPC hook and the Runtime HTTP Key to authenticate with the server:

The registered RPC Functions can be invoked with any HTTP client of your choice. For example, with cURL you could execute the function with the server as follows.

curl "http://127.0.0.1:7350/v2/rpc/http_handler_path?http_key=defaulthttpkey" \
    -d '"{\"some\": \"data\"}"' \
    -H 'Content-Type: application/json' \
    -H 'Accept: application/json'

Notice that the JSON payload is escaped and wrapped inside a string. This is by design due to gRPC not having a type that would map between a Protobuf type and a JSON object at the time the RPC API was designed. Support for JSON has since been added to gRPC but we have kept it this way to not break the API contract and ensure compatibility.

An unwrap query parameter is supported which allows you to invoke RPC functions with raw JSON data in the payload:

curl "http://127.0.0.1:7350/v2/rpc/http_handler_path?http_key=defaulthttpkey&unwrap" \
    -d '{"some": "data"}' \
    -H 'Content-Type: application/json' \
    -H 'Accept: application/json'

Register Raw HTTP Handlers​

Power Users Only

This is Power User feature, most developers will not need to register their own HTTP handlers. Be careful when registering your endpoints as you could accidentally overwrite existing Layerg endpoints if you use existing paths.

You can attach new HTTP handlers to specified paths on the main client API server endpoint.