Availability & Roadmap
These docs deliberately describe work that is designed but not yet shipped, so you can size your side of the integration before it lands. Check here for what is real today.
Pages and sections covering unshipped work carry a Coming soon marker. If a page has no marker, it describes current behaviour.
Available today
Section titled “Available today”| Capability | Notes |
|---|---|
| Ticket lifecycle | Create, cancel, and reactivate tickets; expiry and removal outcomes |
| Nemesis match engine | Team shape, skill scoring, latency filtering and scoring, attribute filters, parties, team balancing |
| Queues and rulesets | Multiple rulesets per queue, shared engine defaults, fairness arbitration between rulesets |
| Hot configuration reload | Configuration changes apply without a restart or redeploy |
| gRPC transport | matchmaker.core.v1.MatchmakerService, over TLS with a bearer token |
| Outcome generation | Outcomes are produced and recorded durably, at-least-once, ordered per queue. Delivery to your backend is what is missing |
| Match host selection | Preferred host plus every mutually acceptable alternative |
| .NET SDK | Invokation.Match.Sdk |
Coming soon
Section titled “Coming soon”Each item lists what it changes for you, since that is the part you have to plan around.
| Capability | What it means for your integration |
|---|---|
| HTTP/JSON transport | The same operations without a gRPC toolchain. This is what unblocks you if gRPC is painful in Unreal, Unity server code, PHP, Ruby, or a serverless runtime. Field names, validation, and error semantics are identical, so switching later is an envelope change |
| Webhook outcome delivery | The blocker for a production integration. Receive outcomes on an HTTPS endpoint you own, with an HMAC signature to verify. An HTTP handler and a shared secret, no client library. Plan for a handler that acknowledges fast and processes asynchronously |
| WebSocket outcome delivery | Streamed outcomes with resumable offsets, for backends that cannot expose an inbound HTTPS endpoint. Your client owns reconnection and offset bookkeeping |
| Per-queue sink selection | Choose delivery per queue rather than per game, so two queues can deliver to different endpoints and you can repoint delivery with a configuration edit |
| JSON-native engine payloads | Post the engine payload as a plain JSON object instead of base64-encoded protobuf. Removes the need for HTTP clients to carry protobuf at all |
| Backfill fulfilment | The backfill API, pool model, and outcome types exist and accept requests, but the engine does not fill them yet: a request submitted today expires rather than producing a fill. Design against the documented flow, but do not gate a launch on it |
| Matchmaker-driven provisioning | IVK Match requests the game server itself and hands you a match that is ready to join, instead of you provisioning on receipt. Removes a round trip and a failure surface from your backend, and moves provisioning retry and compensation inside the service |
| More SDKs | Additional language clients. Nothing about the integration shape changes; the API is the same underneath |
| Credentials in the .NET SDK | The builder will take a token directly. Until then, pass one via WithHttpClient; see .NET SDK § Authentication |
| Queue management in the portal | Create, edit, and retire queues from the browser, with a YAML editor. The YAML contract is settled and unchanged by this |
Reading the markers
Section titled “Reading the markers”Anything not yet shipped is marked two ways, and both mean the same thing:
- A Coming soon callout at the top of the page or section it applies to.
- A Coming soon badge next to the page in the sidebar, when the whole page describes unshipped work.
Each callout also says how settled the design is. If it says the shape is settled, you can build against the documented contract. If it says field names are provisional, read the page as intent rather than as a contract.
Organisation, game, portal, and credential capabilities are covered under Platform.