Skip to main content
Every deck-detail response (GET /api/public/v1/games/{game}/decks/{id}) carries a featured_cards array. It is the single, game-agnostic way to read a deck’s special cards: the MTG commander, partner, and companion, and the Riftbound legend, champion, and battlefields — all in the same shape, so one parser handles every game.

Entry shape

featured_cards is always present on deck-detail (it is [] for a deck with no special cards). It is also returned on both deck-list endpoints — GET /games/{game}/decks and GET /games/{game}/decks/my — when you pass ?include=summary, in the identical shape, so you can render special cards in a list without a per-deck detail fetch. See List summary fields. Without include=summary the list omits it; fetch a single deck to read it.

List summary fields

Add ?include=summary to either list endpoint to receive, per deck, the same featured_cards array shown above plus two more render-ready fields — no per-deck detail fetch needed:
All three keys are snake_case, and the two list endpoints return the exact same field names and casing — one parser handles both. /decks/my enriches the caller’s private decks too, not only public ones. The full per-section card inventory (expanded_cards) is never on the list; it stays detail-only behind ?expand=cards.

Grouping by slot

slot is the group key; slotKey distinguishes repeated slots. Riftbound’s two battlefields share slot: "battlefield" but keep distinct slotKeys:

Game coverage

The field is driven by each game’s special-card configuration, so it generalizes without client changes: A slot your code hasn’t seen before is still safe to render: label falls back to a title-cased version of the type, and the card fields are always populated the same way. Treat the set of slots as open-ended.