Integrations

It has to fit the stack you already run.

VisaRoxy reads cameras over open streaming standards and sends events out over webhooks and a REST API. That covers the two directions that matter: what the platform consumes, and where its decisions end up.

Inbound

What VisaRoxy reads.

The camera layer is where most vision projects get stuck, because it is the layer with the most vendors and the least appetite for change. VisaRoxy treats it as a utility.

RTSP streams
Any camera that publishes an RTSP URL can be onboarded. This is the common denominator across vendors, and it covers the majority of installations that are more than a few years old.
ONVIF devices
Cameras that implement ONVIF discovery and media profiles can be found and configured without entering a stream URL by hand, which is what makes onboarding a site with a large camera count practical.
Encoded analogue
Sites still running analogue cameras behind an encoder work without change, because the encoder already presents a stream. No camera replacement is required to start.
Your VMS
VisaRoxy does not replace a video management system and does not need to take over recording. It reads a stream alongside the VMS, so retention, review and evidentiary workflow stay where they are.
Sub-streams
Where a camera publishes a lower-resolution sub-stream, agents can analyse that instead of the main stream. It reduces bandwidth and compute, and for most operational rules the extra detail is not needed.
Existing sensors
Access control, door contacts and PLC signals can be included as context in a rule where the site already exposes them, so an event can require both a camera condition and a machine state.

Outbound

What leaves the platform, and in what shape.

An event is a small, well-defined record. Anything downstream — a ticket, an alert, a dashboard, a data warehouse — is built on the same structure.

Every confirmed event is delivered as a JSON object to an outbound webhook at the moment it is created, and is available from the REST API afterwards. The payload is deliberately boring: identifiers, timestamps, the zone, the class, the duration, the severity, and a reference to the clip.

Because the shape is stable, a site can build its own routing rather than depending on a connector we ship. A team that wants walkway breaches in one queue and housekeeping observations in another writes that rule against the payload instead of asking us to add a setting.

Clip references are separate from event metadata, which allows an analyst or a reporting tool to read event counts without being granted access to video. That separation is enforced by the access rules described on the security page, not by convention.

Webhook delivery is retried with backoff when a destination is unavailable, and failures are visible in the event's delivery record. An event that could not be delivered is not silently dropped; it stays in the queue with its error, which is the difference between an integration that is broken and one that is merely slow.

{
  "event_id": "evt_01J8QK4M2X",
  "event_name": "Vehicle in pedestrian walkway",
  "severity": "high",
  "occurred_at": "2025-03-11T08:41:12Z",
  "duration_seconds": 11,
  "site": "dc-north",
  "zone": "walkway-d04",
  "camera": "dock-04-receiving",
  "agent": "loading-dock-sentinel",
  "objects": [
    { "class": "vehicle", "track_id": "t-4471" }
  ],
  "clip_ref": "clip_9f2c…",
  "acknowledgement": {
    "state": "pending",
    "escalates_at": "2025-03-11T08:43:12Z"
  }
}

Illustrative payload showing the fields a destination receives. Values are sample data.

Destinations

Where events usually end up.

These are the categories a deployment delivers into. Specific named connectors are scoped during a pilot, because the destination systems differ from site to site.

Alerting

On-call and team messaging

The common first destination. Events route to a channel, a rota or an on-call schedule with the clip attached, so the first person to see it has the context to decide whether it needs a walk.

Delivered by webhook into whatever the site already uses for shift communication.

Ticketing

ITSM and work management

Safety and compliance events often need a ticket with an owner, a due date and a closing condition. The agent opens it with the event attached and the zone recorded, so the record is generated by the work rather than assembled for an audit.

Delivered by REST API or webhook, depending on the destination's preference.

Analytics

Warehouse and BI

Event metadata is a clean operational dataset: zone, type, duration, response time, outcome. Landed in a warehouse it sits alongside production and logistics data, which is what makes correlation possible.

Delivered by API pull or webhook push, depending on how the pipeline is built.

Video

VMS bookmarks

Where a site's evidentiary workflow lives in its video management system, an event can place a bookmark at the right timestamp so the existing review process finds it without anyone searching.

Scoped per VMS during onboarding, since vendor interfaces differ.

Equipment

Signals and controls

Some events warrant a physical response rather than a message: a walkway beacon, a barrier, a signal to a control system. Actions can be configured to drive an output where the site exposes a way to receive it.

Requires a defined interface on the equipment side and a safety review of the action.

Identity

Single sign-on

Operators sign in through the site's existing directory using standard federation, so access follows joiners, movers and leavers rather than being maintained by hand in a second system.

Configured during onboarding; local accounts remain available where no directory exists.

Straight answer

What we will not put on this page.

Integration pages in this category usually show a wall of partner logos. That wall is not evidence of anything, and we are not going to build one we cannot stand behind.

VisaRoxy does not display a catalogue of certified partner integrations, because we have not asked third parties to certify anything and we are not going to imply a relationship that does not exist. What the platform guarantees is narrower and more useful: it reads streams over open standards, and it emits a stable event payload over webhooks and a documented REST API.

In practice that means almost any destination is reachable, because the destination only has to accept an HTTP request with a JSON body. Where a target system has an awkward interface — an older ITSM that only accepts a specific XML envelope, or a VMS whose bookmark API is vendor-specific — the work is a small adapter, and it is scoped and agreed rather than assumed.

That adapter work is a defined step in onboarding, not an open-ended promise. We look at the destination's interface, confirm what it accepts, and write the translation between the VisaRoxy payload and what the target expects. If it turns out the destination cannot accept an external event at all, we say so before the pilot rather than after.

If you need a specific system on day one

Name it during the walkthrough. We will tell you plainly whether it is a webhook, a short adapter, or something that needs a conversation with the vendor.

Before you connect anything

Outbound integrations are the part of a deployment that a network and security team will scrutinise hardest. The platform is built so that the answer is specific rather than reassuring.

  • Outbound only from the runtimeNo inbound path from the internet into the site network is required.
  • Explicit destination allow-listEvents are delivered only to endpoints you nominate and approve.
  • Per-destination credentialsTokens and secrets are scoped to a single destination, not shared across them.
  • Delivery recordsEvery delivery attempt, retry and failure is recorded against the event.
Read the full data handling position

Outbound destinations

dc-north · 4 endpoints configured

Healthy
  • Shift alerts Team messaging webhook Last delivery 14:32:08 · 142 ms
  • Safety queue ITSM ticket endpoint Last delivery 13:47:02 · ticket 4412
  • Site channel Beacon output Last signal 14:32:08 · 1 walkway beacon
  • Data platform Event metadata push Retrying · destination returned 503

Illustrative interface with sample data.

Bring your stack diagram to the call.

We will tell you which parts are a webhook, which are a short adapter, and which need a conversation with a vendor before anything is promised.