> ## Documentation Index
> Fetch the complete documentation index at: https://docs.marioded.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Build with Reverse

> Turn match lifecycle events into recordings, playback, and custom replay experiences.

# Build with Reverse

Connect Reverse to the way your server already works. Start with the feature you want to build, then choose the API for the machine where it runs.

## Choose your integration

> [card] [Record a match](recording)
>
> Start when the arena is ready. Save when the game finishes. Keep the replay ID with your match.

> [card] [Add a Watch button](playback)
>
> Authorize a selection and start local playback, or send a viewer through your lobby.

> [card] [Make it your own](ui-extensions)
>
> Add menu actions, hotbar controls, and game-specific replay events.

## Learn the API from the beginning

The introduction builds one recording integration a little at a time. Start with service discovery, create a recording, then add arena bounds and participant selection to the same example.

| Step | What you will build or learn |
| - | - |
| [1. Setting up](https://docs.marioded.com/api/getting-started.md) | Add the dependency and declare the runtime plugin. |
| [2. Services, recordings, and sessions](https://docs.marioded.com/api/concepts.md) | Understand the objects you will use and which UUID identifies each one. |
| [3. Creating your first recording](https://docs.marioded.com/api/first-recording.md) | Connect a minimal start/stop integration to a match. |
| [4. Improving your recording](https://docs.marioded.com/api/improving-recording.md) | Select the arena and participants, and handle persistence outcomes. |

## Which API do I need?

| Your plugin runs on… | Start with | Typical feature |
| - | - | - |
| A gameplay server | `api-recorder` | Automatic recording, arena bounds, participants, save notifications. |
| A replay server | `api-player` | Playback, seeking, speed, viewer controls, custom rendering. |
| A selection lobby | `api-lobby` | Authorized catalog selection and proxy dispatch. |

Shared data contracts live in `api`; menu action contracts live in `api-gui`. Player and recorder can run on separate machines, so keep their role-specific bindings separate too.

## Browse by task

| Task | Guide |
| - | - |
| List, rename, or delete recordings safely | [Catalog and storage](https://docs.marioded.com/api/catalog-and-storage.md) |
| Notify players after a save really finishes | [Events](https://docs.marioded.com/api/events.md) |
| Register a custom catalog button | [Menu actions](https://docs.marioded.com/api/menu-actions.md) |
| Add an in-playback control | [Hotbar controls](https://docs.marioded.com/api/hotbar-controls.md) |
| Handle completion callbacks correctly | [Threading and failures](https://docs.marioded.com/api/threading-and-failures.md) |
| Move a viewer to a replay server | [Availability and dispatch](https://docs.marioded.com/api/availability.md) |
| Follow an end-to-end implementation | [Integration recipes](https://docs.marioded.com/api/recipes.md) |
| Copy a complete integration example | [Example gallery](https://docs.marioded.com/examples/index.md) |

> [!WARNING]
>
> **Authorize before playback.** Raw storage and playback methods are building blocks, not catalog permission checks. Use a trusted actor and the catalog when serving a player's selection.

## Going deeper

Add [custom recordables](https://docs.marioded.com/api/recordables.md) for portable game-specific events. Implement [terrain providers](https://docs.marioded.com/api/terrain-providers.md) or [protocol adapters](https://docs.marioded.com/api/adapters.md) only when extending the runtime itself. Ordinary minigame integrations do not need to replace these internals.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.