Order events
order.created, order.updated, order.sent_to_kitchen, order.paid and order.cancelled are emitted from core order workflows.
Webhooks.
Signed event delivery, retries, destination validation and consumer safety for Limvero integrations.
Event coverage
Public webhook events are tied to implemented restaurant lifecycle workflows.
Payment events
payment.refunded, payment.voided and payment.fiscal_receipt.recorded are emitted from payment, refund, void and fiscal recording workflows.
Delivery attempts
Delivery attempts are stored with retry state, response metadata and manual redelivery support in Restaurant Cabinet.
Delivery safety
Webhook delivery is designed for tenant isolation, safe destinations and idempotent consumers.
Signed payloads
Consumers must verify the Limvero HMAC signature against the raw request body before processing a webhook.
Destination validation
Webhook URLs must be HTTPS and are validated before storage and before delivery to reduce SSRF risk.
Retries and idempotency
Webhook consumers must treat event delivery as at-least-once and use idempotency for retried events.
Tenant management boundary
API key, webhook endpoint and redelivery management require a normal Restaurant Cabinet session, not a POS PIN session.
No private destinations
Local, private, reserved and unsafe destinations are blocked so webhook delivery cannot reach internal infrastructure.
Provider-specific connectors
Marketplace, fiscal, payment and delivery provider connectors remain scoped integration projects until selected and implemented.
Webhooks are managed in Restaurant Cabinet and should be tested against controlled tenant data before connecting production downstream systems.
Plan a clean restaurant rollout.
Talk through locations, POS devices, kitchen workflow, menu migration, API needs and security review before launch.