How to build a hardware integration without having the physical device

The invisible traffic jam: the hardware dependency

The typical integration plan looks like this: buy the terminal (2–4 weeks of importing), set up a test network, connect, and only then start coding. In that plan, your dev team is blocked by a package on its way. Customs arrives, the deadline doesn't move, and the feature competes against the courier's clock.

The problem is one of order, not capability: you start with the hardware when you should start with the data contract — what information your SaaS needs and in what format. Everything else can be built before the device even exists.

Phase 1: design the data contract (no hardware, no API)

Before touching anything external, define with your team what your product needs:

• What fields does a punch require in your system? (person, verification method, date/time, source terminal).
• Which flows react to events? (notifications, headcount, schedule-based alerts).
• Which reports does the end user consume? (attendance by range, hours worked, access audit).

With that you can already write the internal data structures, the use cases and even the tests for your logic — everything that lives on the other side of the boundary with the hardware.

Phase 2: virtual sandbox — your development terminal

The API Connect sandbox creates virtual terminals with a simulated serial number that generate real events: check-in and check-out punches, accesses granted and denied, sync pulses. Your backend consumes them exactly like those of a physical device.

The full development flow works from day one:

curl -X POST https://TU-DOMINIO-API/auth/login \
  -H "Content-Type: application/json" \
  -d '{"username": "tu_usuario", "password": "tu_password"}'

curl -X GET "https://TU-DOMINIO-API/report/TU-SERIAL-VIRTUAL?from=2026-09-01&to=2026-09-14&page=1&per_page=500" \
  -H "Authorization: Bearer {token}"

Every punch you simulate in the sandbox browser ends up in your history and is queryable via API, with the same fields you'll receive in production. Your business logic can already be written, tested and corrected against real data.

Phase 3: simulate the edge cases (the ones that break the feature)

The real value of the sandbox isn't testing the "happy path" — it's repeating, at zero cost, the odd scenarios that with physical hardware require someone to go on site and trigger them:

• Expired terminal: test what your logic does when a device passes its expiration date.
• Multi-terminal: with the full trial you can simulate several sites and verify that your SaaS correctly separates events by serial.
• Users and credentials: register someone via API and see how the terminal reacts, without touching the device's menu.
• Reconnection and deduplication: terminals re-send events on reconnect; validate that your reconciliation doesn't duplicate records.

Phase 4: the swap to production

The day the customer's real device arrives, the transition is the most boring part of the project — which is exactly what it should be: you register the physical serial number in your account and your software keeps calling the same URLs. There is no rewrite phase because sandbox and production share the same API.

Being honest: what you CANNOT validate without hardware

The sandbox unblocks development, but there are things only the physical device proves:

• Real biometric read quality (worn fingerprint, face in low light).
• Real latency of the site's network and behavior on unstable internet.
• Installation, power and placement of the device.

That's why the right flow is: sandbox to build and validate the logic → acceptance test with the real device on site to close. With this methodology, that final test is no longer a mystery: you know exactly what to verify because everything else already works.

Frequently asked questions