/storefront/storeDados públicos da loja (nome, contatos, checkoutEnabled e os campos do checkout) para header/footer e checkout.
Resposta (publicStoreInfoSchema)
| Campo | Tipo | Obrigatório |
|---|---|---|
| name | string | sim |
| string | null | sim | |
| phone | string | null | sim |
| string | null | sim | |
| address | objeto | null | sim |
| checkoutEnabled | boolean | não |
| checkoutFields | objeto | não |
{
"name": "Minha Loja",
"checkoutEnabled": true,
"checkoutFields": {
"cpfCnpj": "optional",
"phone": "required",
"company": "off",
"birthDate": "off"
},
"email": "contato@minhaloja.com.br",
"phone": "(11) 4000-0000",
"whatsapp": "(11) 99999-0000",
"address": {
"street": "Av. Paulista",
"number": "1000",
"district": "Bela Vista",
"city": "São Paulo",
"state": "SP",
"cep": "01310-100"
}
}checkoutEnabled: false(spec 19 RN-20, vitrine congelada) significa que a loja está no ar e navegável mas NÃO vende: esconda botões de compra, carrinho e "comprar agora". O checkout responde422 PLAN_CHECKOUT_DISABLEDde qualquer forma: a flag existe para o cliente final não bater no erro.checkoutFields(spec 15 RN-08) diz o que a etapa de identificação deve pedir:off= não renderize,optional= renderize sem asterisco,required= renderize com asterisco e bloqueie o avanço. **Já vem resolvido**: ocpfCnpjchegarequiredsozinho quando o lojista habilita boleto ou emissão de NF-e, então o tema não precisa (nem deve) refazer essa conta.- Tema que ignora
checkoutFieldsquebra de dois jeitos, e os dois já aconteceram: combirthDate: "required"oPOST /storefront/checkout/completeresponde422por um campo que a tela não pediu; e comcpfCnpj: "optional"a tela segue exigindo um documento que a loja não usa, desfazendo a minimização que o servidor aplicou.