Frontend — Diferenças de Contrato

POST /api/show-case-new/

O que mudou no request: campo showCaseType adicionado.

{
  "schema": "arezzo",
  "storeId": 123,
  "storeName": "Loja Centro",
  "maxInstallments": 10,
  "userId": 456,
  "userName": "João Silva",
  "userPhone": "11999999999",
  "name": "Vitrine de Verão",
  "codeBrand": 1,
  "dateExpiration": "2026-07-25T00:00:00",
  "showCaseItems": [],
+ "showCaseType": "SellerStock"
}

Response: sem alteração.

Valores de showCaseType (enum C# serializado como string):

Valor (JSON)	Tipo
"Brand"	Brand
"Store"	Store (vitrine personalizada)
"Recommendation"	Recommendation
"BrandSeller"	BrandSeller
"SellerStock"	SellerStock (estoque da loja)

Regras:

• showCaseType = "SellerStock" → showCaseItems ignorado
• showCaseType = "SellerStock" → só pode existir uma por (userId, storeId). Atualizado em 03/07: a API SHALL NOT retornar erro quando já existir uma vitrine SellerStock ativa para o (userId, storeId) — nesse caso, o POST retorna 200 OK com os dados da vitrine existente (comportamento "get-or-create"), e não cria duplicata. O App trata a resposta como sucesso normal (não há mais um caminho de "erro de duplicata" a tratar no client).

---

PUT /api/show-case-new/

O que mudou no request: campo showCaseType adicionado.

{
  "id": "ce30e80b-88c8-4e6c-806f-abbca51940cc",
  "dateCreated": "2026-06-01T10:00:00",
  "schema": "arezzo",
  "storeId": 123,
  "storeName": "Loja Centro",
  "maxInstallments": 10,
  "userId": 456,
  "userName": "João Silva",
  "userPhone": "11999999999",
  "name": "Vitrine de Verão",
  "codeBrand": 1,
  "dateExpiration": "2026-07-25T00:00:00",
  "showCaseItems": [101, 102, 103],
+ "showCaseType": "SellerStock"
}

Response: sem alteração.

Regras:

• showCaseType = "SellerStock" → API ignora todos os campos exceto dateExpiration

---

GET /api/show-case-new/v2/store/{storeId} ← NOVO ENDPOINT

Versão evoluída do GET /api/show-case-new/store/{storeId}. Usar este no lugar do v1 para a tela de listagem de vitrines.

Request: igual ao v1.

GET /api/show-case-new/v2/store/123?pageNumber=1&pageSize=10&termSearch=vitrine&orderBy=1
Authorization: Bearer {token}

O que mudou no response: estrutura de paginação alterada + campos hasSellerStock e hasNext adicionados.

- {
-   "items": [...],
-   "total": 1,
-   "pageNumber": 1,
-   "pageSize": 10
- }

+ {
+   "data": [...],
+   "total": 1,
+   "pageNumber": 1,
+   "pageSize": 10,
+   "hasSellerStock": true,
+   "hasNext": false
+ }

Atualizado em 03/07: hasNext (bool) é exposto diretamente pelo backend — o App não precisa calculá-lo a partir de total/pageNumber/pageSize.

Uso do hasSellerStock:

• true → vendedor já tem vitrine SellerStock ativa → desabilitar botão de criação
• false → vendedor não tem → habilitar botão de criação

---

GET /api/show-case-new/products?id={showCaseId}

Sem alteração de contrato. Request e response idênticos. A mudança é apenas interna na API.

---

GET /api/show-case-new/app/{showCaseId}

O que mudou no response: campos showCaseType e totalItems adicionados.

{
  "id": "ce30e80b-88c8-4e6c-806f-abbca51940cc",
  "dateCreated": "2026-06-01T10:00:00",
  "dateExpiration": "2026-07-25T00:00:00",
  "schema": "arezzo",
  "storeid": 123,
  "storename": "Loja Centro",
  "codeBrand": 1,
  "url": "https://...",
  "maxinstallments": 10,
  "userid": 456,
  "username": "João Silva",
  "userphone": "11999999999",
  "name": "Vitrine de Verão",
+ "showCaseType": "SellerStock",
+ "totalItems": 87,
  "showCaseitems": [...]
}

Comportamento do showCaseitems por tipo:

showCaseType	showCaseitems	totalItems
"Store"	Lista completa dos produtos curados	Quantidade da lista
"SellerStock"	4 primeiros produtos (preview)	Count total do estoque da loja no ES