GET /v1/checkouts, porém restringe implicitamente o catálogo à sub-organização :orgId: só entram sessões cujo product_id resolve para um produto com organization_id igual a :orgId.
Use quando quiser uma URL explícita por vendedor filho (análogo a /v1/sdk/organizations/:orgId/products e /discounts), em integrações de marketplace.
Autenticação
- Supabase JWT da organização pai (
Authorization: Bearer). - A API verifica em
organization_relationshipsque o token pertence ao pai direto de:orgId.
Escopos
É necessário pelo menos um dos escopos:web:read, web:write ou checkouts:read (mesma regra que GET /v1/checkouts).
Parâmetros de path
UUID da sub-organização (filha). Apenas checkouts cujo produto principal pertence a essa org entram no resultado (após os filtros abaixo).
Query (opcional)
Os parâmetros são os mesmos deGET /v1/checkouts. O filtro por organização não precisa ser enviado no query: ele é aplicado automaticamente com :orgId.
Restringe a checkouts com esse produto principal (deve ser produto da sub-org; caso contrário a lista pode ficar vazia).
Filtra por cliente associado ao checkout.
Um ou mais valores:
open, confirmed, succeeded, failed, expired (conforme suporte da API para múltiplos valores).Busca parcial por e-mail do cliente (
customer_email).Tamanho da página. Padrão:
20.Página (base 1). Padrão:
1.Ordenação estilo Polar, ex.:
-created_at. Pode ser repetido na query HTTP se o cliente enviar vários sorting=.Resposta
Objeto comitems (lista de checkouts) e pagination:
total_count— total de registrosmax_page— última página para olimitusado
Erros comuns
| HTTP | Motivo |
|---|---|
401 | Token ausente ou inválido |
403 | Token não é JWT de pai de :orgId, ou escopos insuficientes |
500 | Erro interno ao consultar o banco |

