Skip to content

Developers · Partner API

Voice-to-NERIS inside your own product

A firefighter taps a mic in your incident form and talks. One HTTP call later you have the transcript and a NERIS-shaped draft to fill the form with. Your product stays the system of record and the one that files.

Last updated September 2026.

What you get

  • One endpoint. POST https://app.fire-mic.com/v1/narrations takes audio (or plain transcript text) plus the department’s NERIS id, and returns the transcript, the incident as a NERIS v1 payload, the required fields it could not fill, and per-stage timings. Typical round trip for a one-minute narration is 4 to 8 seconds.
  • Nothing to host. No SDK to vendor, no model to run, no NERIS credentials to hand us. Any HTTP client in any language.
  • Your users, your records. There are no FireMic accounts for your users. The credential is yours; the department is identified by its NERIS id; the firefighter never leaves your product.
  • Test first, sign later. A sandbox key works against the same production pipeline with tighter limits, so an engineer can integrate before a commercial agreement exists.

What we never do

  • We never submit to NERIS on this surface. The API has no submit route, and the partner surface cannot reach our own NERIS client. You remain the submitter of record, with your validation, your state exports and your audit trail untouched.
  • We never see a NERIS username, password or client secret of yours.
  • We never guess silently. A required field the narration did not cover comes back in gaps, with the question we would ask the firefighter, instead of a made-up value.

The flow, in four steps

  1. Mint a session. Your backend (or, for a desktop client with no server tier, the client itself) calls POST /v1/sessions with your API key and the department’s NERIS id. You get a token that lives 15 minutes and can only act for that department. Keys never ship inside client code.
  2. Record and send. Your form records audio however you like and posts it, base64-encoded, to POST /v1/narrations with the session token. Or post text instead of audio if you already have a transcript.
  3. Fill the form. The response carries neris, the same module shape NERIS accepts on its own incident endpoint. Map it to your fields once, at setup. Show transcript next to the fields so the firefighter can check what was heard, and surface gaps as the things still to fill.
  4. Tell us what happened. When the firefighter saves, call POST /v1/narrations/{id}/outcome with whether the draft was kept and which fields they edited. This is optional, and it is how extraction gets better for your departments specifically.

Try it in a minute

Text mode needs no audio file. With a sandbox key:

curl -s https://app.fire-mic.com/v1/narrations \
  -H "Authorization: Bearer $FIREMIC_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "department": "FD34007744",
    "external_ref": "INC-2026-001847",
    "transcript": "Engine 31 responded to 214 Maple Avenue for a reported structure fire, dispatched 14:21, on scene 14:27. Two story wood frame, light smoke showing second floor rear. Pulled an inch and three quarter through the front door, fire in a rear bedroom, room and contents, knocked down in about five minutes. Ladder 5 did a primary search, all clear. One occupant self evacuated, evaluated on scene, refused transport. Smoke detectors present and operated. Cause appears to be a space heater. Cleared at 15:45."
  }'

The quickstart has the same call in C#, Swift, Kotlin and JavaScript, and the audio version.

How fast it is

Measured against production in September 2026, one-minute narrations:

Step Typical time
Upload and transcription 0.5 to 0.7 s per minute of audio
Core extraction (incident type, location, times, units, narrative) 2 to 6 s, scaling with narration length
Module detail (fire, medical, hazardous situation), run in parallel 0.5 to 1.5 s
Whole call, wall clock 4 to 8 s

These are current measurements, not guarantees. Hold the connection open; set your client timeout to at least 120 seconds so a long or slow narration completes rather than orphaning a result. If your product needs it faster, the pipeline can be tuned further for a partner. Ask.

While the call is in flight, GET /v1/processing-messages gives you the same rotating “while you wait” lines our own app shows, grouped by phase, if you want them. It is public and cacheable and entirely optional.

Where it runs

RedAlert-style desktop clients, native mobile apps and mounted tablets all work the same way: record on the device, one HTTPS call, fill the form. Anything with a webview can instead open our hosted mic page with a session token and receive the finished draft as a single message, with host snippets for WebView2, WKWebView, Android WebView and the web. The page uses the same REST route documented here.

What we keep, and for how long

Every call is recorded: which partner and department, the transcript, the draft we returned, the gaps, timings, and later the outcome you report. Transcript, draft and outcome are retained so we can measure and improve extraction quality for your departments. Audio is stored separately and deleted after 30 days by default; a partner can set that shorter, including zero. Delete-on-request is honoured at the partner, department or narration level. No narration data is ever shared with another partner, and none of it is used to train anything outside FireMic. The full statement is in the API reference.

Getting a key

Keys are issued by a person, not a signup form. Use the contact buttons on the About page with the subject “Partner API key” and tell us the product it is for. You get a sandbox key the same day; live keys follow the agreement. Keys can be partner-wide, naming the department on each request, or pinned to a single department so a key living inside one station’s install can never act for another.

Next