Compatibilidade
O que está implementado do Open Delivery 1.4.0, o que é extensão MeuPedido e o que ainda não existe.
A API segue o Open Delivery 1.4.0 (Abrasel), módulos Order e Merchant, com o MeuPedido no papel de aplicação de pedidos: o pedido nasce no MeuPedido e o seu sistema o recebe e o conduz. Esta página é o inventário exato do que existe, para você saber o que pode reaproveitar de uma integração Open Delivery já feita e o que precisa tratar como específico do MeuPedido.
Legenda da coluna Situação:
- Implementado segue o padrão 1.4.0. Uma integração Open Delivery genérica funciona sem mudança.
- Extensão não existe no padrão, ou existe com comportamento diferente. Está documentado aqui e marcado nas páginas.
- Não implementado: previsto no padrão, ainda não disponível. Chamadas a essas rotas devolvem
404.
Autenticação
| Recurso do padrão 1.4.0 | Situação | Observação |
|---|---|---|
POST /oauth/token com grant_type=client_credentials | Implementado | Corpo application/x-www-form-urlencoded (canônico). Alias POST /v1/oauth/token. |
| Credenciais em JSON no corpo | Extensão | application/json com grant_type, client_id e client_secret, aceitando também camelCase. |
| Credenciais em HTTP Basic | Extensão | Authorization: Basic base64(client_id:client_secret) com grant_type no corpo. |
| Resposta do token | Implementado | Traz access_token, token_type, expires_in e scope, mais as cópias camelCase accessToken, tokenType, expiresIn. |
Escopo od.all | Não implementado | Use os escopos granulares orders:read, orders:write, merchant:read e catalog:read. |
| Refresh token | Não implementado | O token vale 3600 s. Peça outro com as mesmas credenciais. |
Pedidos (módulo Order)
| Recurso do padrão 1.4.0 | Situação | Observação |
|---|---|---|
GET /v1/orders/{orderId} | Implementado | Estrutura do pedido campo a campo em Estrutura do pedido. |
POST /v1/orders/{orderId}/confirm | Implementado | Leva o pedido a ACCEPTED. |
POST /v1/orders/{orderId}/readyForPickup | Implementado | Leva o pedido a READY. |
POST /v1/orders/{orderId}/dispatch | Implementado | Leva o pedido a DELIVERY. Não vale para pedido INDOOR. |
POST /v1/orders/{orderId}/delivered | Implementado | Leva o pedido a DONE. |
POST /v1/orders/{orderId}/requestCancellation | Extensão | No padrão é um pedido de cancelamento que o outro lado aceita ou nega. No MeuPedido cancela imediatamente (CANCELLED). reason é opcional; code é ignorado. |
POST /v1/orders/{orderId}/acceptCancellation | Não implementado | Não há fluxo de aceite porque o cancelamento é imediato. |
POST /v1/orders/{orderId}/denyCancellation | Não implementado | Idem. |
POST /v1/orders/{orderId}/startPreparation | Extensão | Leva o pedido a PREPARING. |
POST /v1/orders/{orderId}/pickedUp | Extensão | Leva o pedido a DONE em pedidos de retirada ou mesa. |
Header Idempotency-Key nas ações | Extensão | Replay da resposta gravada por 24 h; reuso com requisição diferente devolve 409. |
Resposta 202 com status e situation | Extensão | O padrão só define o 202. O corpo com accepted ou already_applied e o estado resultante é acréscimo. |
| Retrocesso de estado | Extensão | A partir de ACCEPTED, qualquer ação para um estado anterior é aceita (ex.: confirm em PREPARING volta a ACCEPTED) e não gera evento. |
Valores monetários { value, currency } | Implementado | currency é sempre BRL. |
| Datas ISO 8601 | Implementado | Sempre em UTC com sufixo Z. |
Eventos
| Recurso do padrão 1.4.0 | Situação | Observação |
|---|---|---|
GET /v1/events:polling | Implementado | Query limit (padrão 100, máximo 200). Responde array vazio quando não há eventos, nunca 204. |
POST /v1/events/acknowledgment | Implementado | Corpo [{ "id": "<eventId>" }]. Responde 202 com { "acknowledged": n }. |
Alias GET /v1/events/:polling | Extensão | Caminho antigo, com barra antes de :polling. Continua funcionando por compatibilidade com integrações já feitas, mas o caminho oficial é /v1/events:polling. Não use em integrações novas. |
Filtro eventType no polling | Não implementado | Todos os tipos vêm no mesmo feed. Filtre do seu lado. |
Header x-polling-merchants | Não implementado | Cada credencial pertence a uma loja; o feed já é por loja. |
POST /v1/newEvent (push do padrão) | Não implementado | Para receber eventos por push, use os webhooks MeuPedido. |
Campo orderURL no evento | Implementado | URL completa do pedido, para GET com o mesmo token. |
Campo sourceAppId no evento | Implementado | Presente quando houver. |
Evento CREATED | Implementado | Pedido criado, ou PIX confirmado no caso de pagamento online. |
Evento CONFIRMED | Implementado | Pedido ACCEPTED. metadata vem como {}. |
Evento READY_FOR_PICKUP | Implementado | Pedido READY; também quando um TAKEOUT ou INDOOR vai a DELIVERY. |
Evento DISPATCHED | Implementado | Pedido de entrega em DELIVERY. |
Evento CONCLUDED | Implementado | Pedido DONE. |
Evento CANCELLED | Implementado | metadata traz reason e code (CONSUMER_CANCELLATION_REQUESTED ou OTHER_CANCELLATION_REASON). |
Evento PICKUP_AREA_ASSIGNED | Não implementado | Nunca emitido. |
Evento DELIVERED | Não implementado | Nunca emitido. A conclusão chega como CONCLUDED. |
Evento CANCELLATION_REQUESTED | Não implementado | Nunca emitido: o cancelamento é imediato. |
Evento CANCELLATION_REQUEST_DENIED | Não implementado | Nunca emitido. |
Evento PREPARING | Extensão | Pedido em preparo. |
Evento MODIFIED | Extensão | Conteúdo do pedido editado. Busque o pedido de novo em orderURL. |
Eventos COURIER_* | Extensão | COURIER_ASSIGNED, COURIER_ROUTE_STARTED, COURIER_PICKED_UP, COURIER_ARRIVED, COURIER_DELIVERED, COURIER_DELIVERY_FAILED, COURIER_UNASSIGNED, COURIER_ROUTE_COMPLETED. Trazem o bloco delivery com rota, entregador e status da parada. |
| Retenção de eventos | Extensão | Eventos confirmados são apagados após 30 dias; não confirmados permanecem no feed. |
Webhooks
| Recurso do padrão 1.4.0 | Situação | Observação |
|---|---|---|
| Entrega por webhook | Extensão | O padrão prevê POST /v1/newEvent no lado do integrador. O MeuPedido entrega o mesmo envelope do polling na URL HTTPS configurada pelo lojista, com assinatura HMAC-SHA256 nos headers X-MeuPedido-*. |
| Modo de entrega por credencial | Extensão | POLLING, WEBHOOK ou BOTH, definido ao criar a credencial. |
| Retentativas | Extensão | 5, 10 e 20 s; depois WEBHOOK_FAILED e o evento fica no polling. Após 20 falhas consecutivas a URL é desativada. |
| Confirmação | Extensão | Receber por webhook não confirma o evento. POST /v1/events/acknowledgment continua obrigatório. |
Loja e cardápio
| Recurso do padrão 1.4.0 | Situação | Observação |
|---|---|---|
GET /v1/merchant/{merchantId} | Implementado | Escopo merchant:read. O merchantId precisa ser o da credencial. |
GET /v1/merchant/{merchantId}/menus | Implementado | Escopo catalog:read. Array com um único cardápio. |
| Grupo "Tamanho" para variações | Extensão | Produto com vários preços vira grupo obrigatório com id {productId}-variacoes. |
| Item indisponível | Extensão | Continua no cardápio com status: "UNAVAILABLE" em vez de sumir. |
| Módulo Merchant do padrão (envio e atualização de cardápio pelo integrador) | Não implementado | O cardápio é editado pelo lojista no painel do MeuPedido. A API oferece leitura. |
Outros
| Recurso | Situação | Observação |
|---|---|---|
Campo test no pedido | Implementado | true em pedidos de loja de teste. |
Campo preparationStartDateTime | Implementado | Igual a createdAt em pedidos INSTANT e a scheduledDateTimeStart em SCHEDULED. |
Campo extraInfo | Implementado | Texto livre, por exemplo "obs | origem=X | canal=Y | numeroCanal=Z". |
| Ambiente de sandbox | Não implementado | Usa-se uma loja de teste em produção, criada pelo suporte sob pedido. |
| CORS | Extensão | Liberado apenas para https://developer.meupedido.io, para o playground do portal. Integrações são servidor a servidor. |
Como tratar as diferenças
- Integração Open Delivery já pronta: aponte para
https://api.meupedido.io/open-delivery, troque a rota de polling para/v1/events:pollingse ainda usa a forma com barra, e ignoreeventTypeque não conhece (as extensõesPREPARING,MODIFIEDeCOURIER_*), confirmando o evento mesmo assim. - Cancelamento: não espere
CANCELLATION_REQUESTEDnemacceptCancellation. QuandorequestCancellationresponde202, o pedido já estáCANCELLEDe o eventoCANCELLEDchega no feed. - Estados extras:
PREPARINGé opcional. Você pode ir deACCEPTEDdireto paraREADY,DELIVERYouDONE.
Quando um item desta lista mudar de situação, a mudança é publicada no Changelog.
Próximos passos
- Catálogo de eventos: quando cada tipo é emitido e o que traz.
- Ações e idempotência: as transições e o header
Idempotency-Key. - Referência de API: todas as operações disponíveis.