In short
Ayonix raises a Genetec Security Center custom event on a face match, so the existing event-to-action configuration decides what happens next — an alarm, a recording, a door command or a notification. Identity evidence reaches the operator inside Security Center rather than in a separate console.
This page is written from Genetec's published administrator documentation, which is linked at the foot of the page. Genetec keeps its full SDK reference behind a Developer account obtained through the Development Acceleration Program, so this page describes the mechanisms that are publicly documented and is explicit about the limits of what can be stated without that access.
That constraint is why the compatibility matrix below separates implemented from validated. Marking something validated that has not been tested against your version would be a guess dressed as a commitment.
The cost of analytics that live outside Security Center
A Genetec estate exists because one platform correlates video, access and alarms. Analytics that sit outside it give that up for the one event type that most needs the correlation.
Separate analytics consoles mean operators watch two systems and trust neither fully.
A match becomes a Security Center custom event. The operator works in the platform they already know, with the alarm model they already trust.
Security events from different sources cannot be correlated or reported together.
Once a face match is a Security Center event, it participates in the same event-to-action, alarm and reporting machinery as every other event in the system.
Verifying an incident means manually finding the camera and the time in another system.
The custom event is associated with the Security Center entity for that camera, so the video is one click from the alarm rather than a search.
Live video and identity evidence are presented separately, so context is lost.
The event carries its evidence and its camera association, which is what lets an operator see the match and the scene together.
Configuring custom events and their actions is fiddly and poorly documented internally.
The integration package sets out exactly which custom events are raised, what each means, and the event-to-action configuration each expects.
Integrations break at upgrade and nobody discovers it until an incident.
Health monitoring surfaces connection state, and the compatibility matrix on this page states honestly what has been validated rather than what is assumed.
How it works
From a match to a Security Center action
The design principle is that Genetec decides what happens. Ayonix raises a well-defined event; the customer's existing event-to-action configuration owns the consequence.
-
Ayonix recognises
Recognition runs on Ayonix infrastructure inside the customer network against authorised camera video, producing a match with its evidence.
Fails when: The analytics host cannot reach the camera stream because the network segmentation was designed without it.
-
Custom event is raised
A Security Center custom event, defined in advance for this deployment, is raised and associated with the relevant camera entity.
Fails when: The custom event is not defined in Security Center first, so there is nothing for the platform to raise.
-
Event-to-action decides
The customer’s event-to-action configuration maps the custom event to a consequence: an alarm, a recording, a notification or a door command.
Fails when: A consequential action is wired directly to the event, removing the human review the deployment relies on.
-
Operator reviews and the record is kept
The operator sees the alarm with its camera and evidence, decides, and the decision is recorded in Security Center’s own audit trail.
Fails when: The evidence is not attached to the event, so the operator is asked to trust a name rather than judge a comparison.
Architecture
Ayonix raises the event; Security Center decides the consequence
This division is deliberate. The customer already maintains an event-to-action configuration, and an integration that bypasses it creates a second, undocumented policy surface.
Video and entities
Security Center managed-
Cameras
Security Center entities
-
Archiver
Holds the recorded video
-
Authorised stream access
To the analytics host
Ayonix recognition
Customer infrastructure-
Detection and quality gating
Discards unusable captures
-
Matching engine
Gallery or watchlist
-
Event client
.NET SDK or Web-based SDK
Security Center
Genetec platform-
Custom event
Defined in advance for this deployment
-
Event-to-action
Customer-owned policy
-
Alarm, operator, audit
Platform’s own model
Recognition runs on Ayonix infrastructure. Security Center owns the consequence of an event through its own event-to-action configuration, which is where the customer’s security policy already lives.
Compatibility
Four states, and deliberately no fifth
Implemented means the Ayonix integration does it. Validated means it has been tested end to end against a named Security Center version. Integration project means it is achievable and has not been built. Not supported means it is not on offer.
| Capability | Genetec mechanism | Status |
|---|---|---|
| Raise a custom event on a match | Security Center custom events | Supported: Implemented |
| Associate the event with a camera entity | Entity mapping | Supported: Implemented |
| Trigger an alarm | Event-to-action mapped to an alarm | Supported: Implemented — customer-configured |
| Drive a downstream action | Event-to-action: recording, notification, door command | Supported: Implemented — review recommended before consequential actions |
| Present identity evidence to the operator | Event payload and associated camera | Supported: Implemented |
| Cross-platform (non-Windows) integration host | Web-based SDK role, exposing SDK methods as web services | Partial: Available by integration project |
| Health and connection monitoring | Ayonix service monitoring surfaced to operators | Supported: Implemented |
| Audit of operator decisions | Security Center audit trail | Supported: Implemented — platform native |
| Validation against a specific Security Center version | End-to-end test against the customer’s installed release | Depends on configuration: Per deployment — confirmed in the integration plan |
| Genetec certification or marketplace listing | Not applicable | Not supported: Not claimed — verify any such status with Genetec directly |
Nothing in this table should be read as a statement by Genetec. Where a certification or marketplace status is required by a procurement, confirm it with Genetec rather than inferring it from the existence of an integration.
Why "validated" is per deployment
Genetec’s full SDK documentation requires a Developer account through the Development Acceleration Program, and capability differs between Security Center releases. Marking a capability validated against a version it has not been tested on would be a guess presented as a commitment. Validation is therefore stated against the customer’s actual installed version, in writing, as part of the integration plan — which is slower to say and more useful to rely on.
Operator experience
What the alarm actually shows
The same requirement as any other watchlist alert: enough evidence that the operator is judging a comparison rather than trusting an assertion.
The captured image
What the camera actually saw at the moment of the match, not a stock enrolment photo. This is what an operator compares.
The candidate entry
The enrolled image, presented alongside the capture so the comparison is visual rather than numerical.
Score and threshold together
A similarity score is uninterpretable alone. Presented with the threshold in force, it tells the operator how marginal the match was.
Camera and timestamp
The Security Center entity and the time, which is what makes the video one click away rather than a search.
The reason for the alert
Which list, and what the operational meaning of that list is. An alarm whose meaning is undocumented is an alarm nobody can act on correctly.
A place to record the decision
Confirmed, dismissed or escalated, with the operator identity — recorded in Security Center’s own audit trail.
The Security Center Web-based SDK role exposes Security Center SDK methods and objects as web services to support cross-platform development
- Source type
- Third-party vendor documentation
- Verified
- 2026-09-11 · Jan Mocary, Chief Technology Officer
What this does not establish
Quoted from the Genetec administrator guide. Full SDK documentation requires a Genetec Developer account obtained through the Development Acceleration Program, so version-specific capability is stated as unvalidated where it has not been tested.
Integration work with Network Optix, Milestone and Genetec video management platforms
- Source type
- Ayonix first-party statement
- Verified
- 2026-09-11 · Jan Mocary, Chief Technology Officer
What this does not establish
Integration capability only. This is NOT a claim of certification, marketplace listing, technology-partner status or joint validation with any of the three vendors. No such status has been verified, and none is asserted anywhere on this site.
Primary sources for this page: Genetec Security Center Administrator Guide — About Web-based SDK, and the Security Center administrator documentation for custom events and event-to-action. Read on 11 September 2026. Genetec documentation is the authority on Genetec behaviour.
Genetec integration prerequisites
Agree each of these before the integration work begins. Several depend on Genetec programme access that takes time to arrange, so they belong at the start of a project rather than the middle.
-
Record the Security Center version in use
Available interfaces and capability differ between releases. Record the exact version and edition before scoping, because it changes what can be committed to.
-
Confirm Development Acceleration Program access
Genetec states that full SDK documentation requires a Genetec Developer account, obtained through the Development Acceleration Program, which also supplies a development licence. Arrange it early; it is not instantaneous.
-
Decide between the .NET SDK and the Web-based SDK
Genetec documents the Web-based SDK role as exposing Security Center SDK methods and objects as web services to support cross-platform development. Where the analytics host is not Windows, that is the documented route.
-
Define every custom event before configuration
Which events exist, what each means operationally, and what evidence each carries. A custom event whose meaning is not written down becomes an alarm nobody can interpret at 03:00.
-
Map cameras to Security Center entities
Establish the mapping between Ayonix camera identifiers and Security Center entities, once, with a convention that survives the estate growing.
-
Configure event-to-action deliberately
Decide which events raise alarms, which only record, and explicitly which consequential actions require a person first. The default should be that they all do.
-
Agree time synchronisation
The event timestamp locates the video. Drift between the analytics host and the archiver makes evidence hard to find and easy to challenge.
-
Plan health monitoring and alerting
How the control room learns the analytics connection has dropped. A silent failure leaves a site believing it is covered.
-
Define retention on both sides
Security Center retains its events and video; the Ayonix deployment retains captures, templates and its own audit. Both need a stated period, and they need not be the same.
-
Test the whole path before go-live
Induce a known match, confirm the custom event arrives, confirm the configured action fires, confirm the operator can open the right video, and confirm the acknowledgement is recorded.
Frequently asked questions
How does Ayonix integrate with Genetec Security Center?
By raising Security Center custom events on a face match. Custom events are a documented Security Center concept, defined in the platform and then raised by an integration; the customer’s event-to-action configuration then decides the consequence — an alarm, a recording, a notification or a door command. The design principle is that Genetec owns what happens, and Ayonix supplies a well-defined event with its evidence.
What is the Genetec Web-based SDK?
Genetec’s administrator documentation describes the Web-based SDK role as exposing "the Security Center SDK methods and objects as web services to support cross-platform development". In practice it is the documented route for an integration that does not run on Windows. Whether it is the right route for a particular deployment depends on the version in use and what the integration needs to do.
Do we need to join the Genetec Development Acceleration Program?
For integration development, yes in practice. Genetec states that full SDK documentation requires a Genetec Developer account, obtained through the Development Acceleration Program, which also provides an installer and a development licence for setting up a development environment. This is worth starting early in a project, because access is not immediate and the integration cannot be built without it.
Is the Ayonix Genetec integration certified by Genetec?
No such status is claimed. This page describes the use of documented Security Center mechanisms, which is a statement about how software works rather than about a commercial or certification relationship. The compatibility matrix on this page deliberately separates what is implemented from what has been validated and what would be an integration project — and has no "certified" state at all, because none has been verified.
Which Security Center versions are supported?
This page does not publish a version matrix. Capability differs between releases, and publishing a matrix that has not been tested against each one would be precisely the unsupported compatibility claim this site refuses to make elsewhere. For a specific deployment, record the installed version and the supported configuration is confirmed in writing as part of the integration plan.
Can a face match trigger a door to unlock in Security Center?
Technically yes, through event-to-action. Whether it should is a governance decision that deserves explicit thought: a face match is evidence rather than an established identity, and wiring a consequential action directly to it removes the human review the deployment probably relies on. Where an automatic door action is appropriate — a low-consequence door with an enrolled population — it should be a deliberate choice with the threshold recorded.
What evidence does the operator see?
The captured image, the matched entry, the similarity score, the threshold in force and the associated camera, presented with the Security Center alarm. An operator asked to act on a name alone is being asked to trust the system rather than to judge a comparison, and that is how automation bias becomes an operational property rather than a theoretical risk.
Where does recognition run?
On Ayonix infrastructure inside the customer’s network — a server or an edge appliance — not inside Security Center. Security Center provides authorised access to camera video and receives the resulting events. Face images and templates are therefore governed by the Ayonix deployment’s retention configuration, which should be specified alongside the VMS integration rather than assumed to follow it.
Related
Where to go next
Milestone XProtect
The MIP SDK analytics event protocol, with the field that silently defeats most first attempts.
Network Optix
Metadata SDK plugin, so matches are searchable on the timeline.
Watchlist monitoring
Governing alert volume before it reaches the control room.
Access control
Where a match reaches a door rather than an operator.
Integration overview
Every mechanism with its status stated honestly.
Privacy and governance
Why consequential actions should not be wired directly to an event.
Next step
Plan a Genetec integration
Tell us the Security Center version, whether you have Development Acceleration Program access, the camera count in scope and what should happen on a match. The plan comes back with the custom events to define, the event-to-action configuration, and what will be validated before go-live.