Is there a public API reference?

Not on this site. API documentation is shared with customers and evaluation teams. Request it through the contact form and the Dira team will share it with your engineers.

How does Dira prevent duplicate orders?

Every inbound event carries an idempotency key derived from its source. A webhook delivered twice, or a retry after a timeout, is matched to the existing record instead of creating a new order or a second POS check.

How is a new POS connected?

Through a POS adapter behind the Dira Bridge gateway contract. Each brand's connector is scoped and validated with that brand during deployment. The core and the other products do not change.

What security material can our team review?

Security questionnaires, the access model and architecture reviews are handled directly with your security team during evaluation.

Architecture and APIs

Contracts, events and adapters you can inspect.

Q: Can Dira run on Azure?

The current reference deployment is Google Cloud. An Azure implementation can be evaluated separately for an enterprise contract, with its own scope, timeline and validation. It is not a one-click option.

Dira is a set of TypeScript services behind strict OpenAPI 3.1 contracts, with every order change recorded as an event. Marketplaces, POS systems and infrastructure connect through adapters at the edge, so the core stays stable as your stack changes.

Request API documentation Platform overview

diraAPI reference/ Orders and stores

OpenAPI 3.1

ENDPOINTS

WEBHOOKS

order.state_changed
order.replayed
store.availability_changed

200 OK

1{2  "id": "DR-48213",3  "channel": {4    "id": "ubereats",5    "externalId": "ue-7c1e9a"6  },7  "storeId": "S-0142",8  "state": "IN_KITCHEN",9  "catalogVersion": "2026-11-02.3",10  "itemCount": 3,11  "items": [12    {13      "sku": "BRG-DBL",14      "quantity": 1,15      "modifiers": ["NO-ONION", "ADD-CHEESE"]16    }17  ],18  "pos": {19    "checkNumber": "2041",20    "adapter": "pos-gateway"21  },22  "totals": { "subtotal": 2840, "currency": "USD" },23  "eventCount": 724}

Illustrative example · sample payloads, not the published API reference

The stack, stated plainly.

These are the technologies Dira is built, tested and deployed on today.

Services

Node.js and TypeScript on NestJS

Typed service modules share contract types with the APIs they expose, so a schema change shows up at compile time.

Contracts

Strict OpenAPI 3.1

Interfaces are defined as OpenAPI 3.1 contracts and validated in CI before anything ships.

Data

PostgreSQL with logical schemas

Orders, catalog, stores and finance keep separate logical schemas inside one system of record.

Events

Event history and transactional outbox

A state change and its event commit in one transaction, then publish from the outbox.

Packaging

Docker

Every service ships as a container image, and the same image moves from CI to deployment.

Interfaces

React store app and enterprise consoles

The store tablet app is a progressive web app. Command, Catalog and Reconcile run as browser consoles.

New systems connect at the edge.

Adapters translate between an outside system and Dira's canonical model. A new marketplace or POS means a new adapter. Canonical orders, the catalog and every product built on them stay as they are.

Integration status by system

Delivery marketplace

Outside system

Marketplace adapters

Edge · owns the translation

Canonical core

Unchanged

SYSTEMS

Uber EatsIntegrated
DoorDashIn development
GrubhubIn development

THE ADAPTER OWNS

Webhook signature validation
Translation to canonical orders and back
Status and cancellation sync
Menu and availability publishing
Payout report intake

THE CORE NEVER SEES Marketplace payload formats, signing schemes and rate limits.

Every event is signed, keyed and replayable.

Orders move through Dira as events. Each one is verified on the way in, deduplicated, retried when a dependency fails and kept for replay.

Signature validation: Inbound webhooks are rejected unless their signature verifies against the channel's secret. Nothing unverified reaches the core.
Idempotency keys: Each event carries a key derived from its source. A webhook delivered twice, or a retry that already succeeded, is recognized and ignored.
Retries with backoff: Calls to a POS or marketplace that fail are retried on a backoff schedule set per operation.
Dead letter and exception queues: When retries run out, the event moves to a dead letter queue and an exception is opened in Command with the stage, reason and attempts.
Replay: Operators replay from Command or through the API once the cause is fixed. Replays reuse the original key, so the effect applies once.

simplified

1# Simplified marketplace webhook2POST /webhooks/ubereats3X-Signature: sha256=3b9f0c2e41d74Content-Type: application/json5 6{7  "event_type": "orders.notification",8  "event_id": "ue-evt-55a1",9  "resource_id": "ue-7c1e9a"10}

Illustrative payloads · field names simplified

Deployment

Runs on a Google Cloud reference deployment.

Dira's containerized services run on Google Cloud today. It is the environment the platform is built and tested on.

Edge

Marketplace webhooks
Store app
Enterprise consoles
Store POS systems

Cloud Run

Containerized Dira services · Docker images

API services
Adapter services
Event workers

Managed services

Pub/Sub
Event transport from the outbox
Cloud SQL
PostgreSQL · logical schemas · outbox
Cloud Storage
Payout reports and exports
Redis
Cache and short-lived state

Google Cloud reference deployment · simplified

Current

Google Cloud

Services run on Cloud Run, events move over Pub/Sub, data lives in Cloud SQL for PostgreSQL, files in Cloud Storage, and Redis handles caching.

By contract

Other environments

An Azure implementation can be evaluated separately for an enterprise contract, with its own scope, timeline and validation. It is not part of the current deployment and not a one-click option.

Tested before it ships. Visible once it runs.

Changes pass contract checks and failure testing before release. In production, operators and your engineers can see what the platform is doing and who changed what.

How changes ship

CI validation: Every change is built, type checked and validated against its OpenAPI contracts in continuous integration.
Automated contract testing: Adapters and services are tested against the contracts on both sides of each boundary, so a breaking change fails in CI rather than in a store.
Load and chaos testing: The platform is load tested and chaos tested, with adapters and dependencies failed on purpose to exercise retries, queues and replay.

Observability and access

Structured logs and traces: Services emit structured logs and traces keyed to order, store and event IDs, so one order can be followed across services.
Health checks: Services, adapters and store connections report health, and degraded states surface in Command.
Role-based access and audit history: Access is granted by role across products, and every change, replay and manual action is written to audit history.

Security questionnaires, access model reviews and data-handling questions are worked through directly with your security team during evaluation.

API documentation is shared with customers and evaluation teams.

Tell us about your systems and what you need to review. The Dira team will share the documentation and walk your architects through it.

Request API documentation

What evaluation teams review

OpenAPI 3.1 contracts for orders, catalog, stores and events
Canonical event definitions and webhook signing
Adapter boundaries for marketplaces, POS and infrastructure
The Google Cloud reference deployment

Questions from architects

Bring your architecture questions.

Walk through contracts, events, adapters and deployment with the Dira team.

Book a demo How the platform works