A gate camera that reads container codes perfectly and cannot deliver them anywhere useful has solved nothing. Getting
reads into container terminal software reliably is the part of a gate automation project that decides whether it
changes daily operations or becomes a screen nobody watches, and
how the recognition layer plugs in
decides which. This article covers the four integration patterns, the fields that have to travel, and how to design
exception handling before you need it.

Key Takeaways

• Four patterns cover almost every deployment: interface calls, message queues, file exchange and direct database
  writes. They differ sharply in resilience and in how quietly they fail.
• The payload is small but specific. Identity, event context, confidence and an image reference are the four groups,
  and confidence is the one most often left out.
• Exception design is a business decision, not a software setting. Decide what happens on a mismatch before go live
  rather than discovering the default during peak season.
• Monitor for absence as well as for errors. The most damaging integration failures are the ones that stop sending
  data without producing a single error message.

The Four Integration Patterns and How They Fail

A direct interface call is the cleanest option. The recognition layer posts the read, the platform validates it
against its own rules and returns an acknowledgement, which the gate can act on immediately. Bad data is rejected at
the boundary rather than absorbed, and failures are loud.

A
message broker
decouples the two systems in time. Reads are published to a queue and consumed when the platform is ready, so a brief
platform outage causes a backlog rather than a stopped gate. The cost is another component to run, monitor and reason
about.

File exchange remains widespread because it is easy to agree between two organisations. A batch of reads is written to
a location and collected on a schedule. It is auditable and slow, and its failure mode is silence, since nothing
announces that a file was never written.

Direct database writes bypass the platform entirely and should be treated as a last resort. They skip validation,
break on version upgrades without warning, and commonly void vendor support. If a supplier proposes this as the
primary route, that is information about the supplier.

Choosing between the first two is mostly about what a gate outage costs. If a stopped gate means a queue on the public
road within ten minutes, the queue based pattern earns its extra complexity. If a short pause is absorbable, the
simpler call is better.

Whatever you choose, insist that your own team can call and inspect the interface without vendor involvement. An
interface you cannot test yourself is one you cannot diagnose during a night shift, and gates rarely break at a
convenient hour.

The Fields That Have to Travel

Identity comes first. The owner code and serial number as defined by
ISO 6346, with the
check digit validated at the point of recognition rather than downstream. Sending an unvalidated code means the
platform has to guess whether a misread or a genuinely unusual box has arrived.

The size and type code belongs in the same group. It tells the platform what physical object it is dealing with, which
drives slot suitability, stacking rules and billing. A read that carries identity without dimensions forces a lookup
that may itself be out of date.

Event context is the second group: lane, direction, timestamp and camera identifier. Without these the platform can
record an arrival but cannot reconstruct the transaction later, which makes both dispute resolution and gate
performance analysis impossible.

Confidence is the third and the most frequently omitted. Every recognition result carries a score, and passing it
through is what allows automated exception routing. A read at ninety nine percent and a read at seventy one percent
should not follow the same path through your process.

Image reference is the fourth. The platform does not need the frames, but it needs a pointer to them, so that a claim
raised six months later can be settled by retrieving what the camera actually saw. Storing images inside the
operational database is a common and avoidable mistake.

Agree these four groups explicitly in a short document before any code is written. That hour of specification prevents
the most common rework in gate projects, which is discovering after go live that a field everyone assumed was
travelling never was.

Designing Exception Handling Before You Need It

The single most useful preparation for a gate integration is to write down what should happen when things do not
match. Terminals that skip this get whatever the platform default happens to be, and discover it during their first
busy morning.

Start with the unmatched read. A container arrives whose code does not correspond to any expected booking. Options are
to hold the truck, to admit and flag for clerk review, or to create a record and reconcile later. Each is defensible
and they have very different queue consequences.

Then the low confidence read. Below your chosen threshold, does the transaction route to a clerk screen for
confirmation, or does it proceed with a flag. Setting this threshold too high creates manual work you were trying to
remove. Setting it too low lets errors into the record.

Then the physical impossibility. A box that is already recorded as inside the terminal arrives again, or one recorded
as departed is presented for departure twice. These are usually data problems rather than fraud, and they need a
defined resolution route rather than an error message.

Then the unreadable container. Damaged panels, overpainted codes and obscured markings exist in every terminal, and
the process needs a dignified fallback where the clerk keys the number and the system records that it was a manual
entry rather than a read.

Finally, decide who owns each exception queue and how quickly it must be cleared. An exception queue without an owner
fills up and becomes evidence that the system does not work, when the real problem was that nobody was assigned to it.
Our piece on
why manual gates stop scaling
covers the process side.

Monitoring, Testing and Proving It Works

Monitor for absence, not just for errors. The most damaging failure in a gate integration is a feed that stops sending
without complaining, which can run for a day before anyone notices that arrivals have gone quiet. An alert on expected
volume not arriving catches it in minutes.

Reconcile daily at first. Count reads produced by the recognition layer and records created in the platform, and
investigate any difference. A small persistent gap almost always indicates a rejected field or a rule nobody
documented, and it is far easier to chase on day three than on day ninety.

Test the failure paths deliberately before go live. Take the platform offline for five minutes during a quiet period
and watch what the gate does. If the answer is unknown, you have not finished the integration, whatever the happy path
demonstration showed.

Keep the parallel period long enough to be meaningful. Two to four weeks of running the automated read alongside the
clerk entry, with every disagreement logged and categorised, gives you both an accuracy figure and a list of the local
quirks that no vendor could have predicted.

Publish the numbers internally. Gate teams accept automation faster when they can see the disagreement rate falling
and when the exceptions they raise visibly result in changes. Hidden metrics produce suspicion, which shows up as
unexplained manual overrides.

Once stable, the integration becomes invisible, which is the goal. The client describes what the live flow looks like
end to end in its post on
reading a container in realtime, which is a useful companion to this article.

Conclusion

Getting reads into container terminal software is less about technology than about agreement. Choose the pattern that
matches what a gate outage costs you, specify the four field groups explicitly, decide the exception rules before go
live, and monitor for silence rather than for errors. Terminals that do those four things find the integration
disappears into the background within a month.
Talk to Docker Vision about
mapping your own gate fields.

Frequently Asked Questions

Which integration pattern is best for gate OCR?

A direct interface call is the default because the platform validates data at the boundary and failures are visible.
Use a message queue instead where a short platform outage must never stop trucks moving through the gate.

What fields does the platform actually need?

Owner code and serial number validated to ISO 6346, size and type code, lane, direction, timestamp, camera identifier,
a recognition confidence score and a pointer to the stored image. The confidence score enables automated exception
routing.

Why does the confidence score matter so much?

Because without it every read looks equally certain. Passing the score through lets you treat high confidence reads as
authoritative and route low confidence ones to a clerk, which is what keeps automation from quietly introducing
errors.

Should container images be stored inside the platform?

No. Keep the frames in the recognition layer and pass a reference instead. That keeps the operational database lean
while still letting a disputed claim months later be settled by retrieving exactly what the camera captured.

What happens when a read does not match any booking?

That is a business rule your team defines. Common patterns are to hold the truck, to admit and flag for clerk review,
or to create a record and reconcile later. Each has very different queue consequences at a busy gate.

How do we handle containers that cannot be read at all?

Provide a clean manual fallback where the clerk keys the number and the system records the entry as manual rather than
recognised. Damaged panels and overpainted codes exist everywhere and the process needs a dignified path for them.

How long should parallel running last?

Two to four weeks, covering every shift, both weather extremes and at least one peak period. Log and categorise every
disagreement, because that list is where the local quirks of your own gate become visible for the first time.

What is the most common integration failure?

A feed that stops sending without raising an error. Monitor for expected volume not arriving rather than only for
error messages, because silent failures can run for a full day before anyone notices arrivals have gone quiet.

Can this run while the platform is being replaced?

Yes, if the recognition layer is independent. The gate keeps reading and results are repointed at the new system,
which removes the most stressful part of a migration. See our
edge computing explainer
for where processing sits.