Logistics software Dubai: the declaration type is your schema

Logistics software Dubai projects usually budget for route optimisation and proof of delivery, then discover the actual schema problem: Dubai Customs does not have one import declaration and one export declaration. Its customer guide enumerates eleven importation types, ten export types, five transit types and three temporary admission types, before courier and cargo transfer declarations.

Which one applies is a function of where goods start, where they end, and what you intend to do with them — and the available zones are Local, free zone, customs warehouse, the GCC and the rest of the world. A movement from one Dubai free zone to another is its own declaration type. A single "pickup address" and "delivery address" pair cannot express any of this.

Why logistics software Dubai builds get the data model wrong

Most platforms model a shipment as two addresses and a status. In the UAE the endpoints carry a customs status, not just coordinates, and the declaration type is derived from the pair.

Reading the Dubai Customs customer guide, the importation family alone includes Import to Local from Rest of World, Import to Local from FZ, Import to Local from CW, Import to Local from GCC as a statistical import, Import for Re-Export to Local from each of those three origins, Import to CW from Rest of World, Import to CW from FZ, Import to CW from Local after temporary admission, and Import after Temporary Admission.

The export family mirrors it, and the transit family is where a platform usually breaks:

Procedure family	Types in the guide	What varies
Importation	11	Origin zone, and whether the intent is re-export
Export	10	Destination zone, re-export after import, temporary export
Transit	5	Including FZ transit in, out, and between Dubai-based free zones
Temporary admission	3	Origin: Rest of World, FZ or CW

The design consequence is specific. A location in your system needs a customs zone type as a first-class attribute, and a movement needs an intent — is this landing in the local market, passing through, or being warehoused for onward sale? Derive the declaration type from those rather than letting an operations user pick from a dropdown of thirty options, because that dropdown is where the errors come from and the errors are expensive.

Re-export means the intent has to be recorded before the goods arrive

This is the part that surprises teams porting a platform from a single-market country. "Import for Re-Export" is a distinct declaration made at the point of import, and the matching "Re Export to ROW (after import for re-export)" references it later. Goods in a free zone remain under customs control, with duty suspended rather than waived.

So the commercial decision — is this stock for the UAE market or for onward shipment? — has to exist in your data at inbound, not at outbound. A platform that records intent only when a customer order arrives has already filed the wrong declaration. If you are also selling into the local market, the free zone versus mainland distinction compounds it, because it changes who you can sell to as well as what you declare.

Proof of export is channel-specific, so your evidence model is too

Teams build one "proof of delivery" concept and attach a photo and a signature. Customs wants something else, and what it wants depends on the transport mode. For refund of a deposit or release of a guarantee, the guide lists documents of proof of export as:

• Sea: exit or entry certificate, copy of the export declaration or manifest, and copy of the bill of lading.
• Air: exit or entry certificate, copy of the export declaration, and copy of the airway bill.
• Land: exit or entry certificate, and copy of the export declaration or manifest.

Three different document sets against one business event. If your shipment record has a single nullable "pod_document" column, you will be reconstructing these from email threads when a deposit refund is queried. Model the evidence as a typed set keyed by mode, and make the required set a function of the declaration type.

How you actually integrate

The guide names three submission channels: the Dubai Trade portal, Business to Government (B2G), and Customs Bureau Services. B2G is the one that matters for a platform — the guide describes it as the option for "clients having high volumes and frequent transactions". Bureau Services is for non-commercial customers such as individuals, government entities and educational institutes, so it is not your path.

Dubai Trade is also the portal hosting services for DP World, DMCC and Jebel Ali Free Zone Authority, which is why a logistics platform ends up dealing with one portal and several authorities. Plan the integration as B2G with Dubai Trade as the fallback for exceptions, and expect client code registration to be a prerequisite rather than a detail.

Addressing: Makani has no official public API

Dubai's addressing system is not street-number based, and we have written separately about why a conventional address field is the wrong shape for a Dubai delivery app. For a logistics build, one point is worth adding, because it changes an architecture decision.

Makani is a ten-digit geo-address identifying a building entrance, assigned by Dubai Municipality's GIS department, with a plate at the entrance of buildings across the emirate. The app is published by Dubai Municipality, and the GeoDubai portal run by the municipality's GIS Center offers Makani plate requests and geospatial data access requests.

What we could not find is an official public developer API for resolving a Makani number to coordinates. GeoDubai lists data access requests rather than a self-serve API, and the geocoding APIs available for Makani are commercial third-party products built on municipal and Dubai Land Department datasets rather than endorsed government endpoints. Treat that as the current state and verify with the GIS Center before you design around it.

Practically: store the Makani number as authoritative reference data supplied by the customer, keep coordinates alongside it, and do not make your routing depend on resolving one to the other through an integration you have not confirmed exists. Two further cautions — the municipality's own app listing describes the system as adopted across several emirates while currently dedicated to Dubai, and the digit structure is described inconsistently across secondary guides, some calling it a metre-grid coordinate pair and others an area-plus-building scheme. We could not reach an official source to settle it, so do not write code that parses the number into parts.

The autonomous corridor: what to design for

Driverless logistics is closer than it was when this was a 2030 slide. The RTA began commercial autonomous taxi operations on 30 March 2026 in Umm Suqeim and Jumeirah, with a first phase of 100 vehicles — Apollo Go through its own app with Dubai Taxi Company, WeRide through Uber, and Tawasul Transport managing the fleet.

The Dubai Autonomous Zone announced at the RTA's self-driving congress in September 2025 is the part aimed at goods. Khaled Al Awadhi, RTA's director of transportation systems, described a zone covering an area stretching 15 kilometres around Creek Station on the Metro Green Line in Al Jaddaf, extending toward Dubai Creek Harbour and Dubai Festival City, with seven autonomous modes including driverless logistics vehicles and autonomous street sweepers, targeted to be fully operational by mid-2027.

Be careful with the figures circulating about this zone: reporting of the same announcement gives both a 15-kilometre corridor and a separate geometry of 20 kilometres of roads, 10 kilometres of waterways and 3.8 kilometres for delivery robots across 12 square kilometres. Those do not reconcile, and we would not put either in a plan without confirming with the RTA directly.

None of this is a present requirement for a logistics platform. What it argues for is two design choices you would want anyway: treat the vehicle as a typed resource with capabilities rather than assuming a human driver, and model proof of delivery as something a non-human agent can satisfy. A platform that hard-codes a driver identity into every status transition is the one that needs rework when a robot completes the leg.

Where to start

We have not built a UAE logistics platform, and this post rests on public sources rather than on our own delivery. Taking that into account, the sequence we would follow:

1. Model zones and intent before routes. Customs zone on every location, movement intent on every shipment, declaration type derived. Everything else is reversible; this is not.
2. Confirm your B2G eligibility and client code early, because it gates the integration and is an administrative dependency rather than an engineering one.
3. Ask Dubai Municipality's GIS Center directly about Makani data access before choosing between official data, a commercial API, or customer-supplied reference data.
4. Keep the declaration type out of the user interface wherever you can derive it. Thirty-odd options is a data quality problem waiting to happen.

The pattern here is the one that shows up across UAE builds: the regulatory surface shapes the data model, and it is cheaper to discover that in week one than in month six. If you are scoping something like this, we work with companies building in Dubai, and this is the kind of custom software problem we take on.