Adding Devices - Universal Camera Support
This page covers adding individual cameras through the Universal camera support option in Configuration. It walks through how to choose an alarm method, copy the generated credentials into the camera, and validate the setup. Covers: How to Add a Device, Step 1 — Choose the Alarm Method, Step 2 — Copy the Connection Details, Step 3 — Forward Alarms (Optional).
Use Adding Devices & Automatic Configuration when you need to connect a camera or device that will push alarms to GC Surge on its own — using REST API, Email (SMTP), or FTP. This is the Universal camera support option in the ADD menu. If you reach this setup through Guided Setup, the same option appears as “My camera can send alarms (API, FTP or SMTP)” — both entry points lead to the same flow.
For an overview of all four ways to add a camera, see . For adding a new site using Guided Setup, manual setup, or spreadsheet import, see . This page covers the Universal camera support method only.
How to Add a Device
The Add a device modal is a plug-and-play wizard with three guided steps:
- In Configuration, click ADD and select Universal camera support.
- Step 1 — How should alarms be sent to GC Surge? Enter a Device name (see Camera Naming Standards below), choose the site from Select site (if the site doesn’t exist yet, GC Surge creates it automatically), then pick the method your device supports: REST API, Email (SMTP), or FTP.
- Step 2 — Connection details. GC Surge generates the connection credentials for the method you chose — copy them into your camera’s alarm-forwarding settings (details per method below).
- Step 3 — Forward Alarms (Optional). Optionally add a forward rule with + Add Forward Alarm, or skip it.
- Click Add Device, then Done. The device is registered regardless of whether a forward rule is set.
Step 1 — Choose the Alarm Method
In the Add a device modal you choose the alarm-delivery method your device or system supports. The three methods are:
- REST API — the device sends alarms via HTTP POST with structured JSON metadata and inline snapshots, giving sub-second latency. It's the best transport when the device supports it; if the device can't do HTTP POST out of the box, fall back to Email (SMTP), which works everywhere but with higher latency.
- Email (SMTP) — the device emails an alarm (with snapshot attached) to a dedicated GC Surge inbox, which parses the subject, body and attachment into an alarm event. Since almost every IP camera can email motion alerts, it's the universal fallback. End-to-end latency is typically 2–10 seconds.
- FTP — the device uploads an image to an FTP server GC Surge provides, common on older or budget DVRs. FTP carries only the image file and filename — no structured metadata — so GC Surge infers the timestamp from the filename and treats each upload as an alarm. It's the lowest-fidelity transport; use it as a last resort and switch to REST or SMTP when you replace the device.
Prefer GC Surge to configure the camera for you? If you onboard supported brands (HikVision, Dahua, Axis, NxWitness; for Hanwha and SpykeBox select NxWitness) through Add Sites, GC Surge connects to the camera and pushes the alarm-forwarding settings automatically — no manual copying (see the Automatic Configuration section below). In the quick Add a device flow here, you copy the credentials from Step 2 into the camera yourself.
Step 2 — Copy the Connection Details
GC Surge generates all connection credentials automatically. Use the copy buttons next to each file — you do not create these credentials.
- REST API: Device ID, Events URL, API token.
- Email (SMTP): Device ID, SMTP host, SMTP port, Username, Password, Encryption type, To email, From email.
- FTP: Device ID, FTP host, FTP port, Username, Password.
Paste these values exactly into the corresponding fields in your camera’s alarm forwarding configuration. One character error in any credential field will prevent alarms from reaching GC Surge.
The credentials shown are unique per device and can be regenerated if they leak. For REST API, GC Surge generates a callback (Events) URL to paste into the camera's HTTP notification settings; for Email (SMTP) the port is usually 587; for FTP, enter the displayed host, port, username and password into the camera's upload settings.
For Email (SMTP), the SMTP host (smtp.zeptomail.eu) is shared across devices. Each device receives a unique To address (the @zeptomail.eu address the camera sends alarms to) and a unique From address (an @nxgen.io address) — both are generated automatically. The To address is how GC Surge identifies which device an alarm came from. The alerts@nxgen.io address visible in the Forward Alarms section is the optional post-processing forwarding destination, not the device From address.
Step 3 — Forward Alarms (Optional)
Optionally configure where verified real alarms should be forwarded after processing — for example, to an external Central Monitoring Station (CMS) via email or webhook. Click Done when finished. This step is optional; the device is already registered and receiving alarms before you configure forwarding.
Forwarding doesn't change ingest — only what happens after NOVA99x classification: every alarm marked real (or confirmed by an operator) is forwarded over your chosen protocol. Options are DC09 for traditional alarm receivers, email for ad-hoc notifications, or webhook for arbitrary integrations. Most monitoring stations run their whole workflow inside ZenMode and don't forward at all; if you do, set it up once per device and the same rule applies to every alarm from that camera. See CMS Forwarding for the full setup guide.
Automatic Configuration for Supported Brands
For HikVision, Dahua, Axis, and NxWitness devices on public IP connections added through Add Sites, GC Surge pushes alarm forwarding credentials directly to the camera — no manual copying required. The platform handles everything after you submit the site. (Hanwha and SpykeBox run on the NxWitness platform — select NxWitness as the brand.)
On a supported camera, GC Surge enables two things automatically: the SMTP/email server settings and the event-notification trigger that makes the camera send an email on each alarm. Both are applied with no manual step.
For Private/VPN and Edge connections, configuration is delivered through an on-site agent. See Setting Up Sites for connection type details and Local Agent — Field Activation for the on-site activation procedure.
Connection Status After Adding
The Sites dashboard shows the configuration result for every device:
- Done — the device is fully configured and sending alarm events to GC Surge. No action required.
- Pending — the device has been added but the cloud has not yet finished pushing configuration or received a confirmation alarm. Resolves automatically; wait a few minutes before taking any action.
- Error — GC Surge created the configuration but could not push it to the device, usually because the device was offline during setup or the credentials were wrong. Click Retry from the device Actions (…) menu — a Retry integration config modal opens where you can update the IP/Host, Protocol, port, username, and password inline before retrying. You do not need to remove and re-add the device.
Partial Pending and Partial Error appear only at the site level — when some, but not all, of a site’s cameras have finished configuring. A single device shows one of the three states above — or Manually configured if you set it up by hand (see Manual Fallback below).
Manual Fallback
If automated configuration doesn't succeed — for example a device stays in Error after a couple of Retry attempts, or the camera's brand or firmware doesn't accept the automatic push — you can configure it by hand instead:
- Open the connection details from Step 2 (SMTP/FTP host, port, username, password).
- Log in to the camera's own web interface and enter those values into its alarm-forwarding (email/FTP) settings manually.
- Back in GC Surge, confirm you've done it — the device is then marked Manually configured instead of staying in Error.
A Manually configured device sends alarms exactly like an auto-configured one; the only difference is that you entered the settings on the camera yourself. (This is the same manual step used for unsupported brands — here it is just a fallback when the automatic push fails.)
Camera Naming Standards
Camera names appear in Video Search event cards, Analytics breakdowns, subscription camera rows, and Configuration device lists. Descriptive names make large deployments manageable; generic names create persistent operational problems at scale.
- Use names that describe physical location:
Front-Gate-Cam-1,Parking-Level-B2-Exit,Server-Room-Entrance. - Use a consistent format across all cameras:
[Location]-[Zone]-[Number]. - Avoid generic names like Camera 1, Camera 2, or Device A — these become indistinguishable in views showing 200+ cameras.
- Do not duplicate a camera name that already exists on a different site — naming conflicts cause confusion in search and billing views.
Post-Registration Validation
After adding a camera, confirm the following before marking the device as operational:
- Configuration check — confirm the camera appears under the correct site and the device count has incremented.
- Video Search check — confirm events from the new camera appear in Video Search. This verifies the full alarm pipeline is working. Allow a few minutes after activation for the first events to arrive.
- Home dashboard check — confirm alarm KPI metrics reflect activity from the new site and camera. This confirms the camera is contributing to operational dashboards.
Best Practices
- Check the Sites dashboard after adding devices — do not assume all devices configured successfully until you see the status.
- If a device shows Error, correct the credentials and click Retry before contacting support. Most failures are caused by wrong credentials or a temporarily offline device.
- Name cameras before deployment begins — names are harder to change consistently after devices are live and appearing in dashboards.