Relay Integration vs API Integration for Access Control Systems

INFINITE SYSTEMS INSIGHTS

When an access control system needs to communicate with an elevator, turnstile, visitor platform, BMS, HR database, parking system or another building application, the first engineering question is often not which product to buy. It is how the two systems should exchange information.

Two common approaches are relay or dry-contact integration and API or software integration. Both can be appropriate. The correct choice depends on the workflow, data required, system ownership, cybersecurity rules, available interfaces and what must happen when one system is unavailable.

What Is Relay or Dry-Contact Integration?

A relay interface uses an electrical contact to signal another system. In access control, a controller may close or open a contact after an authorized event. The receiving equipment detects that change and performs a predefined action.

For example, an access controller may validate a credential and energize a relay that releases a turnstile lane. The turnstile does not necessarily need to know the employee name, department or access profile. It only needs an approved release signal.

What Is API Integration?

An application programming interface, or API, allows approved software systems to exchange structured information and commands. Instead of reducing the interaction to an electrical on/off state, an API can expose defined software functions such as creating a user, updating a credential, querying an event, sending a destination request or retrieving an authorized status.

API capability varies widely. Some interfaces are read-only. Others allow commands. Some provide real-time events, while others require polling. Authentication methods, rate limits, supported objects, software versions and licensing can also differ. This is why an API should never be treated as a generic promise that two systems will automatically integrate.

Relay vs API: The Practical Difference

When Relay Integration Is Usually the Better Choice

A relay is often appropriate when the receiving system only needs a small number of well-defined signals and there is no benefit in exchanging additional software data.

Relay integration can also be attractive when the required action must remain independent of an application server or when equipment manufacturers expose only hardwired inputs and outputs. However, the project still needs clear documentation of contact type, voltage expectations, normal state, pulse duration, supervision, cable routing and fail-state behavior.

When API Integration Adds Real Value

API integration becomes more valuable when the workflow depends on information that a simple relay cannot express.

For Philippine office towers and mixed-use developments, this can matter when access control must coordinate with visitor management, tenant applications, elevator destination control, parking workflows, HR processes or a wider smart-building platform.

One-Way Signal vs Richer Two-Way Workflow

The biggest design difference is often the amount of context available to the receiving system.

Relay example: Access granted – close output 3 for one second. The receiving device reacts, but it may not know which cardholder caused the signal.

API example: An approved software request may include a user reference, authorized destination, event timestamp and transaction identifier, depending on the documented interface. The receiving platform can then apply its own logic and may return a status or result.

This distinction is especially important for turnstile and elevator integration, where a project may need more than a simple gate release. Some destination-control workflows require a supported software or gateway interface so the system can coordinate the passenger’s authorized destination or elevator assignment.

Failure Modes Must Be Designed Before Integration

A good integration specification describes what happens when components fail, not only what happens during normal operation.

For critical entrances, elevators and life-safety-related interfaces, the approved operating sequence should be coordinated with the relevant equipment provider, consultant and project authority. Software convenience must not replace required emergency behavior or manufacturer-approved safety functions.

Cybersecurity and Permissions Matter More with APIs

Physical relay wiring has its own security concerns, but API integration introduces additional software and network controls. The project team should define how systems authenticate, what the integration account is allowed to do, where credentials are stored, which network paths are permitted and how interface activity is logged.

These controls should be agreed with the building owner’s IT or cybersecurity team. An access control integrator should not assume that an API connection may be placed directly onto a corporate network without review.

Who Owns the Integration?

Many project delays happen because the technical interface is discussed, but responsibility is not. The scope should identify which party provides each component and who is responsible for testing the completed workflow.

1. Access control integrator: access controllers, permissions, access software, required outputs or documented API functions.
2. Third-party system provider: supported inputs, API endpoints, gateway, software licensing or receiving logic.
3. IT/network team: network addressing, firewall rules, DNS, certificates, approved server access and cybersecurity requirements.
4. Consultant or owner: final operating sequence, acceptance criteria, responsibility matrix and required records.
5. Commissioning team: end-to-end testing under normal, denied, fault and recovery conditions.

This coordination is especially important where access control connects to a Building Management System or an elevator access control system, because different contractors may own different portions of the interface.

What Should Be Tested During Commissioning?

Commissioning should prove the complete sequence, not just demonstrate that a contact changes state or that an API returns a successful response.

Procurement Questions Before You Commit

Before approving a relay- or API-based integration, ask the bidders to answer these questions in writing:

• Exactly what data, status or command must pass between the systems?
• Is the proposed interface officially available for the exact hardware and software versions?
• Is the integration read-only, command-capable or two-way?
• Are additional API, gateway, middleware or license fees required?
• Which system is the source of truth for user identity and access permissions?
• Who provides interface documentation and test credentials?
• What happens when either system or the network is offline?
• Who owns future changes if one platform is upgraded?
• What cybersecurity approvals are required before connection?
• What end-to-end acceptance tests must pass before turnover?

These questions help prevent a common procurement problem: buying two products that are individually capable but have no clearly defined, supported or commercially assigned integration path between them.

Can a Project Use Both Relay and API Integration?

Yes. A hybrid architecture is common and can be sensible. An API may synchronize identities, permissions or software events, while a relay handles a local equipment release or independent discrete signal. The design should use each interface for the function it performs best rather than forcing the whole project into one method.

Infinite Systems positions access control as part of a wider integrated building-security environment. For readers who want a platform-specific example of software integration, see our article on GuardPoint 10 API integration. The appropriate architecture remains project-specific and should be confirmed against actual interface documentation.

Frequently Asked Questions

Is API integration always better than relay integration?

No. An API is useful when the project needs richer software data or workflows. A relay can be simpler and more appropriate for a discrete equipment action. The best method depends on what information must cross the interface.

What is a dry contact in access control?

A dry contact is an electrically isolated relay contact that changes state without supplying the controlled circuit’s operating voltage. The exact wiring, ratings and receiving input requirements must be verified for the equipment being connected.

Can an API synchronize access-control users with another system?

Potentially, if the access-control platform and the other application expose compatible, authorized functions for the required user data and permissions. The supported objects, field mapping and ownership of the source record must be defined before implementation.

Can relay integration send a cardholder name or employee number?

Not through a basic single relay contact alone. A relay normally communicates a state or trigger. Richer identity data requires another supported communications method.

What happens if an API connection fails?

That depends on the system architecture. The design should define local controller behavior, retry logic, fault indication, transaction handling and recovery before commissioning. Critical access functions should not rely on assumed behavior.

Who should coordinate an access control API integration project?

The access-control integrator should coordinate closely with the third-party application provider, client IT team, consultant and building operator. Where elevators or other specialized equipment are involved, the corresponding equipment contractor should also be included.