Encontrar evento e ativar wallet

Este é o fluxo que resolve "eu sou um usuário já cadastrado, quero participar de um evento — como o app acha esse evento e cria minha wallet nele?"

1. Participante digita o código do evento (ex.: AXY-9898)
   ou lê um QR que carrega o mesmo código
        ↓
2. GET /v1/wallet/events/by-code/AXY-9898   (wallet-control-api, via Edge)
        ↓
   devolve preview do evento — NÃO cria nada ainda
        ↓
3. App mostra nome/data/moeda do evento, participante confirma
        ↓
4. PUT /v1/events/{eventId}/wallets/current   (wallet-api regional, via Edge)
        ↓
   cria (ou devolve, se já existia) a wallet do participante nesse evento

Passo 1–2: buscar o evento pelo código

curl

curl http://127.0.0.1:8787/v1/wallet/events/by-code/AXY-9898 \
  -H "Authorization: Bearer <accessToken do participante>"

JavaScript

const response = await fetch(
  "http://127.0.0.1:8787/v1/wallet/events/by-code/AXY-9898",
  { headers: { Authorization: `Bearer ${accessToken}` } },
);
const event = await response.json();

Python

import requests

response = requests.get(
    "http://127.0.0.1:8787/v1/wallet/events/by-code/AXY-9898",
    headers={"Authorization": f"Bearer {access_token}"},
)
event = response.json()

Resposta

{
  "eventId": "018f26d7-8a7b-7e7d-8c96-4f0b8d0f2b10",
  "name": "Festival de Verão",
  "slug": "festival-de-verao",
  "eventCode": "AXY-9898",
  "timezone": "America/Sao_Paulo",
  "currencyCode": "BRL",
  "startsAt": "2026-12-15T18:00:00.000Z",
  "endsAt": "2026-12-16T04:00:00.000Z"
}

Pontos importantes:

• O código é aceito com ou sem traço, case-insensitive — axy9898, AXY-9898 e Axy 9898 resolvem igual.
• Esse endpoint exige login (token de participante) — não existe versão pública. Isso limita quem consegue tentar adivinhar códigos.
• Só evento com status=active é encontrado. Evento em provisionamento, suspenso ou arquivado responde 404 EVENT_NOT_FOUND — a mesma resposta genérica de "código não existe", de propósito.
• Essa chamada não cria wallet nenhuma. É só preview, pra o app mostrar antes de confirmar.

Passo 4: ativar a wallet

curl

curl -X PUT http://127.0.0.1:8787/v1/events/018f26d7-8a7b-7e7d-8c96-4f0b8d0f2b10/wallets/current \
  -H "Authorization: Bearer <accessToken do participante>"

JavaScript

const response = await fetch(
  `http://127.0.0.1:8787/v1/events/${eventId}/wallets/current`,
  { method: "PUT", headers: { Authorization: `Bearer ${accessToken}` } },
);
const wallet = await response.json();

Python

import requests

response = requests.put(
    f"http://127.0.0.1:8787/v1/events/{event_id}/wallets/current",
    headers={"Authorization": f"Bearer {access_token}"},
)
wallet = response.json()

Resposta

{
  "walletId": "0728a...",
  "eventId": "018f26d7-8a7b-7e7d-8c96-4f0b8d0f2b10",
  "status": "active",
  "availableAmountMinor": 0,
  "heldAmountMinor": 0
}

• Idempotente: chamar de novo com o mesmo participante/evento devolve a mesma wallet, sem duplicar nem zerar saldo.
• O userId vem do JWT — o cliente nunca escolhe de quem é a wallet.
• Roda numa única transação regional: cria a wallet, o saldo zerado e as contas de ledger (WALLET_AVAILABLE, WALLET_HELD) juntos. Se qualquer parte falhar, nada é gravado.
• Depois de criada, a wallet é sincronizada para o diretório global de forma assíncrona (segundos, não instantâneo) — veja Minhas wallets e Arquitetura → visão geral para entender esse atraso.

Consultar a wallet depois

GET /v1/events/{eventId}/wallets/current
Authorization: Bearer <accessToken do participante>

Mesmo formato de resposta do PUT. Responde 404 se o participante ainda não ativou a wallet nesse evento — nesse caso, chame o PUT primeiro.