Skip to main content

​
The problem

Critical operations stop when the network does. A dispatch centre loses contact with its field teams. A clinic cannot record what happens during an outage. A payment point stops confirming transactions when the line drops. Connectivity is never guaranteed, yet most systems assume it is.

​
What wede does

wede is an operational continuity platform. You integrate once, through a REST API or one of the SDKs, and wede keeps each operation moving whatever the state of the network. When connectivity degrades, wede moves delivery to the next available channel without any change to your integration. Operations captured with no connectivity at all are kept on the device with an integrity checksum and synchronised when the network returns. Whoever is at either end, a dispatcher, a field team or your own customer, keeps working.

​
What a network does not solve

Better coverage does not tell you which operations happened during an outage, in what order, whether any arrived twice, who answered them or how they reconcile with your core systems. wede does, on every network, with the devices your people already carry, and without imposing limits on the operation itself: value limits, eligibility and approvals stay with you and your partners. Every new kind of link is one more channel in your cascade, not a reason to rebuild your integration. See Continuity, not connectivity.

​
Where it is used

wede is vertical-agnostic and region-agnostic by design. It serves organisations where downtime is not an option:
  • Healthcare and emergency services: emergency dispatch, field medical teams, patient-related operations
  • Banking and fintech: payment terminals, ATMs, field agents, transaction confirmation and reconciliation
  • Logistics and delivery: last-mile coordination, fleet and warehouse operations
  • Telecommunications: network operations and field engineer dispatch
  • Government and public services: civil protection, utilities, citizen services
The same foundation applies anywhere operations cannot depend on internet access: industrial and IoT monitoring, critical infrastructure, rural supply chains, maritime operations and humanitarian response. wede is not tied to phones, tablets and computers: the API and the SDKs integrate hardware, whatever the vertical, from payment terminals, ATMs and medical devices to EV chargers, solar plant equipment, meters, vehicle units and any other machine you already operate. No new hardware is required.

​
One core, optional modules

Every integration uses the same core: events, delivery through your channel cascade, offline capture and sync, and signed webhooks. A payment network, a clinic records system or a citizen service needs nothing more. Operational verticals that send people to the field (emergency services, healthcare field teams, field services and delivery) can add the teams, dispatch and missions module on top of the core: team management, ranking of the best available team, missions followed from dispatch to completion, and automatic substitution when a team does not acknowledge in time.

​
Channels

wede delivers through several channels and records on every event the channel it actually used (channel_used):

​
Continuity modes

There is no single fixed hierarchy. Each tenant defines its own path across channels and chooses how wede behaves when a zone is not online:
  • Automatic cascade: wede follows the channel order you define, moving to the next channel when one is unavailable, and queues the operation only as a last resort.
  • Store-and-forward: wede holds the operation and delivers it when connectivity returns.
In either mode, every queued operation is synchronised exactly once, with integrity checks, when connectivity returns. An operation that already reached wede, online or in an earlier batch, is recognised as a duplicate and never stored twice.

​
How it works

  1. Your system sends an event to POST /v1/events, or captures it offline with an SDK and sends it later in a batch to POST /v1/sync/batch.
  2. wede checks the event against your tenant’s catalog of event types, stores it and starts delivery.
  3. wede follows the connectivity state of each operational zone (online, degraded, sms_only, voice_only, offline) and delivers through the path your continuity mode allows.
  4. Your systems receive signed webhooks as the event is created, delivered or fails.
An event’s status is its delivery status: completed once delivered, pending while queued. After delivery, wede clears the stored payload and keeps only identifiers, type, channel and lifecycle.

​
A first event

type is an event type from your tenant’s catalog, which wede never sees beyond its category. vertical, idempotency_key and payload are required; priority is optional and defaults to the priority defined for the type in your catalog. The API answers 202 with the event_id and the dispatch outlook for the event.

​
Hosting

All requests go to https://api.wede.pt over HTTPS. 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.

Quickstart

Send, read back and sync your first events

Authentication

API keys, session tokens and roles

SDKs

JavaScript, Python, Swift and Android

API reference

Every endpoint in detail