Skip to main content
Cria uma sessão de checkout com o mesmo corpo que POST /v1/checkouts, com uma regra extra:
  • Todo produto envolvido na criação (product_id, ou produto derivado de product_price_id, ou cada ID em products[]) deve ter organization_id igual a :orgId.
  • Se você tentar usar um produto de outra sub-organização ou da org pai, a API responde 422 com mensagem clara (não expõe dados do produto alheio).
Isso evita ambiguidade em marketplaces com muitos vendedores: a URL deixa explícito para qual filho aquela sessão está sendo aberta.

Autenticação

JWT da organização pai, com vínculo direto para :orgId em organization_relationships.

Escopos

Pelo menos um de: web:write ou checkouts:write.

Parâmetros de path

string
required
UUID da sub-organização dona do catálogo. Os produtos do corpo devem pertencer a essa org.

Corpo

Igual a POST /v1/checkouts (campos em snake_case no HTTP). É obrigatório fornecer um entre:
  • product_id
  • product_price_id (produto inferido do preço)
  • products (lista de IDs de produto; o fluxo interno usa o primeiro como principal, como no endpoint principal)
Campos frequentes:
string
ID do produto da sub-org :orgId.
string
ID de preço; o produto associado deve ser da sub-org :orgId.
string
E-mail pré-preenchido no checkout.
string
Nome do comprador.
string
CPF/CNPJ quando aplicável.
integer
Valor em centavos quando usar preço customizado (mesmas regras do endpoint principal).
string
URL de retorno após sucesso.
object
Metadados arbitrários gravados na sessão.

Resposta

201 Created com o objeto checkout (inclui client_secret, url para abrir o fluxo, etc.), no mesmo formato que POST /v1/checkouts.

Erros

Exemplos

Checkout simples com produto e e-mail

Usando product_price_id (mesmo filho, preço explícito)

Erro esperado: produto de outra org no mesmo marketplace

Se OTHER_PRODUCT_ID for de outro filho (ou da pai), o path ainda aponta para CHILD_ORG_ID:

Variáveis (bash)