SDKs
An SDK is a convenience, not a requirement. It gives you a typed client, the message types, and credential handling; everything it does is available by calling the API directly.
Support matrix
Section titled “Support matrix”| SDK | Package | Transport | Status |
|---|---|---|---|
| .NET | Invokation.Match.Sdk | gRPC | Available |
| Others | — | — | More languages are planned. See Availability & Roadmap |
No SDK for your language
Section titled “No SDK for your language”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 you can explore the surface without the protos in hand.
- HTTP/JSON: the same operations, using the canonical protobuf JSON mapping. Worth choosing for Unreal or Unity dedicated-server code, PHP or Ruby backends, and serverless functions, where a gRPC toolchain is more trouble than it is worth.
Both are covered in Matchmaking API § Two transports, one API.
What every SDK does the same way
Section titled “What every SDK does the same way”The integration shape is identical whichever SDK you use, because the constraints come from the service rather than the client:
- You generate ticket IDs. They must be UUIDs. Because the ID is yours, 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 your backend.
- Consumers must be idempotent, because delivery is at-least-once.