cardiac_arrest event, a dispatcher scores the available teams and dispatches the best one, the crew app reports each mission step, and your backend receives every change as a signed webhook.
All names, coordinates and identifiers below are illustrative.
Who does what
wede uses two credentials. The API key is your server’s integration credential. People (dispatchers, crews, administrators) sign in and use a session token whose permissions come from their role.
An API key calling a team, dispatch, mission or catalog write endpoint receives
403 forbidden.
The snippets call the REST API through a small helper, so they run in Node.js 20 or later, browsers and React Native without extra packages:
lib/wede.ts
1. Create your event types (one time)
Event types belong to your tenant and live in your catalog, organised by category. wede pre-loads the healthcare catalog (cardiac_arrest, trauma, stroke and others under Pre-hospital emergency; clinical system outages under Hospital continuity), so most integrations only read it. Add your own types when you need them; this needs a signed-in administrator, so run it as a setup script, not from your integration server.
setup-catalog.ts
requires_teams decides whether the event enters dispatch; required_equipment lists codes from your equipment list (GET /v1/catalog/equipment, 422 unknown_equipment otherwise) and counts in the team score without ever blocking a dispatch.
2. Send the emergency from your server
Your dispatch or CAD server sends the event with the API key. Put the zone code inmetadata.zone_id and give every operation its own idempotency_key, so a retry after a timeout can never create a second event.
server/emergency.ts
202 with event_id, status: "pending" and environment. wede then delivers the event through the channel its continuity rules select for that zone. Sending the same idempotency_key again returns 409 duplicate_event.
Use a
wede_test_ key while you build. Sandbox events follow the same channel decision as production, never reach a real provider and never count toward usage.3. Score the teams and dispatch
The dispatcher console signs in with a user that hasdispatch:assign. Scoring with the event_id returns the free teams that cover the event’s type (or its whole category), ranked by score from 0 to 1 (higher is better). The first team is marked recommended; missing_equipment lists what the type calls for and the team lacks, which lowers the score but never excludes the team.
console/dispatch.ts
scored has team_id, team_name, status, vertical, distance_km, eta_min, equipment_match, member_availability, score, recommended, tier (1 covers the type, 2 covers its category), missing_equipment, channel and position. Teams of the vertical that are not candidates come in excluded with a reason (no_members, no_coverage).
The dispatch returns 201 with the dispatch record (id, event_id, team_id, dispatched_by, dispatched_at, notes). wede marks the team on_mission, creates a mission in CREATED status for that team and event, and sends the team.dispatched webhook. There is one mission per team and event: dispatching the same team to the same event again never creates a second mission.
Pass the wede event_id you received in step 2: a dispatch accepts only an existing production event of your tenant (404 event_not_found otherwise) and a team of your tenant (404 team_not_found). When the mission reaches COMPLETED or FAILED, wede releases the team. The event keeps its own status, which is its delivery status; follow the response through the mission. Events still waiting for a team are listed with GET /v1/events?undispatched=true.
Hand the mission to the crew
A dispatch assigns the mission to a team. Look it up, send its id to the crew’s device through your own app notifications, then mark itSENT:
console/dispatch.ts
If your tenant sets an acknowledgement timeout (
reinforcement_timeout_min in the dispatch settings), a mission still in CREATED or SENT after that time is set to FAILED with feedback.reason: "no_acknowledgement", and wede substitutes the best free team not yet called for this event (a new mission, and team.dispatched with substitution: true). If no team is free, the event returns to the dispatch queue. Have crews acknowledge (ACK) promptly.4. The crew app
The ambulance app signs the crew member in and uses the session token, never an API key. Afield_operator sees the missions of the teams they belong to with GET /v1/missions/my and can update only those missions (403 forbidden for any other).
app/inbox.ts
CREATED, SENT, ACK, ON_ROUTE, ON_SITE, COMPLETED, FAILED.
app/mission.ts
COMPLETED and FAILED are final, so a replayed update that is no longer valid returns 409 invalid_transition: treat it as already applied, or read the mission to see its current status. feedback is stored with the mission and included in the webhook.
Records captured without connectivity
Operations the crew records while offline, such as the hospital handover, are captured at the moment they happen, with the capture time and an integrity checksum, and sent later toPOST /v1/sync/batch. The checksum is the SHA-256 of JSON.stringify(payload) + idempotency_key + offline_generated_at (see Sync).
app/handover.ts
duplicate means wede already had that operation, online or from an earlier batch, and stored it only once. An event whose content changed after capture is rejected with integrity_check_failed and recorded as a security incident for your administrators. A captured event can carry metadata.zone_id and metadata.location, as an online event does; they are not part of the checksum.
5. Webhooks on your backend
Subscribe once with the API key. The secret must be at least 16 characters.server/webhooks-setup.ts
mission.status_updated
Verify the signature before you trust a delivery.
X-Wede-Signature is t=<unix seconds>,v1=<hex>, where hex is HMAC-SHA256 with your webhook secret over <t>.<raw body>.
server/webhooks.ts
2xx within 10 seconds. wede makes up to 3 attempts per delivery and disables a webhook after 10 consecutive failed deliveries. Use environment to tell sandbox deliveries from production ones.
HIPAA alignment
wede is designed to support a HIPAA-aligned deployment. Your own controls and agreements complete it.
wede is hosted in the European Union by default. Where local regulation requires in-country data residency, a dedicated regional instance is available by agreement.
Next steps
Score teams
Request and response fields.
Missions
Mission lifecycle and endpoints.
Offline sync
How batches, duplicates and checksums work.
Security
Credentials, roles and data handling.
