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.