Zenitel APIs and SDKs

Select the Zenitel interface for the communication workflow. Check product support for call state, media, notifications and any physical control.

Sources and scopeSource record 25 August 2026

Technical source record: 25 August 2026. Check the linked documentation for current product requirements.

Official Zenitel wiki pages reviewed on 25 August 2026; package availability, current support status, exact SDK methods, licences, ICX/AlphaCom compatibility, recorder versions, and deployment behaviour require vendor confirmation.

Verification and testing

Overview#

Vendor APIs / Device and edge video / Zenitel

Zenitel’s public wiki documents several integration generations. The principal server integration described for AlphaCom/ICX is VS SDK, with vendor .NET libraries and sample applications. A separate Recorder 2.0 API is documented as a licensed recording surface. Their age, product scope, licence and support status differ; don't combine them into one generic Zenitel API.

Documented interface map#

Product and licence boundaries#

The VS SDK page states compatibility with ICX 500 and ICX Core and explains that state retrieval is licensed, with differences between ICX and AlphaCom licence handling. The package number on that page is a minimum identified relationship, not a statement that every later package is compatible with every system release.

Before implementation, pin:

• ICX/AlphaCom server product and exact release;
• VS SDK package and any service provider component;
• required state/control/recording licence;
• .NET runtime, process architecture and supported operating system;
• endpoint types, intercom stations and redundancy topology;
• protocol/service connection mode and certificate/account support;
• vendor support status for Recorder 2.0 or any older DLL.

State, events, and control#

Intercom APIs can initiate or terminate calls, route audio, change station state, activate outputs or interact with emergency workflows depending on the licensed surface. Model every operation as one of observation, communication control, configuration or physical actuation, and authorise them independently.

For server state feeds:

• establish initial snapshot before applying deltas;
• preserve system/node identity and event time;
• detect reconnect, failover and stale state;
• bound callbacks and marshal work off SDK threads according to the official contract;
• reconcile active calls and outputs after connection loss;
• avoid recording sensitive call content or identifiers in diagnostic logs.

Never assume that a library return proves audible delivery, human acknowledgement, relay operation or emergency response.

Native library safety#

Verify package publisher and licence, pin assembly versions, and isolate the integration service from operator clients where practical. Follow documented threading and object disposal rules. Protect credentials in the platform secret store, use a distinct service identity, and don't grant general system control to a recorder only integration.

If the product supports a secure transport or certificate configuration, use the current hardening guide. Don't infer TLS behaviour from a .NET wrapper or expose a legacy raw service outside a segmented management conduit.

Lifecycle and compatibility#

technology_status: mixed reflects current ICX/AlphaCom integration alongside older Recorder 2.0 and .NET Framework era material. Verify current supported replacements directly with Zenitel before starting a new project, and retain the exact wiki revision/package documentation used.

Primary sources#

• VS SDK for AlphaCom, official product, package and licence overview.
• Zenitel SDK category, official SDK catalogue.
• Stentofon .NET libraries, documented managed library runtime context.
• Recorder 2.0 API, separate licensed legacy recording surface.
• Zenitel licences, official licence reference route.

Related pages#

• Intercom and emergency communications
• Remote access security
• Reconnect, backpressure, and queues