Skip to content

Availability & Roadmap

These docs deliberately describe work that is designed but not yet shipped, so that integration work can be sized before it lands. This page lists what is available 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 the game backend is not yet available
Match host selectionPreferred host plus every mutually acceptable alternative
.NET SDKInvokation.Match.Sdk

Each item lists what it changes for the integration.

CapabilityWhat it means for the integration
HTTP/JSON transportThe same operations without a gRPC toolchain. This removes the blocker where gRPC is difficult to use 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. Outcomes are received on an HTTPS endpoint owned by the game backend, with an HMAC signature to verify. Requires an HTTP handler and a shared secret, no client library. The handler should acknowledge quickly and process asynchronously
WebSocket outcome deliveryStreamed outcomes with resumable offsets, for backends that cannot expose an inbound HTTPS endpoint. The 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 delivery can be repointed 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. Integrations can be designed against the documented flow, but a launch should not depend on it
Matchmaker-driven provisioningIVK Match requests the game server itself and delivers a match that is ready to join, instead of the game backend provisioning on receipt. Removes a round trip and a failure surface from the game 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, the documented contract can be built against. If it says field names are provisional, the page describes intent rather than a contract.

Organisation, game, portal, and credential capabilities are covered under Platform.