> ## Documentation Index
> Fetch the complete documentation index at: /docs/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Documentação das APIs da DeliveryVip, em português. Regras que mais quebram integrações: (1) Merchant API: faça polling em GET /merchant/v3/events:polling no máximo a cada 30 s por token; confirme todo evento recebido com POST /merchant/v3/events/acknowledgment e corpo [{"id": "<eventId>"}] (o campo lido é id, não eventId), inclusive eventos repetidos ou que o sistema não trata; deduplique por eventId; o evento é só um aviso, busque o pedido na orderURL. (2) Tokens client_credentials valem 24 h e não têm refresh_token: peça outro ao receber 401. (3) Webhooks: valide a assinatura HMAC sobre o corpo bruto e responda 2xx rápido; o polling é a reconciliação. (4) Open Delivery: host od.deliveryvip.com.br, um client_secret por loja, datas em UTC. (5) Fidelidade: o operador implementa 5 rotas assinadas com HMAC e chama o config push; o estorno precisa ser idempotente. (6) Partner API: scope dv.partner. Não invente endpoints: use a referência gerada das specs OpenAPI.

# Datas e horários

> O formato das datas nas APIs da DeliveryVip, o fuso de cada API e como interpretar os valores sem errar por 3 horas.

Todas as datas com horário seguem o **RFC 3339** (perfil do ISO 8601) e trazem o fuso explícito no próprio valor. O fuso usado, porém, muda conforme a API.

| API | Fuso | Exemplo |
| - | - | - |
| Merchant API V3 | **UTC-3** (horário de Brasília) | `2026-08-10T14:39:28-03:00` |
| Partner API V2 | **UTC-3** (horário de Brasília) | `2026-08-10T14:39:28-03:00` |
| [Open Delivery](/docs/guides/open-delivery.md) | **UTC** (sufixo `Z`) | `2026-08-10T17:39:28Z` |

Os três exemplos da tabela são **o mesmo instante**. O Open Delivery usa UTC porque a [especificação](https://abrasel-nacional.github.io/opendelivery/) exige: *"All dates must be sent using UTC as default"*.

> [!WARNING]
>
> **Não assuma o fuso: leia o offset.** Integrações que descartam o `-03:00` ou o `Z` e tratam o valor como hora local erram por 3 horas, principalmente quando falam com a Merchant API e com o Open Delivery ao mesmo tempo.

## Interpretando as datas

Qualquer biblioteca de datas moderna converte a partir do offset:

```js Node.js theme={null}
const createdAt = new Date('2026-08-10T14:39:28-03:00')
createdAt.toISOString() // '2026-08-10T17:39:28.000Z'

createdAt.getTime() === new Date('2026-08-10T17:39:28Z').getTime() // true
```

```python Python theme={null}
from datetime import datetime, timezone

created_at = datetime.fromisoformat("2026-08-10T14:39:28-03:00")
created_at.astimezone(timezone.utc)  # 2026-08-10 17:39:28+00:00

created_at == datetime.fromisoformat("2026-08-10T17:39:28+00:00")  # True
```

> [!TIP]
>
> Guarde as datas no seu banco em UTC (ou com o offset) e converta para o fuso da loja só na exibição.

## Datas sem horário

Filtros que recebem só a data, como `starts_at` e `ends_in` da [listagem de pedidos](/docs/guides/merchant/order/listar-pedidos.md), usam `YYYY-MM-DD` e são interpretados no fuso de Brasília: `starts_at` vale a partir de 00:00:00 e `ends_in` até 23:59:59 do dia informado.

```text theme={null}
/merchant/v3/{merchantId}/orders?starts_at=2026-10-01&ends_in=2026-10-15
```

## Horários de funcionamento

Os horários de funcionamento da loja (`timePeriods`, com `startTime` e `endTime`) são **hora local da loja**, no formato `HH:MM:SS` e sem offset. Eles descrevem um horário de relógio que se repete toda semana, não um instante.

```json theme={null}
{ "dayOfWeek": ["MONDAY"], "timePeriods": { "startTime": "18:00:00", "endTime": "23:30:00" } }
```

## Timestamps de autenticação

Os campos `created_at`, `exp` e `iat` das respostas de [autenticação](/docs/inicio/conceitos/autenticacao.md) são **Unix timestamps** (segundos desde 1970, em UTC), e `expires_in` é uma duração em segundos.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.