Skip to content

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.

CapabilityNotes
Ticket lifecycleCreate, cancel, and reactivate tickets; expiry and removal outcomes
Nemesis match engineTeam shape, skill scoring, latency filtering and scoring, attribute filters, parties, team balancing
Queues and rulesetsMultiple rulesets per queue, shared engine defaults, fairness arbitration between rulesets
Hot configuration reloadConfiguration changes apply without a restart or redeploy
gRPC transportmatchmaker.core.v1.MatchmakerService, over TLS with a bearer token
Outcome generationOutcomes are produced and recorded durably, at-least-once, ordered per queue. Delivery to your backend is what is missing
Match host selectionPreferred host plus every mutually acceptable alternative
.NET SDKInvokation.Match.Sdk

Each item lists what it changes for you, since that is the part you have to plan around.

CapabilityWhat it means for your integration
HTTP/JSON transportThe 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 deliveryThe 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 deliveryStreamed outcomes with resumable offsets, for backends that cannot expose an inbound HTTPS endpoint. Your client owns reconnection and offset bookkeeping
Per-queue sink selectionChoose 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 payloadsPost 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 fulfilmentThe 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 provisioningIVK 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 SDKsAdditional language clients. Nothing about the integration shape changes; the API is the same underneath
Credentials in the .NET SDKThe builder will take a token directly. Until then, pass one via WithHttpClient; see .NET SDK § Authentication
Queue management in the portalCreate, edit, and retire queues from the browser, with a YAML editor. The YAML contract is settled and unchanged by this

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.