How to Build a Custom Genetec Security Center Plugin Using the Genetec SDK

Two different things people mean by "Genetec SDK"

Genetec ships two distinct SDK surfaces under the Security Center umbrella, and confusing them is the most common early misstep:

The Security Center SDK (Genetec.Sdk) is a client library for building standalone applications that connect to Security Center over the network — logging in as an SDK user, querying entities, subscribing to events, pulling live and archived video. This is what you'd use to build an external service or bridge that talks to Security Center.
The Plugin Framework is what most people mean by "a Genetec plugin" — an in-process extension that installs as a Role on the Genetec Server and, optionally, ships a matching extension that Security Desk and Config Tool load directly. This is the closer analogue to a Milestone MIP SDK plugin, and it's what this guide covers.

Plugin architecture: role, agent, and client extension

A Genetec plugin is typically organized as three coordinated pieces, all sharing a common plugin GUID so Security Center can associate them at runtime:

The Plugin Role — a background service entity that runs on the Genetec Server, configured and monitored from Config Tool exactly like Genetec's own built-in roles (Archiver, Access Manager, and so on). This is where persistent logic lives: talking to a third-party system, running scheduled jobs, reacting to Security Center events.
Agents — units of work the Plugin Role owns and supervises. A plugin can register one or more agents that each handle a specific responsibility (an event listener, a polling worker, a device bridge), and Genetec Server manages their lifecycle alongside the role itself.
Client extensions — separate assemblies that Config Tool and Security Desk load to give operators and administrators UI for the plugin: property pages for configuring the role, custom entity browser nodes, and task or workspace panels inside Security Desk.

This split matters for how you design a plugin: server-side logic in the role/agents keeps running whether or not any operator has Security Desk open, while the client extension is purely presentational and only matters when a user is actively looking at it.

Custom entity types

Security Center's entire object model is built from entities — cameras, doors, cardholders, areas, alarms, and roles are all entities with a type, a GUID, and a position in the system tree. A plugin can introduce its own custom entity types that live alongside Genetec's built-in ones: a custom device type representing a third-party sensor, a configuration entity holding plugin-specific settings, or a logical grouping entity that shows up in Config Tool's entity browser and can be referenced from macros, schedules, and reports just like any native entity.

This is what makes Genetec plugins feel native rather than bolted-on: once a custom entity type is registered, it participates in Security Center's existing permission model, audit trail, and entity browser search — you don't rebuild any of that plumbing yourself.

Illustrative plugin structure

The exact base classes vary by SDK version, but the shape of a plugin solution is consistent across releases — a role project, an agent, and a Security Desk extension coordinating through the shared plugin GUID:

C# — plugin role (server-side)

using Genetec.Sdk.Plugin;

namespace Xplug.GenetecPlugin
{
    // Registered in Config Tool as a Plugin role; supervises one
    // or more agents and exposes configuration to Config Tool.
    public class XplugPluginRole : Plugin
    {
        public override void OnLoad()
        {
            base.OnLoad();
            RegisterAgent(new XplugEventAgent(this));
        }

        public override void OnUnload()
        {
            // Release connections, stop timers, flush queued work.
            base.OnUnload();
        }
    }
}

C# — agent (background worker)

namespace Xplug.GenetecPlugin
{
    // Owned and supervised by the role; handles one responsibility,
    // e.g. listening for a specific Security Center event class.
    public class XplugEventAgent
    {
        private readonly XplugPluginRole _role;

        public XplugEventAgent(XplugPluginRole role)
        {
            _role = role;
        }

        public void OnEntityEvent(Guid entityId, string eventType)
        {
            // Dispatch to a third-party system, raise a custom
            // alarm, write an audit entry — the plugin's actual work.
        }
    }
}

C# — Security Desk extension (client-side)

namespace Xplug.GenetecPlugin.SecurityDesk
{
    // Loaded by Security Desk; contributes a task or workspace
    // panel bound back to the plugin role's configuration/state.
    public class XplugSecurityDeskExtension
    {
        public void Initialize()
        {
            // Register a custom task, entity browser node, or
            // property page scoped to the plugin's entity types.
        }
    }
}

The role and agent classes are the source of truth for behavior; the Security Desk extension is a thin, UI-only layer reading and writing state through the role rather than duplicating logic client-side.

Deploying a Genetec plugin

Build and package the role, agent, and client extension assemblies together — Genetec's plugin tooling packages these into an installer the Genetec Server and Security Desk workstations can consume.
Install on the Genetec Server first, then add the plugin as a Role from Config Tool (System → Roles → Add an entity → Plugin), pointing it at the appropriate database and assigning it to a server.
Deploy the client extension to every Security Desk and Config Tool workstation that needs the plugin's UI — typically via the same installer used for the server component, run on each client machine or pushed through existing software distribution tooling.
Verify entity registration — confirm the plugin's custom entity types appear in Config Tool's entity browser and that the role reports a healthy state before rolling out to operators.
Test failover behavior if the Genetec Server environment is configured for role failover — a plugin role should recover its agents cleanly when Genetec Server relocates the role to a standby server.

Licensing considerations

Genetec plugins built for commercial distribution run through the Development Acceleration Program (DAP), which is how SDK access, certification and the plugin's licensing are handled. DAP membership is open — technology partners, integrators and end users can apply — and provides the SDK documentation, installer and a Security Center development licence; a separate, paid SDK assistance plan buys access to Genetec's SDK technical team, and certification is included in some of those plans.

When a plugin is ready for production you contact Genetec for its part number and production certificate, and the end customer's Security Center licence has to include a certificate for the plugin before it can be installed. That makes it a procurement step on the customer's side rather than a silent install, and it is worth saying out loud in a sales conversation rather than discovering it during one. Building this in from the start avoids a re-architecture later when a customer wants a properly licensed, certified version instead of an internal proof of concept. We go through the whole picture in licensing and distributing a commercial VMS plugin.

One naming note, since the acronyms are easy to mix up: GTAP is the Genetec Technical Assistance Portal — the support site — not a partner programme. The programmes are the Technology Partner Program and, for SDK work, DAP.

Where projects usually need a specialist

The mechanics above describe the shape of a Genetec plugin; the hard parts of a real deployment are elsewhere — role failover behavior, keeping agent state consistent across thousands of entities, designing custom entity types that hold up under Security Center's permission and audit model, and certification through DAP. This is the work behind every custom Milestone XProtect plugin development and Genetec Security Center engagement we run at Xplug.in — architecture, certification, and the long-term version tracking that keeps a plugin running through years of Security Center upgrades.

Working with Xplug.in

Send us the capability you need inside Security Center

A feasibility answer first, not a proposal. Describe the capability, or send the third-party system’s API documentation. You get back whether it belongs in a plugin role, a Security Desk extension, the Web SDK or the ISG, and what we’d flag before budget is committed.
An entity and event model designed against Security Center’s grain. Which of your concepts become custom entity types, how they inherit the permission model and audit trail, and what an operator sees in Security Desk when something happens.
The plugin built for role failover and scale — agent state that recovers cleanly when the role relocates to a standby server, and behaviour that holds up across thousands of entities rather than a demo system’s dozen.
Source and IP transferred to you at delivery, taken through certification rather than left working-but-unverified, plus version tracking as Security Center releases move underneath it.

Get a feasibility check Schedule a technical demo

Xplug.in is a Genetec Technology Partner, working within the Development Acceleration Program, with 140+ plugins shipped since 2014 — plugin roles, Security Desk extensions, custom entity types and third-party system bridges. Write to contact@xplug.in or use the form; a straight technical answer costs you one email.

Questions we get asked

What is the difference between the Security Center SDK and the Plugin Framework?

The Security Center SDK is a client library for building a standalone application that connects to Security Center over the network — logging in as an SDK user, querying entities, subscribing to events, pulling video. The Plugin Framework is what most people mean by a Genetec plugin: an extension that installs as a Role on the Genetec Server and can ship matching extensions that Security Desk and Config Tool load directly. Choosing the wrong one is the most common early misstep.

Why bother with custom entity types?

Because they are what makes a plugin feel native rather than bolted on. Once a custom entity type is registered, your objects live in the system tree alongside cameras and doors, participate in Security Center’s permission model, audit trail and entity browser search, and can be referenced from macros, schedules and reports. None of that plumbing has to be rebuilt.

Does a customer need a licence change to load our plugin?

Plan for it. Genetec’s Development Acceleration Program documentation describes a specific part number being activated on the end user’s Security Center licence in order for a plugin to load, which makes it a procurement step for the customer rather than a silent install. Settle the specifics with Genetec for your product before a salesperson tells a prospect the plugin just installs.

What does role failover mean for plugin design?

That your agents can be stopped on one server and started on another at any time. Any state held only in memory is lost at that moment, so persistent work belongs in the role’s database rather than in process memory, and agents need to be written to resume rather than to assume they are starting fresh. Testing this deliberately is the difference between a plugin that survives a failover and one that quietly stops working after it.