SDKs

SDKs are optional. An SDK provides a typed client, the message types, and credential handling; everything it does is also available by calling the API directly.

Support matrix

SDK	Package	Transport	Status
.NET	Invokation.Match.Sdk	gRPC	Available
Others	—	—	More languages are planned. See Availability & Roadmap

Languages without an SDK

Both transports are documented and usable directly, and nothing in the service distinguishes a ticket created through an SDK from one created over raw gRPC or HTTP.

• gRPC: generate a client from the protobuf definitions. Server reflection is enabled, so the surface can be explored without a local copy of the protos.
• HTTP/JSON: the same operations, using the canonical protobuf JSON mapping. Suited to Unreal or Unity dedicated-server code, PHP or Ruby backends, and serverless functions, where a gRPC toolchain is impractical.

Both are covered in Matchmaking API § Two transports, one API.

What every SDK does the same way

The integration shape is identical regardless of SDK, because the constraints come from the service rather than the client:

• The caller generates ticket IDs. They must be UUIDs. Because the caller controls the ID, retrying a timed-out create is safe and cannot produce a duplicate.
• Creating a ticket does not return a match. It returns when the ticket is durably queued.
• Outcomes arrive out of band, not as the return value of any call. Consuming them is a separate path in the game backend.
• Consumers must be idempotent, because delivery is at-least-once.