Today
The shift on one screen: what is due, what is late, and what is waiting on a decision.
- Today
Technical details
For your IT team: how Zagru One works
The part behind the buyer page: architecture, configuration, integration, identity and data separation. Every claim on this page was verified in the product code; what is not live yet is marked.
Request a technical callMeasured figures
Counted in the codebase, not made up for marketing.
- measured capabilities
- 177
- 147 complete, 20 partial, 10 not yet measured
- backend API endpoints
- 1,700+
- documented with an OpenAPI definition
- capability domains
- 17
- warehouse, transport, 3PL, billing, customs and more
- configurable definition kinds
- 35
- in Studio, with a governed lifecycle
Source: Zagru One capability coverage report and API definition, September 2026.
Why it is different
Four things to ask about in any demo.
Each one is a mechanism in the codebase, not a brochure adjective.
01Guided processes
One decision per step, enforced on the server.
Creating a site is not a twenty-field form. It is a sequence of single questions, each resolved server-side and validated in the command path.
One question at a time — Each step asks for what it needs and states the consequence — the site code appears on every document, label and report, and it cannot be changed later.
Steps are data, not screens — Order, visibility, requiredness, defaults and validation are rules resolved against platform, tenant, party, warehouse, process and role. One renderer serves every process.
The rule holds without the interface — The backend validates each step against the same effective experience, so a client calling the API directly cannot skip a requirement.
Unsaved work is defended — Leaving a form that has unsaved changes raises an explicit guard instead of silently discarding what was typed.
02Logistics Studio
Thirty-five kinds of definition, one governed lifecycle.
Configuration is a first-class object with a key, a version and an approval trail — not a settings page somebody edited last March.
A stable key, deliberately permanent — Artifacts are namespaced with dots, and the key cannot be changed once created, so references stay valid across versions.
Version one is a draft — Creating an artifact creates a draft version. Publishing is a separate and deliberate act.
Sandbox and tests before approval — A version is validated, moved to sandbox and tested before it can be submitted for approval.
Authored, not coded — Workflows, rule sets, screens, forms, documents, labels and mappings are composed from registry components. Configuration parameterises them; it never supplies executable code.
Definition lifecycle
- Draft
- Sandbox
- Test
- Approval
- Published
All 35 definition kinds
- Workflows
- Rules
- Screens
- Forms
- Mobile screens
- Dashboards
- Reports
- Documents
- Labels
- Notifications
- KPIs
- Integration mappings
- Permission sets
- Agents
- Task types
- Configuration sets
- Semantic models
- Custom fields
- Location types
- Inventory statuses
- Party role types
- Charge types
- Milestone types
- Exception types
- Packs
- Characteristics
- Transport modes
- Resource types
- Equipment types
- Shipment profiles
- Process experiences
- Integration bindings
- Document bindings
- Document bundles
- Compliance document types
03Site hub
Every site has one place that explains itself.
Not a settings tree. A hub of named actions in plain language, grouped by what they change — and honest about what is not built yet.
Grouped by intent — Structure, operations, and everything else: the shape of the site, the work booked against it, and the record of both.
Each action says what it does — Zones are described as receiving, storage, pick face and staging; a location is a bin, rack position, dock door or staging lane.
Unfinished work is labelled — Actions that are not available yet stay visible and marked, rather than hidden to make the product look finished.
Deactivation preserves history — Stopping a site stops new work while its structure and history stay readable.
04Tenancy and access
Isolation the database enforces, not the query.
Multi-tenancy that depends on every developer remembering a WHERE clause is not multi-tenancy. This one is enforced underneath the application.
Isolation the application cannot bypass — Every tenant table enforces isolation in the database itself, and the active tenant is bound to the transaction before the first query runs, so the rule holds for its whole duration.
No default tenant — Without a tenant context, tenant tables return no rows. There is no implicit fallback that sees everything.
Roles are scoped to sites — A role is granted for one warehouse, or — deliberately and visibly — for every warehouse in the tenant.
Verified at startup — The platform checks its own isolation rules when it boots, so a missing rule is a failure to start rather than a silent leak.
Architecture
The part procurement asks about.
Eight layers, each with one job, and a hard boundary between your business domain and the machinery underneath. That boundary is why your operation can change without the platform being rewritten.
Canonical model
Warehouse, transport, customs and 3PL share one definition of every record, so nothing has to be reconciled between them.
Execution core
The engine behind receiving, picking, loading and billing. One behaviour for every tenant, with no per-customer forks.
System of record
Balances, movements and decisions are stored once, as the authoritative version every other system can trust.
Configuration layer
What makes your operation different lives as metadata, rules and screens — versioned and published, never a branch of the source.
Process engine
Work that runs for hours or days is carried to completion, step by step, with each step recorded as it finishes.
Event backbone
Every meaningful change is published, so connected systems are told what happened instead of polling for it.
Access layer
One place where people, roles and machine credentials are defined for every area of the platform.
Analytics layer
Reporting runs on a path built for heavy questions, so the floor never waits on someone else's report.
Technology choices must not leak framework-specific concepts into the business domain.
Tenant isolation
No tenant can reach another tenant's data. The rule is enforced in the database itself, and the platform refuses to start if a table is missing it.
Audit trail
Who changed what and when, readable per site and across the tenant, including the comment left with a decision.
Identity
Single sign-on through your own corporate identity provider, roles granted per warehouse, and API credentials limited to the permissions they were given.
Telemetry
Every operation is traceable end to end, with health and metrics your operations team can watch and internal detail withheld from public responses.
Versioned configuration
Effective configuration is version-stamped, so the settings a decision ran under can be reconstructed afterwards.
Durable execution
Long-running work is durable: a restart resumes the process where it stopped instead of losing it.
Integration
A warehouse is never the only system in the building.
Six channels, each a real backend module rather than a consulting project. Their status is stated one by one below.
REST API
The same API the product's own interface calls. Nothing is reserved for the vendor.
Webhooks
Signed deliveries to your endpoint, so an external system is told rather than left to poll.
EDI
Reads X12 850, 856, 940, 943, 944, 945, 947, 214 and EDIFACT ORDERS, DESADV, RECADV, IFTSTA. Writes X12 850, 856, 945, 997 and EDIFACT DESADV. Transport: files and SFTP. No EDI-specific screen yet; field mapping in Studio.
Connectors
The file connector (CSV, SFTP) is live. ERP order, marketplace and parcel carrier connectors run against test environments; their live connections are in development.
Events
An event backbone carries domain events between modules and outward, with wildcard patterns for subscribers.
Scoped credentials
Machine access is a first-class object with its own scopes, audit account and revocation.
A credential is created in the product, named after the system that will hold it, tied to a service account that audits everything it does, and granted the narrowest set of scopes that still lets the integration work.
Industry behaviour without a fork.
A pack carries the rules, statuses, document types and validations an industry or a jurisdiction needs, installed as configuration rather than branched into the product.
Industry packs
- Pharma
- Food
- Fashion
- Automotive
- Chemicals
- Electronics
- 3PL
Country and regulatory packs
- European Union
- Türkiye
- United Kingdom
Screen map
Areas and the screens they open.
The application's navigation, section by section, with the screens each area opens. Areas modelled in the backend without a screen yet are marked.
01Operate
The shift as it stands right now.
Needs Attention
Exceptions gathered into one queue instead of scattered across modules.
- Needs Attention
02Execute
The physical work: goods in, goods out, and the stock in between.
Inbound
From the expected receipt to the putaway, including the quality hold.
- Expected receipts
- Receiving desk
- Quality control
Outbound
Orders become waves, waves become picks, and picks become a loaded trailer.
- Orders
- Waves
- Packing station
- Shipping desk
Inventory
Balances, handling units and lots, with every movement that changed them.
- Balances
- Handling units
- Lots
- Movements
- Adjustments
- Counts
Tasks
One queue for the work the system assigns to a person or a machine.
- Tasks
Processes
Running guided processes and the approvals that gate them.
- Instances
- Approvals
03Resources
The people, the yard, and the doors they work through.
Workforce
Who is on shift, what they are assigned, and how the work is spread.
- Workforce
Yard / Dock
Appointments, the dock board, and the trailers moving between them.
- Appointments
- Dock board
- Yard map
04Network
Everything that happens beyond the four walls.
Transport
Loads and shipments from tender to delivery, with the carriers behind them.
- Loads
- Shipments
- Tenders
- Tracking
- Carriers
3PL
Contracts and the billable events they turn into invoices.
- Contracts
- Billing
Control Tower
One view across sites, carriers and orders.
- Control Tower
Customs
In developmentDeclarations, bonded-warehouse stock ledger and guarantees. The connection for official filing (BİLGE, Türkiye) is in development.
05Insight
Questions answered from the same records the floor writes.
AI Operations
An AI assistant working on the same records with the user's permissions. Early access; off by default.
- AI Operations
Reports
Operational reporting over the analytical store.
- Reports
06Build
Where the platform is configured instead of customized.
Studio
Where workflows, rules, screens, forms, documents and labels are authored and published.
- Studio
07Administer
Tenancy, access, and the record of who changed what.
Settings
Tenancy, access, platform configuration and the audit log.
- Tenant profile
- Organizations
- Users
- Roles
- API credentials
- Configuration
- Feature flags
- Integrations
- Audit log
Integration and access screens
Keys, webhooks, configuration: from inside the product.
Captured from the running application. Records are sample demo data.
Settings
A key acts as one service account, limited to the permissions chosen, revocable on its own.
Settings
Signed deliveries to an https endpoint, with failing endpoints disabled after repeated errors.
Studio
A new rule set starts as draft version one and is published through sandbox, test and approval.
Settings
Legal entities, regions, sites and departments scope users, configuration and reporting.
Settings
A person, their account, and every role they hold with the scope it applies to.
Captured at 1440 × 900 · sample demo data
FAQ
What IT teams ask us.
How does single sign-on (SSO) work?
Through OpenID Connect. Each customer defines its own identity provider; users are created on first sign-in and roles are mapped. SAML connects through Keycloak federation.
How is it deployed and where does it run?
On containers and Kubernetes. In the cloud, with the option of an environment dedicated to you: its own Kubernetes namespace, database, message broker and storage. Installation on your own servers is available on request, as a project; there is no packaged offline installer today.
How is one customer's data kept apart from another's?
At database level, with row-level security policies. The active customer is bound at the start of every transaction; without that context, tables return no rows. If any table lacks its policy, the platform refuses to start.
How do we use the API?
It is the same API the product's own interface uses, documented with OpenAPI. Keys for machine access are created in the product, limited by scope and an IP allow list, and revocable on their own.
How do we get our data out?
Lists and reports can be exported, and all data can be read through the API. There is no one-click bulk export tool today; our team supports the transfer of your data when you leave.
Do the handhelds work offline?
Yes. The Android app keeps tasks and pending operations on the device and sends them in order when the connection returns. Zebra, Honeywell and Datalogic scanners are supported, as well as camera and Bluetooth scanners. The web application does not work offline.
Talk your questions through with our engineers.
Request a technical call