Skip to content

Trilhas por papel

O Open Delivery não exige que você implemente tudo. Cada sistema assume um (ou mais) papéis no ecossistema e declara no Discovery o que suporta.

Use esta página para montar um caminho de leitura e implementação alinhado ao seu produto.

Mapa rápido

Papel Quem é Capabilities típicas Comece por
Originador App de pedidos, marketplace, totem Orders, Merchant (consumo), Auth, Discovery Trilha Originador
Software Service (PDV) Gestão do restaurante / POS Merchant, Orders, Indoor, Auth, Discovery Trilha PDV
Logística Operador de entrega, frota Logistics (+ Orders contexto), Auth, Discovery Trilha Logística
Software CRM / Loyalty Dados do cliente, fidelidade, reviews Customer (módulos Reviews e Loyalty), Auth, Discovery Trilha Customer

Um mesmo produto pode combinar papéis (ex.: marketplace com frota própria = Originador + Logística).

Originador

Você cria pedidos e, em muitos fluxos, é dono do Merchant ID e do cardápio exibido ao consumidor.

O que implementar

  1. Discovery — manifesto well-known
  2. Autenticação — OAuth por aplicação
  3. Merchant: Dados da Loja + Menus
  4. Orders — criar pedidos, cancelar, consumir eventos/status
  5. Opcional: Logistics, Customer (push de clientes), Indoor (totem/QR)

Leituras

Tipo Link
Guia Primeiros Passos
Protocolo Orders · Merchant · Menus
API Referência Orders · Merchant
Migração V1→V2

Software Service (PDV)

Você é a fonte operacional da loja: confirma pedidos, envia cardápio, é autoridade da conta Indoor e, em muitos casos, da emissão fiscal.

O que implementar

  1. Discovery + Auth
  2. Dados da Loja + Menus — services, pause, CRUD/snapshot
  3. Orders — confirmação, preparo, eventos, cancelamento V2
  4. Indoor — se houver salão (Account, pagamentos, fiscal)
  5. Webhooks de eventos (e/ou polling onde o manifesto declarar)

Leituras

Tipo Link
Protocolo Merchant · Dados da Loja · Menus · Orders · Indoor
API Merchant · Orders · Indoor
Matrizes Eventos por perfil (Orders)

Logística

Você executa ou orquestra a entrega e emite eventos de tracking informativos (sem confundir com o status do pedido).

O que implementar

  1. Discovery + Auth
  2. Logistics — cotação, despacho, tracking, problemas
  3. Integração com contexto de Orders (eventos logísticos vs status)

Leituras

Tipo Link
Protocolo Logistics · Orders — status × eventos
API Logistics

Software CRM / Customer

Você cuida do relacionamento (dados do cliente): cadastro, leads, avaliações e programas de fidelidade. O produto costuma ser um Software CRM ou motor de fidelidade — a capability do protocolo é Customer (nunca “CRM”). Não altera o ciclo operacional do pedido na cozinha.

O que implementar

  1. Discovery + Auth (escopo od.crm)
  2. Customer — capability customer (declare as operações dos módulos ativos)
  3. Módulos opcionais da mesma capability (não são extensões):
  4. Reviews — pode ser implementado sozinho entre os módulos
  5. Loyalty — pode ser implementado sozinho entre os módulos

Leituras

Tipo Link
Protocolo Customer · Reviews · Loyalty
API Customer

Indoor (quando o salão é o produto)

Se o seu produto é totem, QR de mesa, tablet de garçom ou PDV de salão, trate Indoor como trilha principal — mas lembre: é extensão de Orders.

Papel no Indoor Responsabilidade
Software Service Hospeda Account, pagamentos, fiscal, eventos
Ordering Application Envia pedidos INDOOR, consome webhooks, UI de conta

→ Protocolo Indoor · especificação Indoor · Matriz de eventos de conta

Checklist comum a todos os papéis

  1. Publicar GET /.well-known/opendelivery
  2. Obter token OAuth (preferência: por aplicação)
  3. Listar merchants autorizados (GET /merchants quando aplicável)
  4. Implementar só as capabilities declaradas no manifesto
  5. Separar status (verdade no GET) de eventos (notificações)

Para o fluxo mínimo genérico, veja Primeiros Passos.

Relacionado