Skip to main content

​
4 November 2026

​
Evidence packs name their key by its fingerprint

  • Evidence packs and GET /v1/evidence/public-keys name the signing key by its fingerprint, key_ref: the first 16 hexadecimal characters of the SHA-256 of the public key. It replaces key_id in new packs; packs made before stay exactly as they were signed. See The key fingerprint.
  • The signing key stays in a hardware security module; a key attestation is available to auditors on request.

​
1 November 2026

​
Refused events are kept

  • wede keeps every event it refuses with its full content as it arrived, the device, its number and the reason, as a record that cannot be changed. The result of a refused event in a sync says so with recorded: true. See Refused events are kept.
  • New GET /v1/sync/rejected: the refused events of your organisation with their content. In the dashboard, the new Refused page shows them. wede never sees their content.
  • New POST /v1/sync/rejected: a device that kept refused events with an SDK before 2.17.0 hands them to wede only to be kept, never processed again.

​
SDKs 2.17.0 and wede edge node 1.7.0

  • Every SDK keeps what it holds without network so that a long time offline never slows the device down, and works within the space the device has. With no space left it lets go only what it can download again, then refuses the new operation with WedeStorageFull; nothing already kept is lost. New storageBudgetBytes, onStorage, storageUsage and storageLevel. See Space on the device.
  • A refused event stays on the device until wede confirms it keeps its content; only then can your app clear it, and clearRejectedEvents says how many it cleared and kept.
  • The wede edge node 1.7.0 runs on the SDK 2.17.0 and answers 507 storage_full when it has no space left for an event it would accept by itself.
  • Both are in Downloads. Earlier versions keep working.

​
Value operations

  • New wede parser model Value operations (val) in every vertical except banking, for sales, transfers, purchases and refunds that are not ATM or POS. One per organisation; its types sale, transfer, purchase and refund are added to the catalog of every vertical of your organisation. See Value operations.
  • The value operation types of wede, these four and the ledger types of banking, always stay ledger types without teams and cannot be deleted: PATCH or DELETE returns 409 value_type_fixed. Their name, description and category can change, and they can be deactivated.
  • An operation with an amount and no currency takes the currency of the country of your organisation, and an ISO 4217 number such as 978 is read as its currency (EUR). Amounts are never converted.

​
31 October 2026

​
Fee on value

  • For payments, transfers and other operations with an amount, wede can agree with your organisation a fee on the value of each operation, besides the fee per event, set for each operation type. It depends on the amount of each operation, as agreed in your contract. Only accepted production operations in the currency of your country pay it; amounts are never converted, and a reversal pays nothing. See Fee on value.
  • It goes on the monthly invoice from November 2026, one line per operation type (kind: value_fee), and counts in fee_amount.
  • GET /v1/tenant/monthly-invoices returns value_fees: your fee on value by operation type. Billing in the dashboard shows it.
  • Without a fee on value agreed with your organisation, nothing changes.

​
29 October 2026

​
SDKs 2.12.0 and wede edge node 1.4.0: app tokens

  • Apps can work through your organisation’s wede edge node with one of its app tokens, also while wede does not answer. Apps of your customers use the app token alone; apps of your staff use it next to the session of the person signed in. New option edgeAppToken (edge_app_token in Python). See Working through your wede edge node.
  • Each device that registers through the node gets a key of its own, kept and sent by the SDK. What belongs to one device needs that key: its notices always, the rest when the app has no session.
  • wede edge node 1.4.0 takes app tokens (WEDE_EDGE_APP_TOKENS); its node token stays for operating the node. A node with no app tokens works as before.
  • Both are in Downloads. Apps that call wede directly need no change. Earlier versions keep working.

​
Manuals inside every package

  • Since SDKs 2.11.1 and wede edge node 1.3.1, every package includes its complete manual (MANUAL.md) and the manual of the wede API (API.md).

​
28 October 2026

​
SDKs 2.11.0 and wede edge node 1.3.0 in Downloads

  • SDKs 2.11.0 for JavaScript and TypeScript, React Native, Python, Swift and Android are available in Downloads, with everything announced for 2.10.0: the offline queue goes most urgent first, the priority of your catalog is applied on the device, larger requests are compressed, and the notices to the person who made a request. See SDKs.
  • wede edge node 1.3.0 is available in Downloads for organisations with access to it, with the notices given through the node while wede does not answer.
  • Nothing changes in your code. Earlier versions keep working.

​
Notices through the edge node while wede does not answer

  • With wede edge node 1.3.0, the app of the person who made a request gets its notices through the node even while wede does not answer, when the app and the teams that answer the request reach wede through the same node, with your texts. When wede answers again, it learns what the app already showed, so nothing is shown twice or sent again by SMS or voice. Nothing changes in your code. See Notices to the person who made a request.
  • POST /v1/devices/{device_id}/notices/ack also takes keys (request key and state), used by the edge node. See Notices for the app that made a request.
  • event.requester_update carries via: "edge" for a state the edge node gave first.

​
SMS through the provider that delivers best

  • With two or more SMS providers in your fallback order, wede now sends through the one that delivers best. It measures every SMS it hands to a provider from the delivery receipts (share delivered and time to the receipt, last 30 days); providers with at least 20 results swap places among themselves, and the others keep the place you gave them. The order of the channels stays yours and voice always runs last. wede never stores the number or the text of an SMS to measure it.
  • On by default. Turn it off with the new PATCH /v1/tenant/communications/settings (sms_measured_order), or in the Communications page of the dashboard. GET /v1/tenant/communications returns measured and send_order for each SMS provider. See SMS providers in the measured order.

​
Notices to the person who made a request

  • Your organisation writes, per event type in its catalog, the text of the notice for each state of a request: received, dispatched, on route, on site (requester_texts, one line of up to 160 characters; a state without text sends nothing). See Notices to the person who made the request.
  • The app that made the request gets each notice by the best channel it has: over the internet (new GET /v1/devices/{device_id}/notices and POST /v1/devices/{device_id}/notices/ack), through your wede edge node, or without data by an encrypted SMS status request answered with one readable SMS per notice: your sender name, your text and a link to your app or a code. Every notice goes out in your organisation’s name. See Notices to the person who made a request.
  • New webhook event.requester_update, never with a phone number. event.content_completed is now documented too.
  • New switch SMS notices to the people who make requests (sms_requester_status, off by default). Only when it is on, wede keeps the number of a person who made a request by SMS, or who chose to share it in your app (requester: { phone, shared: true } on POST /v1/events and in sync), encrypted and for that request only, until it is completed or closed. Turning it off removes every number kept. Review your privacy policy and terms before turning it on.
  • The link of these notices uses its own path, /<link code>u. The iPhone file shown in Settings, Link in SMS already includes it; until your published file covers it, these notices go out with the code and the links for your teams keep working.

​
SDKs 2.11.0

  • Every SDK reads and confirms the notices (requesterNotices, ackRequesterNotices), asks for them by SMS without data (requesterStatusRequest) and reads the answer with openMessage; the request can carry the number the person chose to share. See SDKs.

​
27 October 2026

  • The wede dashboard now keeps its session in a cookie set by the API (HttpOnly, Secure, SameSite=Strict), which scripts on the page cannot read. Only the wede dashboard addresses receive credentials in cross-origin responses, and requests that change data with that cookie need a header that only those addresses send. See Security.
  • Signing in to the dashboard with an API key is no longer possible: people sign in with email and password or single sign-on. API keys stay the credential of your servers.
  • New POST /v1/auth/logout, used by the dashboard to end its session.
  • Your integrations are unchanged: POST /v1/auth/login still returns the token in the body, and API keys and session tokens keep working in their headers.
  • Sign-in, account creation, password recovery and token requests are also limited per address, so that one source cannot try passwords or create accounts without limit.

​
25 October 2026

​
Offline policy

  • Write your own limits for operations your devices accept without network: for each operation type and currency, a maximum per operation and, optionally, a cumulative amount, a number of operations or both per device since its last sync. There is no limit of time without network, and a policy never expires. Without a policy, nothing changes. See Offline policy.
  • wede checks every decision when the operations arrive and marks the ones that do not match, with the reason. It never refuses or delays an operation because of its decision.
  • New /v1/policies: the policy in use, versions that never change once saved, one in use at a time, and the decisions wede checked. New permissions policies:view and policies:manage, for administrators, technical staff and API keys.
  • In the dashboard, the new Offline policy page writes versions, tries an operation against them and shows the decisions that did not match.

​
SDKs 2.9.0

  • Every SDK fetches the offline policy after each sync with network, keeps it and applies it with no network. A refused operation is never queued: captureEvent throws WedePolicyDeclined with the rule. The option whenNoPolicy chooses what a device that never received the policy does. See Your limits without network.
  • No change is needed in your code. Without a policy in use, operations are captured as before, and earlier versions keep working.

​
Offline policy in the proof kit

  • The proof kit has a seventh check, Your offline policy: it passes when wede checked every decision your devices took with your policy in the window. Decisions that did not match are listed one by one as findings about your devices and never make the proof fail. The report carries offline_policy. See Proof kit.
  • POST /v1/policies accepts only operation types that are active in your catalog. A type that exists but is turned off returns 422 unknown_operation_type, now with inactive listing it.

​
Proof kit in the sandbox

  • Prove continuity with your own equipment: open a proof run in the sandbox, run your devices with your sandbox key (capture without network, out of order, a batch sent again, an altered message, your own records) and finish it. The report (wede-proof/1) says whether anything was lost, stored twice or accepted altered, check by check; a check you did not exercise is never reported as passed. It is sealed with the SHA-256 of its canonical JSON and never changes. See Proof kit and Proof runs.
  • In the dashboard, the new Proof kit page opens and finishes runs and shows the report, with the JSON to download.

​
Integrity incidents in the sandbox

  • An event sent with a sandbox key whose checksum does not match is still refused and recorded as an integrity incident, marked as sandbox, but no alert email is sent and no personal data incident is opened. Production is unchanged. See Integrity incidents.

​
Evidence packs by zone

  • Integrity incidents now carry the zone of their event. A pack for a zone holds the incidents of that zone and those without a zone, marked zone_code: null; never those of another zone. See Integrity incidents and zones.

​
Messages in English

  • Two error messages that were still in Portuguese are now in English: Missing X-Wede-API-Key header. and Token expired (offline tokens). The error codes are unchanged.

​
24 October 2026

​
Plans and the monthly invoice

  • Every plan now includes users, devices, zones, webhooks and data sources (empty means unlimited), production events per year and communications per year, and may have a fee per production event. wede can agree conditions of its own with your organisation for any plan. See Plans.
  • What goes above your plan never stops your operations and is charged apart, on one invoice a month: communications through wede above what the plan includes (since October 2026), each unit above the plan for each day it was above, production events above the yearly limit at a price per event, and the fee per production event when your plan has one (all three since November 2026). A month below 0.50 in your currency goes on the next invoice. The yearly licence is invoiced on its own, as before. See The monthly invoice.
  • Billing suggests the next plan by price when what was charged above your plan in the last month costs more than the monthly difference to that plan.
  • New GET /v1/tenant/plans: every plan offered to your organisation with your conditions. New GET /v1/tenant/monthly-invoices: your monthly invoices, line by line, and the upgrade suggestion.
  • GET /v1/tenant/billing: usage.overage_events is measured against the yearly limit agreed with your organisation, else the plan’s. usage.overage_amount_eur is deprecated and always 0; channel_costs carries your price with your discount (price_per_unit, country_price, discount_pct).

​
Parsers

  • A parser model always keeps one active version. The active version cannot be archived (DELETE /v1/parsers/{id}) or turned off (PATCH with is_active: false): both return 409 active_version_required. Make another version of the model active first; the previous one can then be archived. See Update a parser.

​
SDKs: minimum supported version

  • The minimum supported version of every SDK is 2.4.0. Older copies are refused on the routes only the SDKs use, with 403 sdk_version_unsupported. See Minimum supported version.

​
23 October 2026

​
How usage is counted

  • Every production event counts once toward your yearly allowance, when it is created, whether it is delivered or not.
  • Communications are counted the way the providers charge them, when they are sent: each SMS segment to each recipient, each started minute of a call, each satellite or LoRa message. Only what goes through a provider of wede is taken from your plan and charged. What goes through your own providers, and what your organisation receives, is counted and never charged. See What wede counts.
  • GET /v1/tenant/usage returns communications_year: each channel bought from wede with the units used and included this year. See Usage.

​
Communications above the plan

  • Communications through wede above what your plan includes are invoiced every month, from October 2026. What went above the plan before 1 October 2026 is never invoiced. GET /v1/tenant/communications returns invoiced per channel: units and amount already invoiced this year, and waived_units. See Communications.

​
Licence notices

  • The administrators of your organisation get an email 30, 7 and 1 days before your licence ends, when it ends and when it becomes inactive, each once. See Licence notices.

​
Teams

  • PATCH /v1/teams/{id} with zone_id: null removes the team from its home zone.

​
22 October 2026

​
Dispatch threshold

  • The default dispatch_threshold is now 0.70. Organisations that were still on the previous default 0.30 moved to 0.70; any other value you chose is unchanged. The threshold still never stops a dispatch: it only marks a mission below_threshold.
  • The dashboard offers three levels: 0.80 (strict), 0.70 (standard) and 0.55 (permissive). Any value from 0 to 1 can still be set with PATCH /v1/tenant/dispatch-settings.
  • GET /v1/tenant/me returns dispatch_threshold as a number instead of a decimal string. See Automatic dispatch.
  • reinforcement_timeout_min accepts a whole number from 0 to 60; a higher value returns 400 validation_error.

​
Teams

  • DELETE /v1/teams/:id deletes only a team that was never sent on a mission. A team with missions is kept as their history and the call returns 409 team_has_missions; set it unavailable instead.

​
SLA alerts

  • When WEBHOOK is an alert channel of the SLA of a vertical, wede sends sla.violated once per mission that passes the response target of its priority, and sla.uptime_below_target at most once a month when the availability of the API that month is below the uptime target. See Webhook events.
  • The alert channels of an SLA are EMAIL and WEBHOOK; push and voice were removed.

​
Usage

  • GET /v1/tenant/usage returns by_vertical, the production events of the period in each vertical (it was always empty). The included quantities in limits are the ones agreed with your organisation when they differ from the plan.

​
Privacy Policy and Terms of Service, version 2.0

  • The Privacy Policy now describes wede as processor for your organisation’s data and as controller for its own customer relationships, the retention periods per vertical, user deletion, incident notification under Article 33(2) GDPR, the full list of sub-processors and what the dashboard keeps in the browser.
  • The Terms of Service now describe what happens when a licence ends (the account is degraded, never switched off), that usage above the plan never stops the service, and the offline and channel commitments as they work today.
  • app.wede.pt/privacy and app.wede.pt/terms open these pages.
  • A one-off destination is kept encrypted with your organisation’s key while a delivery over the fallback channels runs, and removed when it ends. It is never kept with the event.

​
20 October 2026

​
SDKs 2.8.0

  • The SDKs send a field team’s reply by SMS for you when there is no data connection: on iPhone and on Android without the SMS permission they open the messaging app with the reply written, and on Android with the permission they send it with no tap. See Field teams’ replies by SMS.

​
17 October 2026

​
Reconciliation: decisions, daily closing, view by device

  • POST /v1/reconciliation/resolutions records what your organisation decided about an operation or a record that did not reconcile: accepted_as_captured, corrected_in_client_books, reversed, written_off, under_investigation or other (with a note). One, or up to 500 per request with one result per decision. The operation never changes; the history is kept and the latest decision counts. GET /v1/reconciliation/resolutions returns the history. Operations, records and the view show the latest decision, and operations can be filtered by resolution. See Your decisions.
  • POST /v1/reconciliation/sources/{source_id}/closes closes a day of a source with your totals per currency and direction, in your time zone; the day is closed or difference, with each difference. GET lists the latest closing of each day, what wede counts now and the days not closed yet. See Closing each day.
  • GET /v1/reconciliation/devices: each device with its operations by state, decisions and whether everything it sent has arrived.
  • New webhooks reconciliation.resolved and reconciliation.period_closed.
  • In the dashboard, Reconciliation has Resolve on every operation and record not confirmed, Daily closing and By device.

​
SDKs 2.7.0

  • Every SDK records decisions (one, or any number: 500 per request, in order), reads their history, closes days, reads closings and reads the view by device. No change is needed in your code. Earlier versions keep working.

​
SDKs 2.6.0: ledger and reconciliation

  • Every SDK can read the operation ledger and work with reconciliation: create and change sources, send your records, read the outcome of each record, the summary, the view by equipment and by day or hour, and the operations behind it. See Operation types and the ledger and Reconciliation.
  • Sending records takes any number of them: the SDK sends 500 per request, in order, and returns one outcome per record with the totals. A record already received is reported as duplicate_external and never counted twice, so sending again after an error is safe.
  • Android SDK on the JVM (outside Android): requests with PATCH now work. The JVM’s HttpURLConnection refuses that method, so they go through java.net.http. Android is unchanged.
  • No change is needed in your code. Earlier versions keep working.

​
Usage

  • GET /v1/tenant/usage also returns by_day, the events of each UTC day of the period (periods of up to 92 days), and year_to_date, the production events since 1 January (UTC), which is what the yearly allowance of your plan is measured against.

​
Deleting users

  • A company admin can now delete the accounts of their organisation. The account is blocked and every session ends at once; 30 days later the name, email and password are removed for good. Until then the deletion can be undone, and the account comes back suspended. Nobody can delete their own account or the emergency account of single sign-on.

​
16 October 2026

​
Evidence packs, format 2

  • New packs are wede-evidence/2: people and devices appear as codes of the pack (P1, D1), never as their ids. The key to the codes is kept by wede only, read only by the wede team and recorded in the audit log each time, and anonymised at the end of the evidence period. Packs in format 1 stay as they were signed. See Codes for people and devices.

​
15 October 2026

​
Continuity evidence packs

  • POST /v1/compliance/evidence produces a signed record of a time window of up to 92 days: every period offline or degraded and how long it lasted, who or what changed each state, every synchronisation that came afterwards with the result of each item, events by ingest channel and integrity incidents. No business content.
  • Packs are signed with ECDSA P-256 by a key held in a hardware security module. The public keys are published at GET /v1/evidence/public-keys, so an auditor can check a pack with openssl without wede. Packs can never be changed or removed. See Continuity evidence packs.
  • In the dashboard, Compliance has a new Evidence Packs tab to generate and download packs.

​
Continuity record

  • Every change of state of a zone or of the organisation now opens a period that is kept for good. Periods before 15 October 2026 were rebuilt from the audit log and are marked as reconstructed.
  • Every event records the channel it came through (api, sync, offline_dispatch, sms, satellite, lora, other), and every synchronisation records the result of each item, duplicates included.

​
Compliance report

  • offline_sync counts failed and blocked_integrity per day. GET /v1/compliance/report/export returns the report as a file directly, without a redirect.

​
14 October 2026

​
Single sign-on with SAML 2.0

  • Besides OpenID Connect, an organisation can now use SAML 2.0 for single sign-on, with its own Entity ID, reply address and metadata under https://api.wede.pt/v1/auth/sso/saml/<organisation id>. Assertions must be signed; up to 3 signing certificates, for rotation. Only sign-ins started by wede are accepted: a tile in your provider portal uses the Sign-on address. See Single sign-on.
  • Every single sign-on, OpenID Connect or SAML, now completes only in the browser tab where it started. A sign-in link opened in another browser is refused and recorded as browser_mismatch.

​
Provisioning with SCIM 2.0

  • Your directory can create accounts, change their role by group and suspend them at https://api.wede.pt/scim/v2, with a wscim_ token. See Provisioning (SCIM).

​
Security export to your SIEM

  • GET /v1/security-events?after=<n> returns the security record of your organisation in order, with a wsec_ token, and wede can also push it every minute to up to 3 https addresses, signed like webhooks. See Security export (SIEM).

​
13 October 2026

​
Single sign-on with OpenID Connect

  • An organisation can sign in to the dashboard through its own identity provider over OpenID Connect, with verified email domains, roles from groups and an option to require single sign-on for everyone except an emergency account. See Single sign-on.

​
SDKs 2.5.0

  • Every operation captured offline carries the identity of the device and its place in the device’s own numbering, sealed on the device. The device’s completeness appears on the Devices page like any other machine. See SDKs.
  • The device registers itself before it sends its first operations, so every operation is attributed to it from the start.
  • The event metadata types include the device and capture time fields, for integrations that send from their own hardware.
  • No change is needed in your code. Earlier versions keep working.

​
Mappings: connect equipment without code

  • A mapping says which field of the messages a device or system already sends fills each field of a wede operation. Messages are then sent as they are to POST /v1/ingest/{code}, as JSON or CSV (text/csv), up to 500 per request, with a result per message (accepted, duplicate, rejected with the field and the reason). Each message follows the same path as POST /v1/events. See Mappings.
  • Only the mapped fields enter wede. Mappings have versions that never change once saved; one is in use at a time. POST /v1/mappings/preview tries a mapping on sample messages without storing anything.
  • New permissions mappings:view and mappings:manage, for the organisation’s administrators, technical staff and integration keys.

​
Capture time on online events

  • POST /v1/events accepts an optional metadata.captured_at, the time the device captured the operation. It becomes the capture time of the operation, used to match your records by time.

​
Parser models

  • Every factory parser model now has a field for the equipment that captured the event (device_ref where there was none). It is not sent by SMS by default and not shown to field teams. Parsers you already have are unchanged.
  • The model for ATM and POS terminals has original_stan, to tie a reversal to its original operation. It is off the SMS by default, so the model still fits one SMS; you can turn it on in your parser.

​
12 October 2026

​
Proof that nothing is missing, per device

  • For each device that numbers what it sends, wede shows what arrived, what is missing and since when, what arrived late, duplicates refused, restarts of its counter and whether its record is intact. On the Devices page and with GET /v1/devices/{device_id}/completeness. See Devices.

​
Quantities and units

  • Operations and your records can carry a quantity and its unit as captured, never converted. Reconciliation matches by quantity in the same unit, with the new reasons quantity_mismatch and unit_mismatch. See Reconciliation.

​
Currencies

  • Amounts sent in decimal are converted with the decimals of their own currency (none for JPY, three for KWD), instead of always two.

​
Reconciliation and reversals

  • Your own records are matched against every operation wede carried, by type of equipment and by day or hour, with fixed outcomes and reasons and signed webhooks. A reversal is tied to the operation it reverses, whichever arrives first. See Reconciliation.

​
National phone numbers

  • Phone numbers sent to wede can now be written as a national number of your organisation’s country, with or without spaces, as well as in international form (+ or 00, then the country code and number). wede checks that a national number is valid for your country and stores it in international form. This applies to team device numbers and SMS recipients. A number that is neither valid for your country nor international returns 400 validation_error.
  • The one-off destination.phone of an event is unchanged and still takes the international form.

​
10 October 2026

​
What a field team sees

  • A field_operator session now receives an event (GET /v1/events/:event_id) with the payload reduced to the fields marked Show to team in the parser the event was written with; keys outside the parser never reach the team, and metadata is reduced to zone, location, parser reference and offline origin. The response carries payload_filtered: true, and filter_reason: no_parser when the vertical has no parser (then the payload is withheld until a parser is active). The other tenant roles are unchanged.
  • labels next to payload in GET /v1/events/:event_id and in the event.created webhook: the label of each parser field and, for enumerated fields, the label of the chosen option. The codes in payload never change.
  • Missions created by wede carry a snapshot of the Show to team fields in payload, with labels, so the team keeps the data while the mission lasts; it is cleared when the mission ends. GET /v1/missions/my and GET /v1/missions/:id also return event_teams: every team called to the same event with its role and state, never its members.
  • Payload retention: an event whose type sends a team keeps its payload until it is closed or its missions end, instead of losing it at delivery. Types that do not send a team are unchanged (cleared at delivery).
  • For an event sent over the API with several active parser models in its vertical, wede uses the model whose type field maps to the event type.
  • GET /v1/parsers items carry sms_size.segments_at_version_100 and sms_size.grows_at_version_100: from version 100 the version number takes one more character, so a model at the 95-byte limit will need a second SMS. The dashboard shows the warning on the model.

​
8 October 2026

​
One catalog per organisation

  • An event’s type is now always an active event type of your catalog for the event’s vertical. The wede categories (EMERGENCY, PAYMENT, BOOKING, STATUS_UPDATE, IDENTITY_CONFIRM, DISPATCH, OTHER) are no longer accepted as a type. Any other value returns 422 unknown_event_type, now with known_types listing the accepted codes.
  • The catalog is organised by vertical, category and event type. wede pre-loads a starting catalog for every vertical of your organisation; administrators keep what fits, add their own types, deactivate or delete the rest, and restore the defaults at any time. Types that already existed were kept, with their coverage.
  • Each type says whether it sends a field team (requires_teams), which equipment and qualifications resolve it (required_equipment, codes of your own equipment list) and its default priority. priority is now optional on POST /v1/events: without it, the type’s default applies (normal when it has none).
  • GET /v1/catalog returns the catalog with the team coverage of each type; GET /v1/catalog/equipment returns your equipment and qualifications. GET /v1/catalog/actions and GET /v1/event-categories are deprecated: the first still lists your types, the second returns an empty list. Both will be removed.
  • GET /v1/events items carry category (the code of your catalog category), category_name and requires_teams; dispatchable keeps the same value as requires_teams. The category filter takes a category code of your catalog; legacy_type=true lists open events sent before this change with a type that is not in your catalog. GET /v1/events/:event_id carries event_type_id and requires_teams.
  • POST /v1/events and the event.created webhook carry dispatch.status (queued, manual, not_dispatchable with reason: type_does_not_require_teams, off, sandbox); the webhook also carries category and requires_teams.
  • Each value of a parser’s type field points to a type of your catalog. A parser cannot be activated while one of its values points to a type that does not exist (422 parser_type_missing).

​
Dispatch by coverage

  • Only events whose type sends a team enter the dispatch queue (GET /v1/events?undispatched=true).
  • Teams cover a whole category or specific types (GET and PUT /v1/teams/:id/coverage). Candidates are the teams of the vertical that cover the event’s type (tier 1) or its category (tier 2); the others appear in excluded with reason: no_coverage. Tier 3 is always empty.
  • A team without members is never a candidate (excluded with reason: no_members); dispatching it by hand returns 409 team_has_no_members.
  • The equipment a type calls for counts in the score and is reported per team as missing_equipment; it never excludes a team. A manual dispatch of a team that does not cover the type or lacks equipment still happens, with warnings in the response and in the team.dispatched webhook.
  • POST /v1/teams/dispatch/score with event_id ranks by coverage (by_coverage: true, event_type, required_equipment, tier and missing_equipment per team).
  • A team’s equipment is chosen from your equipment list: POST /v1/teams/:id/equipment takes a code of that list (422 unknown_equipment otherwise). Team members carry user_id when linked to an account.
  • Automatic dispatch takes the best tier 1 team, or the best tier 2 team when none covers the type itself, and never waits for ideal conditions: a team below dispatch_threshold is dispatched and the mission is marked below_threshold.

​
SDKs 2.4.1

  • Live events (listLiveEvents), continuity state (getContinuity), reinforcement requests (list and fulfil), sandbox connectivity simulation, listEvents with category, undispatched and cursor pagination, and webhook signature verification in every SDK (verifyWebhookSignature, with signWebhookBody for tests). Available from Downloads in the dashboard.

​
7 October 2026

​
SDKs 2.4.0

  • The wede SDKs for JavaScript and TypeScript, React Native, Python, Swift and Android are now distributed privately to customers under agreement, from Downloads in the wede dashboard. See SDKs.
  • Offline layer with automatic synchronisation when the connection returns, messages to field teams when there is no data connection and their replies, device registration and removal.
  • Each download is a unique copy for your organisation.
  • The public 2.0.0 packages (npm, PyPI, GitHub and JitPack) have been withdrawn.

​
27 September 2026

​
Event status is the delivery status

  • An event becomes completed as soon as it is delivered: online (rest_full or rest_compressed), through any channel of your cascade, or reconciled from the store-and-forward queue. Events accepted by sync follow the same rule once delivered, and so do simulated deliveries in the sandbox.
  • pending now means only that the event is queued (queued_offline) or not delivered yet.
  • The stored payload is cleared whenever an event becomes completed, including online deliveries.
  • The event.delivered webhook now carries "status": "completed".
  • A mission outcome no longer changes the status of its event, and no longer sends event.status_changed. Follow missions with mission.status_updated.

​
Dispatch queue

  • GET /v1/events?undispatched=true returns the events without an active mission (no mission, or only missions that ended FAILED).

​
Core and optional module

  • The core that every integration uses is events, delivery through your channel cascade, offline capture and sync, and webhooks. Teams, dispatch and missions are an optional module for operational verticals such as emergency services, healthcare field teams, field services and delivery.

​
Zones

  • Reading zones needs zones:view, which the integration API key and every tenant role have. Creating, updating and deleting zones needs zones:manage (company_admin, company_tech, country_admin).
  • Creating a zone whose zone_code already exists returns 409 zone_code_taken.
  • On a zone shared with another tenant, you can change only its state and active verticals: changing name, region, the centre or boundary returns 403 shared_zone.
  • A connectivity_state change made with a sandbox key only affects the sandbox.
  • Connectivity reports and metadata.zone_id on events only resolve zones linked to your tenant. A report on another tenant’s zone returns 422 invalid_reference; an event with another tenant’s zone code is stored without a zone.

​
Rate limits

  • API key requests are limited per tenant and per minute (your tenant or plan limit, 500 by default).
  • Every API key response carries x-ratelimit-limit, x-ratelimit-remaining and x-ratelimit-reset. Above the limit, wede returns 429 rate_limited with Retry-After and the body fields limit and retry_after_seconds.

​
Tenant isolation for teams and missions

  • A team, member, event or mission of another tenant returns 404: not_found, or team_not_found / event_not_found on POST /v1/teams/dispatch, and team_not_found on POST /v1/missions.
  • POST /v1/teams/dispatch requires an existing production event of your tenant.

​
Mission lifecycle

  • A mission’s status only moves forward and can skip steps. FAILED can be set from any status that is not final; COMPLETED and FAILED are final. Any other change returns 409 invalid_transition.
  • Users with only missions:receive (field_operator) can update only missions of their own team (403 forbidden otherwise), and only their own member location.
  • GET /v1/missions/my returns the missions of every team the signed-in user is a member of (up to 50).
  • field_operator can now register and sync devices (sdk:access) and read zones (zones:view).

​
Substitution instead of reinforcement

  • When a mission is not acknowledged within reinforcement_timeout_min, wede sets it to FAILED with "feedback": { "reason": "no_acknowledgement" }, frees its team and dispatches the best free team not yet called for that event.
  • The new dispatch sends team.dispatched with substitution: true, mission_id, replaced_team_id and replaced_mission_id. The previous reinforcement and original_team_id fields are no longer sent.
  • If no team is free, the event returns to the dispatch queue.

​
Team ranking

  • Zone boundaries now count when wede ranks teams: a team whose zone boundary does not contain the event ranks lower. It is not excluded.

​
Usage beyond the allowance

  • A tenant is never suspended for exceeding its annual event allowance. Operations continue and the excess is reported as overage_events in the usage object of GET /v1/tenant/billing.
  • Usage alerts are sent when 50, 40, 30, 20, 10 and 0 percent of the allowance remains, each at most once per year.

​
Webhooks and browsers

  • Webhook URLs must use https; any other URL returns 400 invalid_payload.
  • The API accepts cross-origin requests from any origin. It authenticates only by headers, so the JavaScript SDK works in browsers with a session token. Never put an API key in a browser.

​
26 September 2026

​
SDKs 2.0.0

Four official SDKs, all at version 2.0.0, under new package names:
  • Session-token support: sign a user in with WedeClient.login and use the token in apps and browsers, where an API key must never be shipped.
  • Offline capture with checksum: captureEvent (capture_event in Python) records the capture time and the integrity checksum, and syncBatch sends up to 500 captured events at once.
  • 2.0.0 is a new major version. See SDKs for the current methods.

​
Event types

  • An event’s type is now either an active event type of your tenant’s catalog for the event’s vertical (for example cardiac_arrest) or an active wede category (EMERGENCY, PAYMENT, BOOKING, STATUS_UPDATE, IDENTITY_CONFIRM, DISPATCH, OTHER).
  • Each catalog event type is linked to a wede category, and every event stores its category when it is received.
  • GET /v1/event-categories lists the categories. GET /v1/catalog/actions lists your event types.
  • Any other type returns 422 unknown_event_type, online and in sync batches.

​
API key integration scope

  • An API key now authenticates as an integration credential that covers the full integration cycle: send, list and read events, sync, manage webhooks, read event types, read and report connectivity, and read billing.
  • Teams, dispatch, missions, users, API keys and catalog entries need a user session with the right role. See Authentication.

​
Sync

  • Events accepted in POST /v1/sync/batch now follow exactly the same delivery path as online events.
  • Each accepted event sends an event.created webhook with "origin": "sync", and every batch sends a sync.completed webhook with its summary.

​
Webhooks

  • Every subscribable webhook event now fires: event.created, event.status_changed, event.delivered, event.failed, sync.completed, device.synced, connectivity.degraded, connectivity.restored, the team.* events, mission.created and mission.status_updated.
  • Verifiable signatures: X-Wede-Signature: t=<unix seconds>,v1=<hex>, where v1 is the HMAC-SHA256 of <t>.<raw body> with the secret you set when creating the webhook.
  • Webhooks created before 26 September 2026 must be recreated to receive the new signature.
  • POST /v1/webhooks/:webhook_id/test now sends a real signed webhook.test delivery to your endpoint and returns the outcome: success, response_status, response_time_ms and error.

​
Sandbox

  • wede_test_ keys now work against a real sandbox. Events are stored with "environment": "sandbox", delivery is simulated with the same channel decision as production, nothing reaches a real recipient and nothing counts toward usage or billing.
  • POST /v1/sandbox/simulate-connectivity simulates a zone’s connectivity state for a limited time, in the sandbox only.

​
Events

  • GET /v1/events now paginates with a cursor: pass the next_cursor of one page as cursor to get the next. limit defaults to 50, maximum 200.

​
v1.2.0: 9 June 2026

​
Device sync

  • POST /v1/devices/register: register a device with a permanent device ID
  • POST /v1/devices/sync: sync a device’s dispatch queue, idempotent per device and sequence number
  • GET /v1/devices/:device_id/queue: pending queue of a device

​
Dispatch settings

  • PATCH /v1/tenant/dispatch-settings: configure automatic dispatch
    • dispatch_mode: turn automatic dispatch on or off
    • dispatch_threshold: minimum ranking for automatic dispatch, between 0 and 1
    • reinforcement_timeout_min: minutes before a backup team is dispatched when the first team has not acknowledged (0 turns it off)

​
Missions

  • Mission lifecycle: CREATED, SENT, ACK, ON_ROUTE, ON_SITE, then COMPLETED or FAILED
  • COMPLETED and FAILED close the originating event and return the team to available
  • Field operators can update mission status
  • Backup dispatch: send a different team to the same event with POST /v1/teams/dispatch and the same event_id

​
Dispatch

  • event_lat and event_lng are optional
  • requires_manual: true is returned when automatic dispatch is on and no team reaches the threshold
  • Automatic reinforcement when a mission is not acknowledged within reinforcement_timeout_min

​
SDKs 1.2

The previous SDK packages were updated with requestBackup and updateDispatchSettings, and a new Android SDK was added under the previous name wede-sdk-android.

​
v1.1.0: 27 May 2026

​
Teams and dispatch

  • GET /v1/teams: list teams
  • GET /v1/teams/:id: team detail
  • PATCH /v1/teams/:id/members/:memberId/location: update a member’s location
  • POST /v1/teams/dispatch/score: rank teams for an event
  • POST /v1/teams/dispatch: dispatch a team to an event

​
Missions

  • GET /v1/missions: list missions, filtered by team, status and limit
  • GET /v1/missions/:id: mission detail
  • PATCH /v1/missions/:id/status: update a mission’s status, with optional feedback

​
Billing

  • GET /v1/tenant/billing: current plan, annual usage and available plans

​
API key management

  • GET /v1/tenant/api-keys: list active API keys (prefix only)
  • POST /v1/tenant/api-keys/rotate: rotate an API key with a grace period during which the previous key stays valid

​
Security

  • Five consecutive failed sign-in attempts lock the account for 15 minutes
  • Session tokens are invalidated at once when a user is suspended or the session is revoked

​
SDKs 1.1

The previous SDK packages were updated with teams, dispatch, missions and billing methods. Previous names: @wede/sdk (JavaScript and TypeScript), wede-sdk (Python), @wede/react-native-sdk (React Native) and WedeSDK (Swift).

​
v1.0.0: May 2026

​
Core platform

  • POST /v1/events: submit events
  • GET /v1/events: list events
  • POST /v1/sync/batch: sync events captured offline
  • GET /v1/sync/status: sync totals for your tenant
  • GET /v1/connectivity/status: zone connectivity state
  • POST /v1/connectivity/report: report connectivity from a field device
  • GET /v1/tenant/zones: list zones
  • GET /v1/parsers: list parsers
  • GET /v1/tenant/me: tenant information
  • GET /v1/tenant/usage: usage by period
  • POST /v1/webhooks, GET /v1/webhooks, DELETE /v1/webhooks/:webhook_id: manage webhooks

​
Authentication

  • POST /v1/auth/login: sign in with email and password and receive a session token
  • POST /v1/auth/forgot-password: request a password reset
  • POST /v1/auth/reset-password: reset a password with a token
  • POST /v1/auth/change-password: change the password of the signed-in user
  • POST /v1/auth/verify: verify an account activation token

​
Security

  • Rate limiting per tenant

​
SDKs 1.0

First SDKs, under the previous names @wede/sdk (JavaScript and TypeScript), wede-sdk (Python), @wede/react-native-sdk (React Native) and WedeSDK (Swift).