GuardPoint 10 API Integration for Flexible Access Control in the Philippines

GuardPoint 10 API integrating mobile access, turnstiles and elevators in a Philippine office building

Modern buildings often operate several independent platforms for employee records, visitor registration, physical access, CCTV, elevators, parking and workplace services.

When these systems do not exchange approved information, administrators may have to create and update the same user manually in multiple databases. This can cause duplicate records, delayed permission changes and access rights remaining active after a user transfers or leaves.

GuardPoint 10, developed by Sensor Access Technology, provides an access-control platform with integration capabilities intended to connect access functions with supported third-party systems and applications.

An API does not make every system automatically compatible. Successful integration still requires confirmed interfaces, software licensing, cybersecurity controls, field testing and clear responsibility among the manufacturers, developers, consultants and contractors involved.

What Is GuardPoint 10?

GuardPoint 10 is an access-control and security-management platform from Sensor Access Technology.

Depending on the selected modules, equipment and project design, the platform may support:

  • Cardholder management
  • Door access control
  • Access schedules
  • Areas and occupancy status
  • Alarm management
  • Event monitoring
  • Video integration
  • Biometric readers
  • Mobile credentials
  • Visitor workflows
  • Rule-based actions
  • Multi-site administration
  • Supported third-party integrations

Available functions depend on the exact GuardPoint 10 release, licensed modules, controllers, readers and connected systems.

A feature shown in a manufacturer brochure or another project should not be assumed to be included automatically in every proposal.

What Is an Access-Control API?

An application programming interface, or API, provides a defined method for authorized software systems to exchange data or requests.

In an access-control project, an API may allow an approved third-party application to perform functions such as:

  • Creating or updating a user
  • Assigning an identifier
  • Requesting approved access permissions
  • Suspending or revoking a credential
  • Retrieving selected access events
  • Checking authorization status
  • Initiating a supported workflow
  • Receiving relevant system information

The exact data and commands available depend on the API documentation, permissions and software version.

An API should not be treated as unrestricted access to the security database. Each integration should be limited to the information and functions required for its approved purpose.

Why API Integration Can Improve Access Administration

An integration-ready architecture can reduce repetitive administration when responsibilities are clearly defined.

Consider an employee leaving an organization. Without integration, several teams may need to disable the person separately in:

  • Human resources
  • Door access control
  • Turnstiles
  • Elevator permissions
  • Parking
  • Mobile credentials
  • Visitor sponsorship
  • Workplace applications

If one system is overlooked, outdated permissions may remain active.

With a properly designed workflow, an approved status change in the authoritative source system can initiate corresponding actions in other connected systems.

The integration does not remove administrative responsibility. It changes how approved information is communicated.

Integration Does Not Mean One Database Controls Everything

A common integration mistake is allowing multiple systems to modify the same information without deciding which one is authoritative.

A project should identify the source of truth for each data type.

Information Possible authoritative system
Employee identity and employment status HR or identity-management platform
Door and zone permissions GuardPoint 10 or approved security workflow
Visitor registration Visitor-management platform
Elevator destination permissions Access control, subject to the approved elevator interface
Vehicle authorization Parking or vehicle access system
Video recordings Video-management system
Workspace reservations Workplace application
Emergency operation Approved local life-safety controls

The actual assignment depends on the project.

If two systems can independently overwrite the same permissions, records may become inconsistent. Ownership, update direction and conflict handling should be documented before development begins.

One-Way and Two-Way Integration

Not every integration needs to exchange information in both directions.

One-Way Integration

A one-way interface sends approved information from one system to another.

Examples may include:

  • HR sends employee status to access control.
  • Access control sends selected events to a reporting platform.
  • A visitor platform sends an approved temporary visitor record.
  • GuardPoint 10 sends an authorization result to a supported interface.

One-way integration can be easier to govern because one system remains responsible for the original record.

Two-Way Integration

A two-way interface allows both systems to exchange or update approved information.

This may be appropriate where the workflow requires status confirmation, error reporting or synchronized changes.

However, it introduces additional questions:

  • Which system wins when records conflict?
  • How are duplicate requests handled?
  • What happens if one platform is unavailable?
  • How are failed updates retried?
  • Who investigates synchronization errors?
  • Which system maintains the final audit trail?

Two-way integration should be used only where the operational requirement justifies the added complexity.

GuardPoint 10 and Smart Workplace Applications

Sensor Access Technology identifies smart workplace platforms among the systems that may be integrated with GuardPoint 10.

A workplace application may provide an employee- or tenant-facing experience for functions such as:

  • Mobile building access
  • Visitor invitations
  • Tenant services
  • Workplace information
  • Room or desk services
  • Building announcements
  • Other supported occupant functions

GuardPoint 10 can remain responsible for the applicable access-control decisions while the workplace platform provides the user interface.

A simplified conceptual flow is:

Employee or workplace application → approved integration → GuardPoint 10 → door, turnstile or supported elevator interface

The actual architecture must be confirmed for the selected products and software versions.

The workplace application should not bypass the access-control platform or directly operate field devices unless that function is specifically supported and approved.

GuardPoint 10 and Smart Spaces

Sensor Access Technology has published information identifying Smart Spaces as one of its supported integrations.

In a suitable project, Smart Spaces may provide an occupant-facing digital experience while GuardPoint 10 manages the corresponding access permissions.

However, the following items must still be confirmed:

  • Supported GuardPoint 10 version
  • Supported Smart Spaces version
  • Available integration functions
  • Required software licenses
  • Mobile credential architecture
  • User synchronization
  • Access-permission ownership
  • Hosting and network requirements
  • Error and retry handling
  • Data retention
  • Technical-support responsibilities

A previous integration does not guarantee compatibility with every future release or project configuration.

Visitor Management Integration

A visitor management system may be integrated with GuardPoint 10 to support temporary access workflows.

A typical process may include:

  1. A host pre-registers a visitor.
  2. The visitor record is reviewed or approved.
  3. The system creates a temporary access request.
  4. GuardPoint 10 receives the authorized visitor information.
  5. A supported card, QR code or mobile credential is issued.
  6. The visitor receives access only to the approved doors, turnstiles or floors.
  7. The permission expires according to the configured schedule.
  8. Relevant access events remain available for authorized review.

The integration should define what happens when:

  • The visit is cancelled
  • The host changes
  • The visitor arrives early
  • The visit extends beyond the original schedule
  • A credential is reissued
  • The access-control platform is offline
  • The visitor-management platform is unavailable
  • A temporary credential fails
  • A visitor requires an escort

Visitor access should expire automatically where supported, but the expiration process must be tested.

Turnstile Integration

GuardPoint 10 can form part of a turnstile access-control solution.

A typical transaction may involve:

  1. A person presents a supported credential.
  2. The reader sends the credential information to the access-control system.
  3. GuardPoint 10 checks the applicable permissions.
  4. The system confirms the permitted direction and schedule.
  5. The authorized turnstile lane receives an opening command.
  6. Passage sensors monitor the user’s movement.
  7. The transaction is recorded.

The design should also address:

  • Anti-passback
  • Tailgating
  • Lane direction
  • Accessible passage
  • Multiple users approaching together
  • Invalid or expired credentials
  • Visitor QR codes
  • Mobile credentials
  • Turnstile safety inputs
  • Fire alarm operation
  • Power failure
  • Network interruption
  • Local guard override

An API is not normally responsible for the turnstile’s real-time safety functions. Those functions should remain within the approved local turnstile and access-control architecture.

Mobile Credential Integration

GuardPoint 10 may support mobile credential workflows through compatible Sensor Access or third-party technology.

Depending on the selected system, credentials may use:

  • NFC
  • Bluetooth Low Energy
  • A supported mobile application
  • QR codes
  • Another approved digital credential method

Before procurement, confirm:

  • Supported phones and operating systems
  • Reader compatibility
  • Credential licensing
  • Enrollment method
  • Revocation behavior
  • Offline operation
  • Phone-replacement procedure
  • Data processed by the application
  • Mobile-device security
  • Fallback access
  • Administrator permissions

Mobile credentials should not be described as universally replacing cards. A phased deployment may continue supporting cards for visitors, contractors or users without compatible phones.

Biometric Reader Integration

GuardPoint 10 can be used with supported biometric readers and platforms.

Biometrics may provide additional identity assurance at selected access points, but compatibility must be confirmed for the exact reader, controller, software and integration method.

The design should address:

  • Fingerprint or facial enrollment
  • Template storage
  • Matching location
  • Liveness controls
  • False acceptance and rejection
  • Network interruption
  • User fallback
  • Privacy notices
  • Retention
  • Device synchronization
  • Enrollment administration
  • Worker or visitor offboarding

Biometric integration does not automatically make every door more secure. It should be used where the risk and operational requirement justify the additional processing.

CCTV and Video Integration

Sensor Access Technology publishes information about GuardPoint 10 video integration with selected video-management platforms.

Depending on the supported integration, operators may be able to:

  • Associate a camera with an access-controlled door
  • Display video for an alarm
  • Review footage related to an access event
  • Compare a cardholder photograph with the person shown on video
  • View selected live or recorded video
  • Support alarm verification

Available functions vary by video platform, licensing and software version.

Video integration should not be described as proving conclusively who used a credential. Camera position, image quality, time synchronization and retention must support the intended investigation.

A project should confirm:

  • Supported VMS version
  • Required licenses
  • Camera and door mapping
  • Time synchronization
  • User permissions
  • Video retention
  • Network bandwidth
  • Failover behavior
  • Cybersecurity controls
  • Responsibility for technical support

Alarm and Rule-Based Automation

Sensor Access Technology describes configurable cause-and-effect actions within the GuardPoint 10 platform.

Depending on the available modules and approved configuration, a rule may respond to an event by:

  • Generating an alarm
  • Sending an approved notification
  • Changing a supported door state
  • Initiating another configured action
  • Escalating an event for operator review

Automation should be designed around a documented operational requirement.

Before enabling a rule, define:

  • The initiating condition
  • Required verification
  • The intended action
  • Time schedules
  • User permissions
  • Failure behavior
  • Manual override
  • Event logging
  • Reset procedure
  • Cybersecurity implications
  • Testing responsibility

Life-safety functions should not depend solely on general API logic or cloud connectivity. Fire alarm and emergency responses require their own approved local interfaces.

Elevator Access-Control Integration

GuardPoint 10 may be integrated with supported elevator access-control systems.

Two common approaches are:

Conventional Floor Restriction

A valid credential enables only the authorized elevator floors. Integration may use approved relay interfaces, controllers or manufacturer-supported connections.

Destination-Control Integration

In a destination-control system, an authorized passenger may receive an assigned elevator before entering the lift car.

The process may involve:

  1. The user presents a credential at a turnstile or destination terminal.
  2. GuardPoint 10 validates the user’s access permissions.
  3. An approved gateway or software interface exchanges the required information.
  4. The elevator destination-control system assigns an elevator.
  5. The assignment is displayed using the elevator system’s approved interface.

The elevator system remains responsible for dispatch and elevator operation.

Mitsubishi SmartLift and DOAS Integration

Sensor Access Technology has published case-study information describing GuardPoint 10 integration with Mitsubishi’s destination-control technology.

For supported projects, an interface such as the ELSGW gateway may form part of the engineered communication path between GuardPoint 10 and Mitsubishi SmartLift or DOAS.

However, compatibility should be confirmed for:

  • Exact Mitsubishi system
  • GuardPoint 10 release
  • Gateway version
  • Elevator software
  • Turnstile configuration
  • Display arrangement
  • Network architecture
  • Required licenses
  • Door and floor permissions
  • Front and rear elevator doors
  • Visitor workflows
  • Emergency modes
  • Testing responsibilities

The access-control contractor should coordinate with Mitsubishi-authorized elevator personnel.

Infinite Systems can coordinate the access-control and turnstile portions, but elevator operation, approvals and commissioning remain subject to the elevator manufacturer’s requirements.

Philippine GuardPoint 10 Project Experience

Sensor Access Technology’s published case studies identify Infinite Systems Technology Corporation as the installation partner for the GuardPoint 10 deployment at Innoland One Montage in Cebu.

The manufacturer describes a project involving:

  • GuardPoint 10
  • Sensor Access controllers
  • Security turnstiles
  • Mitsubishi destination-control integration
  • Assigned elevator information displayed at the turnstile area

This provides a relevant Philippine example of GuardPoint 10 being used as part of a coordinated access and elevator solution.

It should not be assumed that every project will use the same equipment, interfaces or configuration. Each building must be assessed independently.

HR and Identity-System Integration

An HR or identity-management platform may serve as the approved source of employee status.

A suitable integration may help automate actions related to:

  • New employees
  • Department transfers
  • Site assignments
  • Role changes
  • Contract expiration
  • Leave or suspension
  • Offboarding
  • Rehiring

The workflow should not simply copy every HR field into the security system.

Only the information required for access control should be exchanged. Sensitive employment information that is unrelated to physical access should remain outside the integration.

The project should also define whether HR can directly assign security permissions or merely request a predefined access profile for security approval.

Parking and Vehicle Access Integration

GuardPoint 10 may form part of an integrated parking barrier and vehicle access solution where compatible interfaces are available.

Possible credential methods include:

  • RFID
  • ANPR
  • Mobile credentials
  • QR codes
  • Staff cards
  • Visitor records

Vehicle access and pedestrian access should remain separately governed where required.

A valid vehicle credential should not automatically grant unrestricted pedestrian access to the building.

Building Management System Integration

A building management system may receive selected access-control events or status information where a supported interface and operational requirement exist.

Potential uses include:

  • Occupancy-related information
  • Door or controller status
  • Alarm monitoring
  • Approved energy or comfort workflows
  • Central facilities dashboards

The BMS should not automatically receive unrestricted personal access records.

The project should define whether the BMS receives aggregated status, anonymous occupancy information or identifiable events. Privacy, cybersecurity and operational necessity should guide that decision.

APIs and Building Automation

An authorized access event may be used as part of a wider building workflow.

Possible examples include:

  • Activating an approved workplace arrival workflow
  • Requesting an elevator destination
  • Associating a visitor with temporary floor access
  • Updating a monitored occupancy area
  • Sending an approved security alert
  • Triggering a supported application event

This does not mean access control should directly command every building system.

Lighting, HVAC, elevators, fire alarm and other systems should retain their own approved controllers and safety logic. Integration should exchange only the information or requests defined in the project architecture.

Cybersecurity Requirements

An API increases connectivity and therefore expands the system’s cybersecurity considerations.

The integration design should address:

  • API authentication
  • Authorization scopes
  • Service accounts
  • Credential and secret storage
  • Encryption in transit
  • Network segmentation
  • Firewall rules
  • Rate limits where supported
  • Input validation
  • Audit logging
  • Certificate management
  • Software updates
  • Vulnerability management
  • Remote-support controls
  • Backup and restoration
  • Incident response
  • Account revocation

API credentials should not be embedded openly in scripts, shared documents or unprotected configuration files.

Each integration should use the minimum permissions required.

Privacy and Data Protection

Access-control integrations may process names, identifiers, photographs, access permissions, visitor records, access events and biometric information.

The responsible organization should determine:

  • The specific and lawful purpose
  • Which system is the source of each record
  • Which organizations control or process the data
  • What information is exchanged
  • Who may access or export it
  • How long it is retained
  • How errors are corrected
  • What happens during offboarding
  • Whether data crosses jurisdictions
  • How incidents are handled
  • Whether a privacy impact assessment is appropriate or required
  • How third-party developers and support personnel are controlled

Integration should follow data-minimization principles. The fact that an API can expose a field does not mean every connected application should receive it.

Compliance with the Data Privacy Act of 2012 depends on the complete processing arrangement—not only on encryption or access passwords.

Integration Failure and Offline Operation

Every interface should have a defined response when one component becomes unavailable.

The project should confirm:

  • Whether door controllers continue operating locally
  • What happens when the API is offline
  • Whether requests are queued or rejected
  • How failed transactions are reported
  • Whether duplicate updates are prevented
  • How systems resynchronize
  • Which platform maintains the authoritative record
  • How revocations are handled during an outage
  • How administrators perform urgent changes
  • Which logs are available for troubleshooting

A failed workplace application should not automatically stop already authorized users from entering if the approved local access-control architecture is intended to continue operating.

Conversely, the system should not accept unverified access requests merely because an integration is unavailable.

API Versioning and Change Management

Integrations can stop working when software versions, authentication methods or data structures change.

A change-management plan should cover:

  • GuardPoint 10 upgrades
  • Third-party software updates
  • API version changes
  • Operating-system updates
  • Certificate expiration
  • Database changes
  • New cybersecurity requirements
  • Elevator or gateway upgrades
  • Mobile application updates
  • End-of-support dates

Updates should be tested in a controlled environment where practical before deployment to the live security system.

The commercial agreement should identify who maintains custom code after the original project is completed.

Testing and Commissioning Checklist

The integration should be tested with normal, failure and recovery scenarios.

Recommended tests include:

  • User creation
  • Duplicate user handling
  • Access-profile assignment
  • Department transfer
  • Credential issuance
  • Credential revocation
  • Contract expiration
  • Visitor creation and cancellation
  • Temporary credential expiration
  • Valid and denied access
  • Turnstile authorization
  • Elevator floor permissions
  • Destination assignment
  • Video-event association
  • Alarm and notification rules
  • Network interruption
  • API authentication failure
  • Invalid data
  • Duplicate request
  • Server or application failure
  • Local controller operation
  • Recovery and resynchronization
  • Audit logging
  • Administrator permissions
  • Time synchronization
  • Data retention
  • Emergency operation
  • Backup and restoration

Test results, unresolved exceptions and corrective actions should be documented before handover.

Procurement Checklist

Before specifying a GuardPoint 10 integration, ask:

  • What business or security problem must the integration solve?
  • Which GuardPoint 10 version and modules are proposed?
  • Is the required API function officially supported?
  • Which third-party product and version will be connected?
  • Which system is authoritative for each data field?
  • Is the interface one-way or two-way?
  • What licenses are required?
  • Who will develop and maintain the connector?
  • What documentation and developer support are available?
  • How will API accounts and secrets be protected?
  • What happens during network or software failure?
  • How will errors and duplicate transactions be handled?
  • Which personal information will be exchanged?
  • What retention and privacy requirements apply?
  • How will software updates be tested?
  • Which party supports each system after handover?
  • What test cases and acceptance criteria are required?
  • Are elevator or other manufacturer approvals needed?
  • What recurring software or support costs apply?
  • How will the integration be retired or replaced in the future?

Integration scope should be confirmed before equipment procurement, not after the hardware is installed.

Frequently Asked Questions

Does GuardPoint 10 provide API integration?

Yes. Sensor Access Technology identifies API integration as a GuardPoint 10 capability. The available functions and requirements must be confirmed for the exact software version and licensed modules.

Can GuardPoint 10 integrate with every third-party system?

No. Compatibility depends on the third-party product, available interfaces, software versions, licensing and engineering scope.

Can GuardPoint 10 connect with Smart Spaces?

Sensor Access Technology identifies Smart Spaces among its integrations and has published a case study involving GuardPoint 10 and Smart Spaces. Compatibility should still be confirmed for the proposed versions and project.

Can GuardPoint 10 integrate with visitor management?

Yes, where a supported visitor-management module or interface is available. Temporary credential issuance, expiration and failure handling should be tested.

Can GuardPoint 10 work with turnstiles?

Yes. GuardPoint 10 can form part of a turnstile access-control solution using compatible readers, controllers and turnstile interfaces.

Can GuardPoint 10 integrate with Mitsubishi destination-control elevators?

Sensor Access Technology has published GuardPoint 10 projects involving Mitsubishi destination-control integration. The exact elevator, gateway, software and project requirements must be verified.

Can GuardPoint 10 integrate with CCTV?

Sensor Access Technology lists integrations with selected video-management platforms. Supported functions and versions vary and should be confirmed before procurement.

Can an HR system automatically revoke access?

A properly designed integration may initiate access revocation when an approved employment-status change occurs. The workflow, authorization and outage behavior must be defined.

Does API integration eliminate manual administration?

No. It may reduce repetitive data entry, but organizations still need approval workflows, exception handling, audits and data-quality controls.

Will API integration continue working after software upgrades?

Not automatically. Updates can affect authentication, data fields and supported functions. Integrations require testing and change management.

Is GuardPoint 10 a cloud-only system?

Deployment architecture depends on the selected GuardPoint 10 solution, modules and project design. Cloud-only operation should not be assumed without confirmation.

Does an API make the access-control system less secure?

Not necessarily, but it creates additional interfaces that must be protected. Strong authentication, limited permissions, network controls and audit logging are essential.

Does Infinite Systems provide GuardPoint 10 integration in the Philippines?

Yes. Infinite Systems can assess, design, supply, install, integrate and maintain suitable GuardPoint 10 solutions for doors, turnstiles, visitors, mobile credentials, CCTV and supported elevator systems in the Philippines.


Planning a GuardPoint 10 Integration?

Infinite Systems can assess your existing access-control environment, doors, turnstiles, elevators, visitor workflows, mobile credentials, CCTV, HR systems and third-party applications.

We can help define the integration architecture, data ownership, API scope, licensing, cybersecurity controls, test cases, manufacturer coordination and ongoing technical support.

Request a GuardPoint 10 Integration Assessment


Explore Related Access-Control Solutions