One Case File Across Every Camera Vendor
This connector is not prebuilt. It would be built to your requirement on the same ingestion and export architecture that carries the shipped connectors, with scope and effort agreed per engagement. Axon Evidence.com is where an agency running Axon body-worn cameras stores and shares that footage. Built, the connector would move evidence in both directions with its metadata, which is what an agency wants when it holds footage from more than one camera vendor and would rather work one case file than one store per vendor. Axon Evidence.com would keep doing its job for the cameras it manages.
How it connects
Two directions, and they are separate pieces of work. Inbound would be an ingestion connector: evidence and the metadata the source exposes transfer into the platform on a schedule rather than on source-side events. The pull would be scoped by an extension allowlist and excluded paths, the source hierarchy preserved or flattened as configured, and the source item left, moved or deleted afterwards according to what you set.
Outbound would be an export connector, driven by a stored query that can include material already in the library, recreating the folder structure at the destination. Export activity is logged, so what left and when is answerable later.
Case and incident identifiers would arrive as custom attributes, which is how a case reference survives the boundary in either direction. Those attributes are typed and searchable, so a case number that came in with the footage is also the thing you search on. What can be carried is bounded by what the vendor's system exposes, and an engagement would establish that before anything is built.
What you can do together
- Hold body-worn footage alongside interview recordings, CCTV and documents in one Digital Evidence Management case file, with a SHA-384 integrity hash recorded at ingest and a custody entry naming the user, their address and the time for every action afterwards.
- Redact faces, plates, bystanders and audio with Redactor before anything is disclosed, then send the redacted copy back out through the export connector rather than handing it over by drive.
- Ask AI Intelligence Hub what a day of footage and statements contains, and get an answer citing the clip and the moment, limited to the cases the person asking may open.
- Keep the agency's case number attached to the evidence on the way in and on the way out, so the record on each side still points at the same case.
A scenario
- ScopingThe engagement would agree which evidence categories transfer, which identifiers are carried as custom attributes, and whether the source item is left in place after transfer.
- SetupAn administrator would configure the inbound connector once, mapping the case number and incident identifier onto attributes the portal already searches, with a run every hour.
- Tuesday, 23:10A deputy's footage would arrive from Axon Evidence.com after the next run and land in the Digital Evidence Management case file carrying that case number, with its hash recorded and a custody entry for the transfer.
- ThursdayThe records unit would open a public records request against that case, and Redactor would blur the two bystanders and mute the address read out on the radio, with the redaction logged like every other action.
- FridayThe stored query would export the redacted copy and its attributes to the destination the office nominated, and the export would be logged against the case.
- Months laterA supervisor would verify the hash before the file goes to court, and read the custody trail showing who held it and when.
What stays where
Axon Evidence.com would remain the store for the cameras it manages
Camera assignment, upload from the dock and the vendor's own retention keep working exactly as they do. The connector would move copies of what you scope and nothing else.
The platform would read, and write back only what you send
Inbound transfer is on your schedule, outbound is on a stored query you control, and nothing else leaves.
Nothing would be replaced
Officers would go on using the cameras and the vendor's system. The case file gives the agency one place where footage from every vendor sits under one custody model, one access model and one search.
Processing would run where you deploy
Redaction, indexing and the assistant would run on the portal's infrastructure, whether that is a dedicated cloud, your own government cloud subscription, or your own servers.
Products and solutions
Case Records From Axon, Evidence Kept Under Your Own Custody
This connector is not prebuilt. It would be built to your requirement on the REST API and ingestion path the platform already uses, with scope and effort agreed per engagement. Axon Records is the records management system in the Axon suite, holding reports and case files. An agency reaching for this connection usually has a specific reason: it runs Axon Records but wants evidence held under its own custody and retention rather than entirely inside one vendor's suite.
How it connects
Case and report records would come across over the API, and the case number would arrive as a custom attribute on the media, so evidence files against the right case. That attribute is what keeps material retrievable against the record once it sits outside the suite it was written in.
An engagement would establish the division of responsibility carefully, because this is the connection where it is least obvious. Axon Records holds the report; Axon Evidence may already hold media for the same case; and the library would hold material under its own custody model. Three places holding evidence for one case is a disclosure problem rather than an architecture preference, so the engagement decides what lives where and the answer is written down rather than left to practice.
Axon Records stays the authoritative record for reports and case files, report writing does not change, and nothing is written back unless a step is scoped for it. Whether a closed case changes retention on material held here is agreed rather than assumed.
What you can do together
- File evidence against the Axon Records case number while holding it under your own custody and retention.
- Assemble what a case file needs with a workflow reading the record.
- Decide explicitly what lives in Axon Evidence and what lives in the library, rather than discovering it during disclosure.
- Check that items a report cites are actually present.
A scenario
- ScopingThe engagement would agree the division between Axon Evidence and the library, and settle retention on case closure.
- SetupThe connection is configured once against the Axon Records API with the case number mapped to an attribute.
- FilingInterviews and footage received from other sources file against the case under the library's custody record.
- Case preparationA workflow gathers what is attached and lists cited items that are absent.
- DisclosureThe agency produces from a known division of material rather than searching three places.
What stays where
Axon Records remains the authoritative record
Reports and case files stay there, and report writing is unchanged.
Where each kind of evidence lives is written down
Three stores holding evidence for one case is a disclosure problem, so the division is decided rather than left to practice.
The case number travels with the material
It arrives as an attribute and survives export and transfer.
Processing runs where you deploy the platform
Shared or dedicated SaaS, your own cloud, on premises, or air-gapped.
Products and solutions
Next step
See it on your own Axon instance. We will show the connection made, the data moving and the output, then size it for your deployment.
Request a demonstration or write to sales@vidizmo.ai
sales@vidizmo.ai · vidizmo.ai/integrations/catalog/axon