Answers to the questions we hear most.

Three. Confirm as Real escalates the alarm and fires the configured workflow, which might call a technician, send an SMS or email, or contact the customer. Mark as False closes it as a false positive and feeds that decision back into NOVA99x analytics. Escalate hands it to a supervisor or a higher-level operator. Whichever you choose, close the alarm with a resolution note - it is stored in the Audit Log with the operator who handled it, the time, the steps taken and the outcome.

• Use Mask for zones that keep producing false alarms rather than dismissing each one
• A resolution note on every alarm is what keeps the audit log and reporting clean

The most common root cause is Basic Motion Detection, which triggers on any pixel change including wind, rain, reflections and insects. Switching to Intelligent Video System (IVS) events targets real activity only: Line Crossing Detection fires when an object crosses a defined line, Intrusion Detection when an object enters a defined zone, and Human/Vehicle filters use edge-side AI to ignore other movement before any signal is sent. You can also lower motion sensitivity, raise the minimum object size, or require a sustained detection duration before an alarm is sent. Running the manufacturer's test client first confirms whether the device itself is flooding.

• Line Crossing and Intrusion Detection replace Basic Motion Detection
• Human/Vehicle filters drop other movement at the edge
• Lower sensitivity or raise the minimum object size
• Require sustained motion (for example 2 seconds) before alarming

Assign it. The Talos queue is live and every alarm can be assigned to a specific operator, and the queue shows who is currently working on each one, so team coordination is visible at a glance. Leaving an alarm unassigned is what lets two people pick it up at once, so assign it immediately on arrival. What an alarm triggers next depends on its type and the site configuration - Talos workflows can notify the customer, dispatch a technician, send an SMS or email, escalate to a supervisor, or log the response for reporting.

Yes. For tenants with legitimate high-volume alarm requirements the default 25-alarm limit can be increased, for example to 50 or 100, using the custom property style.overflow.threshold set at tenant or service provider level. The defaultIsolationDuration, set in minutes at service provider level, can also be configured where a customer needs different notification suppression behaviour. Threshold changes must be coordinated with the R&D team and applied only after confirming the volume is legitimate, such as an industrial site with high sensor activity, rather than a misconfigured device.

An alarm is always processed for one specific site, and Talos looks for a matching workflow in priority order: a workflow configured directly on that site wins, then one applied to its site group, then the global or company-level fallback. So the way to guarantee a critical site gets a particular response is to attach the workflow at site level. Every workflow must end with a Closing Status such as False Alarm or Police Dispatched, which is what keeps reporting and the audit trail complete. Use the bell icon on the Alarms page to fire a manual test alarm and check your logic before it goes near live sites.

• Incoming conditions combine the alarm code, a schedule, and All of (AND) or One of (OR) logic
• Automated workflows suit routine technical signals and can escalate to a manual one if unresolved
• The Alarms page shows unassigned alarms on the left and each online operator's workload on the right

CMS receivers are configured from the Marketplace, so no manual protocol setup is needed. Open Marketplace, select the Alarm Management System tab, click Explore on the CMS you want and then Configure, and enter the DC09 receiver IP address and TCP port; unlisted systems use "Other CMS System", which takes the same fields. A new Alarm Management System tab then appears under Configuration for each service provider, where every site is listed with its DC09 Account ID and connection status. Edit a site row to enter the DC09 Account ID, which must match the identifier on the CMS side, plus an optional encryption key, and alarms from that site are forwarded automatically when triggered.

• DC09-based receivers include Amwin, Lisa, Immix and any SIA DC-09 system
• Green means the site is configured, red means it is not mapped
• Each DC09 Account ID must be unique; duplicates are blocked
• GCXONE adds a secure event link with pre-event, event and post-event evidence

Evalink Talos is a cloud-based alarm management platform selected from the Marketplace like any other receiver. Click Configure and enter the Company ID and API Key from your Talos account. The API Key needs full access permissions, and both values are in your Evalink Talos account settings under API Access. Once configured, alarms triggered in GCXONE appear in Talos automatically as active events ready for operator processing. A credential error means the Company ID or API Key is wrong, or the key does not have full access.

Every endpoint in the Genesis API expects a token in the auth-token request header, and a request without one answers 401. You obtain that token by exchanging an API credential with POST /proxy/apiToken. The credential is issued per service provider, so the request names the provider the token should act for.

• The header is auth-token, sent on every request
• A missing or rejected token answers 401
• GET /user/me returns the account the token belongs to

The Genesis platform exposes a REST API over HTTPS, and every request is made against one base URL, https://api.nxgen.cloud/api/v1. Every path in the reference is relative to it, so GET /user/me means GET https://api.nxgen.cloud/api/v1/user/me. Requests carry a token in the auth-token header and the API answers JSON. The published specification version is 1.0.0.

The credential's accessId and clientSecret are issued in the Genesis platform under the service provider's settings. You exchange that credential for a token with POST /proxy/apiToken, which declares 200, 204, 400, 401 and 403. Keep the secret on your server: a token can be sent to a browser, but the credential that mints it must not be.

Yes. GET /user/me returns the account the token belongs to, which makes it the quickest check that a token works. A token that is missing or rejected answers 401 instead.

The interactive reference at /api-reference is the same specification in Swagger UI, and the overview lists every resource. Press Authorize, paste a token, and every Try it out panel sends it as auth-token. The token stays in your browser; the requests go directly from it to https://api.nxgen.cloud/api/v1.

401 means the token was missing or rejected, and 403 means it was valid but not entitled to the resource. The response table on each operation lists every status the specification declares for it, so treat that table as the list of what the call can return.

Path parameters are written in braces, as in /site/{id}, and you replace the whole placeholder, braces included. Request bodies are JSON unless an operation says otherwise. On these pages a body is shown as a skeleton: the field names with the type expected in place of each value, and (required) on the fields that must be present.

The overview lists 26 resources with their operation counts: User, Account, Site, Device, Sensor, Camera Controls, Event, Event Search, IO, Trigger, Proxy, Storage Service, Analytics, Status View, Blog, Contact, Dashboard, Folder, Integration, Audit, Report Template, Report, Schedule, Service Requests, Service Request Tab and Developer Tools. Site is the largest surface and Event Search, Proxy, Dashboard and Developer Tools have a single operation each.

• Site 19 operations, Account 11, Sensor 9, Device 8
• Report 8, IO 7, Camera Controls 6, User 6, Blog 6
• Audit 5, Analytics 4, Contact 4, Storage Service 4

POST /device/filter gets the device list with filtering, sorting and pagination. It allows hierarchical level searching, so it can be filtered using a specified hierarchy or it uses the logged in user hierarchy, and it gives the option to get additional entity fields in the response as well as configuration meta data about the entity. It declares 200 Success with an object, plus 204, 400, 401 and 403.

• POST /device/filter for the list; GET /device/{id} for one device
• site/filter, sensor/filter and user/filter follow the same shape

POST /device/ creates a new device, PUT /device/{id} updates an existing one and DELETE /device/{id} deletes it by id. All three declare 200 Success and 204 No Content alongside 400 Invalid input, 401 Unauthorized and 403 Forbidden. GET /device/{id} reads a single device back and adds 404 Not Found.

GET /site/{id} returns a site by id and GET /site/ returns one by siteName, while POST /site/filter lists sites with filtering, sorting and pagination. GET /site/{id}/devices lists the devices under a site and GET /site/{id}/users the users under it. POST /site/ creates a site, PUT /site/{id} updates it and DELETE /site/{id} deletes it by id.

• POST /site/listByCustomerIds gets sites by customer id list
• POST /site/search searches sites for app
• GET /site/id/{id}/app returns site info by site id for app

Yes. PUT /site/arming?siteId={siteId}&action={action} updates arm and disarm by siteID, and PUT /site/arming?siteName={siteName}&action={action} does the same by siteName, with action taken as a boolean. GET /site/arming/info/{id} returns the arm detail for a site id and GET /site/arming/infoByName returns arming details by site name. Isolation offers the same pair, PUT /site/isolate?siteId={siteId}&enable={enable} and PUT /site/isolate?siteName={siteName}&enable={enable}.

• isolateStartTime and duration are optional on the isolate calls
• GET /site/isolation/infoByName reads the state by site name

GET /cameraControls/getStream returns the streaming detail of a sensor: sensorId is required, and channelId, startTime and endTime are optional. GET /cameraControls/getSnapshot returns snapshot detail for a sensor and requires sensorUniqueId and deviceUniqueId, with an optional dateTime. GET /cameraControls/clipInfo gets clipinfo for the timeline from id, startDate and endDate, the dates given as epoch time.