Merge365 | Access Control & Device API Integration

Connect supported access control, biometric and security devices through the Merge365 API gateway for unified events, commands and integration workflows.

Integrate once. Connect supported physical systems.

Connect supported devices through a unified gateway for discovery, event normalization, governed commands and monitored webhook delivery. Compatibility depends on the connector, model and firmware.

Stable application contract.
Vendor-specific execution.

Merge365 separates business logic from device integration. Applications use canonical devices, people, events and commands; approved connectors adapt them to the capabilities of each validated system.

Every application integrates with every vendor.

• Vendor fields enter business code
• Hardware changes force application changes
• Errors are spread across separate integrations

Business logic uses one stable API boundary.

• Canonical device, person and event objects
• Capability-aware commands by connector profile
• One correlation and delivery history

How a request reaches a physical device.

The application calls the REST API. Merge365 authenticates, normalizes, checks policy and records the trace. The selected connector performs only the operations validated for that device profile.

Devices stay behind the approved local, VPN or edge network design.

A connector exposes only validated operations for its model and profile.

Source, tenant, schema, correlation, attempt and outcome remain linked.

Run a gateway operation.

Select an operation to inspect its request, control path, canonical output and delivery evidence.

Read one inventory and a truthful capability profile.

Merge365 identifies supported devices by tenant and site, then exposes only the operations validated for the active connector, model and firmware profile.

Validated integrations with explicit boundaries.

Connect supported devices and business systems through one API. Compatibility is confirmed for your connector, firmware and required operations.

From access event to business workflow.

Choose an operational state to see how identity context, policy, attendance and video references are coordinated.

1. 01Receive the person or device event
2. 02Resolve identity through the approved BioStar 2 integration
3. 03Evaluate the configured access action
4. 04Route attendance and evidence references

One verified identity can drive access, attendance and video context.

The camera or terminal event is correlated with BioStar 2 identity context. The approved project policy can then request access, send an attendance transaction to Time365 and attach an Eye365 evidence reference.

A gateway is valuable only when it is secured and observable.

The control plane applies the configured security and delivery rules around every supported connector operation.

Identity & access

Authenticate the calling system, isolate tenants and apply role-based permissions.

Device boundary

Keep device credentials protected and physical systems out of the public application surface.

Delivery handling

Record attempts and outcomes; apply the configured retry and reconciliation behavior where supported.

Operational trace

Link request, source, target, connector and delivery status with correlation context.

Place the gateway where the integration boundary belongs.

For suitable cloud-first and distributed projects.

For dedicated isolation and customer-controlled network requirements.

For local device networks, edge connectivity and approved cloud services.

Technical architecture in one document.

The updated brochure uses the same identity and explains the product boundary, canonical data model, connector lifecycle, API operations, current ecosystem, BioStar 2 workflow, security controls and deployment choices.

• Features and system architecture
• Architecture and workflow diagrams built for real project discussion
• Device connections and software workflows

Bring one device family and one business workflow.

We will define the connector, canonical objects, events, commands, network boundary and acceptance criteria for a focused proof of concept.