Questions we get asked

It depends on where GateRev runs, and we answer per deployment. GateRev Cloud: automatic authorisation needs a working connection between the site and the cloud. If that path is down, the barrier does not rise automatically — the site switches to its manual gate procedure; a manual lift made through GateRev is recorded as an exception, while a lift made at the barrier itself is outside GateRev's record. GateRev Onsite: the application runs inside your infrastructure, so normal local operation can continue during an Internet outage as long as the local GateRev server, network, ANPR integration and barrier controller are available; that does not mean every external integration stays available. In every model the barrier's local safety functions do not depend on GateRev. The intended behaviour for each failure combination is written down as a table.

No. GateRev is available as TechRevati-managed Cloud and as Customer-Hosted deployment — GateRev Private Cloud in infrastructure your organisation controls, or GateRev Onsite on your own servers — for organisations that require the application and operational data to remain inside customer-controlled infrastructure. The workflow is the same in all three.

It depends on the deployment model, so there is no single answer for every customer. GateRev Cloud: TechRevati-managed infrastructure in the EU. Customer-Hosted (Private Cloud or Onsite): customer-controlled infrastructure, according to the deployment design agreed for your site.

No. Leaving the site must not depend on GateRev being reachable, so we require the exit lane to be set up at installation either to open without a command (fail-open) or to be opened by the guard by hand — for daily operations and for fire evacuation alike. That wiring belongs to the installation; GateRev cannot enforce it. While GateRev is reachable, exit follows the full rules: the automatic exit barrier rises only on an exit-only lane and only for a visit cleared to leave; every other case goes to the guard.

Through a signed generic webhook, delivered and in use: endpoint, secret, event list, retries with jitter and a dead-letter queue you can query. A connector for your specific ERP is built during implementation, to your system. One rule holds either way: an unreachable ERP never stops the gate — inbound checks are advisory, never a block.

No. GateRev covers the operational layer between an expected truck and its completed visit at the site — gate, yard queue, docks and weighing. Your TMS or ERP stays the system of record for transport and business processes; GateRev sends it signed webhook events, and a carrier's TMS can book and update visits through the carrier API.

No. The system only ever sends one command, on one dry contact: open. The barrier interface in the code has no close() at all — closing, the safety loops and the photocells stay with the controller your installer already fitted. That is a deliberate boundary, not a missing feature.

No. GateRev determines whether site access is authorised and can send an OPEN request to the site's barrier control system. The local barrier/control installation remains responsible for the physical movement and its safety functions, including obstacle detection, photocells, safety loops, closing logic, emergency functions and local interlocks. GateRev is not intended to bypass or replace those local safety functions. Who carries legal responsibility depends on the actual installation, the roles and the contracts. Our part is to state which channel may be fail-open and which never: a close channel that energises on network loss is a crushing risk, not a safety improvement, and GateRev must not be wired to one.

Every table in the schema has a retention rule, and a test in CI fails on any new table without one — the rule is executed by a purge job, not written in a policy document. Plate snapshots are framed on the plate: no face recognition, by design. The impact assessment is generated from the live schema and the retention registry rather than kept as static text. In GateRev Cloud your organisation is the controller for gate data and we act as processor under the agreement; in a customer-hosted deployment the roles follow the deployment and the contract documentation.

It depends on your site — the number of gates, docks and integrations — and you get a plan with dates after the site walk-through. The driver side needs no installation at all: a driver registers from a phone browser. Your site set-up — docks, slot templates, roles and required documents — is entered once during implementation.

The driver does, once, on a public form with no account. The approver decides, the guard works from a console at the gate, and nothing is retyped from one system into another. Rejections carry a reason, and every decision leaves a record.

No. The standard driver flow works in a mobile browser: no app installation, no carrier software licence and no separate driver account. The driver chooses one of seven languages at the start, and the pass and notifications follow that choice.

One of seven, chosen at the start: English, Slovenian, German, Serbian, Croatian, Polish, Romanian (staff consoles use the first five). The choice is stored on the visit, so the pass and notifications follow it afterwards; the gate kiosk has its own language choice on screen. A screen that mixes two languages is treated as a bug here, and a test fails the build if any language is missing a phrase.

Yes — the audit screen lists recent sessions with the user, the role, the IP address and the client, filterable by person and by day. It is visible only to the auditor role, scoped to your organisation. The session record is deleted seven days after the session expires, which the screen states on the page rather than in a manual.