Build a VIDIZMO Integration

THE PATHS

What each path is good for

Same platform, several entry points. The right one is usually decided by what your product can emit, not by what it can be asked to do.

REST API

Outbound, VIDIZMO calls you: an HTTP request node with configurable method, headers, parameters and timeout. Inbound, you call us: an external system invokes a workflow over HTTP, then polls for status and result.

Best for: Anything with a documented API and a synchronous answer
You provide: Endpoint, auth model, test credentials

Webhooks

Outbound webhooks fire on media actions, metadata changes, live sessions and workflow completion. Inbound, the HTTP trigger node accepts your payload and maps request data straight into workflow state.

Best for: Event-driven handoffs where neither side should poll
You provide: A receiving endpoint, or the events you can emit

MCP

If your product publishes a Model Context Protocol server, VIDIZMO reaches it over Streamable HTTP, Server-Sent Events or WebSocket, with no connector build at all. The query runs as the person asking, so your permissions still decide the answer.

Best for: Live lookups against data too large or too sensitive to copy
You provide: An MCP server URL and its auth

Workflow designer

65 nodes across 12 categories: AI, annotation, control flow, data, embedding, human-in-the-loop, integration, output, processing, triggers, tools and platform actions. Customers assemble integrations on a canvas without writing code.

Best for: Per-customer variations on a pattern you do not want to hard-code
You provide: Nothing beyond one of the paths above

Open standards

Identity, storage and metadata often need no custom work: single sign-on against the customer's directory, ingest from and archive to their own storage tier, and metadata that stays in sync both ways.

Best for: Infrastructure, storage and identity vendors
You provide: The standard you already support

Not sure? Bring it anyway

An unlisted system is usually configuration rather than a project. Send the product name and which way the data should flow, and our engineers will tell you which path it is and what it takes.

PICK YOUR PATH

Start from what your product does

The path most integrations end up on, by what the partner system is.
If your product…	What usually moves	Path
Records or streams video	Streams and recorded exports in; detections, tags and case references back out	REST API + webhooks
Holds cases, records or evidence	Case and record identifiers in; redacted releasable copies and audit entries out	REST API
Is where people already work	Questions in from the user's own tool; answers, transcripts and clips back	MCP
Stores or archives content	Ingest and archive in both directions, with metadata kept in sync	Open standards
Emits events on state change	Your event fires a VIDIZMO workflow; completion fires a callback to you	Webhooks
Varies a lot per customer	The same pattern, assembled differently by each deployment	Workflow designer

BEFORE WE BUILD

What the scoping call collects

What we need from you

None of this is a gate on starting the conversation. It is what the scoping call collects.

API or MCP documentation — public links are ideal; a PDF is fine.
A sandbox or test tenant with credentials our engineers can use end to end.
The auth model — OAuth, API key, mutual TLS or certificate, and how tokens are refreshed.
Rate limits and payload ceilings, so ingest is designed to stay inside them.
The fields that matter — the identifiers that bind a media file to a case, record, asset or user.
A technical contact who can answer a question inside a working day.
Your deployment shapes — cloud, on-premise, air-gapped, or all three.

What a listing carries

You write the description; we publish it. Keep it to what the integration does for a customer.

Product name and logo — SVG or PNG with transparency, and any usage rules we should follow.
One line, in plain language — outcome first, for example "Teams recordings ingest automatically".
Category — one of the seventeen in the catalog.
Industries — education, financial services, government, healthcare, legal, public safety.
VIDIZMO products it works with, from the five.
Availability — available once published, or on request while it is per-deployment.
A documentation link on your side, for customers who want the detail.

BEFORE IT PUBLISHES

What we test, and what you sign off

We verify

Round trip on real data. Ingest, processing and write-back completed end to end against your sandbox, not a mocked response.
Auth renewal and failure. Token refresh, expired credentials and a revoked key all behave predictably instead of stalling a workflow.
Permission fidelity. A live query returns only what the person asking is entitled to in your system.
Volume and retry. Behaviour at your rate limit, on timeout and on partial failure, with retries that do not duplicate records.

You confirm

The field mapping is right. Especially the identifiers that bind media to a case, record or asset. This is where mistakes are expensive.
The listing copy is accurate. Name, description, category and logo, as they will appear in the catalog.
Supported versions. Which releases of your product the connector is certified against.
A change channel. Where deprecations and new API versions will be announced, so the connector is updated before a customer notices.

DEPLOYMENT REALITY

Where the integration can run

Cloud, on-premise and air-gapped

Many VIDIZMO customers run in environments that cannot accept an inbound call from a vendor's cloud. That does not rule out an integration; it decides which direction it runs in.

Outbound paths work in disconnected deployments. VIDIZMO calling your system, writing to a storage tier, or firing a webhook out are all fine, provided the destination is reachable from inside the customer's network.

Inbound paths need a reachable endpoint. Anything relying on your cloud initiating the call, a webhook into VIDIZMO or an externally triggered workflow, has to be scoped per deployment, and sometimes replaced by a polling pattern on our side.

Access control does not change with deployment shape. A live query against a connected system runs as the person asking, so that system's own rules decide what comes back. An integration widens what VIDIZMO can reach; it never widens what a user is allowed to see.

TECHNICAL QUESTIONS

Asked on most scoping calls

Do we have to write any code?

No. VIDIZMO's integration engineers build the connector against your documented interface. Your engineering effort is documentation, test access and review.

How long does a connector take?

It depends almost entirely on how clean the interface is. A well-documented REST API with a working sandbox is a short build; an undocumented interface, a bespoke auth scheme, or a system that only exports on a schedule takes longer. We do not commit to a delivery date up front. Build order follows customer demand, and a named shared account moves an integration up the queue.

Who hosts the connector?

The connector is deployed with the customer's VIDIZMO environment, so it follows whatever their deployment already is: cloud, on-premise or air-gapped. We will confirm the exact topology for your integration during scoping.

What happens when we ship a breaking API change?

We maintain the connector and will update it, but we do not monitor your release notes, so we need to hear about the change from you. That is why a change channel is agreed at sign-off rather than discovered from a customer's failed workflow.

Can we start with "on request" instead of a public listing?

Yes, and many integrations do. On request means it exists and is deployed per customer; available means any customer can turn it on. Moving from one to the other is a status change, not a rebuild.

Pick the path your product already speaks.

What connects to what