Security

Overview

wede carries operational events for regulated industries: healthcare, banking, emergency services and government. The platform is built on four principles:

Least privilege. Every credential and every role can do only what it needs.
Isolation. Each tenant sees only its own data, and wede staff never see event content.
Minimisation. wede keeps what it needs to prove delivery, not the content it delivered.
Evidence. Every relevant operation leaves an audit entry that nobody can change or delete.

API keys

API keys are the integration credential for your servers, sent in the x-wede-api-key header.

Two environments. wede_live_ keys work in production and wede_test_ keys work in the sandbox. A key only reads and writes data of its own environment, and sandbox events never reach a real provider or count toward billing.
Strong and hashed. Each key carries 128 random bits from a cryptographic generator. wede stores only a SHA-256 hash of the key and a short prefix to help you recognise it. The full key is shown once, when it is created, and cannot be retrieved later.
Server-side only. Never put an API key in a browser, a mobile app bundle or source control. Apps use a user session instead.
Limited scope. A key can send and read events, sync offline events, manage webhooks, read event types, read zones, read and report connectivity, and read billing. It cannot manage zones, teams, dispatch, missions, users, parsers or API keys, and it cannot read the audit log or the compliance report (403 forbidden).
Rejected when invalid. A key that is revoked, expired or past its rotation grace period, or that belongs to an inactive tenant, returns 401 unauthorized.
Rate limited per tenant. API key requests are limited per tenant and per minute (your tenant or plan limit, 500 by default). Responses carry x-ratelimit-limit, x-ratelimit-remaining and x-ratelimit-reset, and requests above the limit receive 429 rate_limited with Retry-After, so one runaway client cannot exhaust your integration.

Your tenant has one active key per environment. Create the first one with POST /v1/tenant/api-keys ({ "environment": "production" | "sandbox" }) and replace it with a rotation:

curl -X POST https://api.wede.pt/v1/tenant/api-keys/rotate \
  -H "Authorization: Bearer <session_token>" \
  -H "Content-Type: application/json" \
  -d '{ "environment": "production", "grace_hours": 24 }'

The response contains new_key. The previous key keeps working for grace_hours (default 24), so you can deploy the new key without downtime. Creating and rotating keys needs a session with the api_keys:manage permission.

User sessions

People sign in with POST /v1/auth/login and use the returned token as Authorization: Bearer <token>.

Passwords are stored as bcrypt hashes and must have at least 12 characters.
Sessions expire after 8 hours (expires_in: 28800).
Immediate revocation. Every session token carries the user’s token version. Suspending or reactivating a user increases that version, which invalidates all of the user’s open sessions at once, and a suspended user is rejected on every request without waiting for the token to expire.
Password reset links are valid for one hour, and the reset request returns the same answer whether or not the email exists, so it cannot be used to discover accounts.
Single sign-on. Your organisation can sign in through its own identity provider over OpenID Connect or SAML 2.0, with your own multi-factor authentication, and can require it for everyone except one emergency account. Every single sign-on completes only in the browser tab where it started. See Single sign-on.
Provisioning. Your directory can create, update and suspend accounts over SCIM 2.0. See Provisioning (SCIM).

Brute-force protection

After 5 consecutive failed sign-in attempts, the account is locked for 15 minutes. While locked, sign-in returns 429 with error: "account_locked" and locked_until. A successful sign-in resets the counter. Every failed attempt is recorded in the audit log and counted in the compliance report.

Transport security

The API is served over HTTPS only, and every response carries standard HTTP security headers. Webhook endpoints must use https too: a webhook with any other URL scheme is refused with 400 invalid_payload. The API accepts cross-origin requests from any origin. This is safe because wede authenticates only with the x-wede-api-key and Authorization headers and never with cookies: a browser never sends a wede credential on its own. Web apps call wede with the signed-in user’s session token; API keys stay on your servers.

Role-based access control

Every route checks the caller’s permissions before it does anything. A call without the required permission returns 403 forbidden.

Role	Scope
`wede_global_admin`	wede platform administration across tenants. Never sees event content
`wede_tech_ops`	wede technical operations. Never sees event content
`country_admin`	Administration of tenants in the assigned countries. Never sees event content
`company_admin`	Full administration of your tenant: users, API keys, webhooks, parsers, zones, teams, dispatch, missions, audit log, compliance report, billing
`company_tech`	Technical integration of your tenant: events, sync, parsers, zones, teams, missions, dispatch settings
`operational_supervisor`	Dispatch console: ranking and dispatching teams, missions, monitoring
`field_operator`	Missions of their own teams only (read and update status), their own location only, device registration and sync, viewing zones, reporting connectivity, syncing offline data
`corporate_client`	Events, dispatch and parsers for a corporate client account

API keys authenticate with their own integration scope, described above. Dispatching teams is a tenant operation: the wede and country roles cannot dispatch. Only administrators can change a user’s role, and only wede_global_admin can assign the wede and country roles.

Tenant isolation

Every tenant’s data is scoped to that tenant in every query. An API key or a tenant user session only ever reaches data of its own tenant: a resource of another tenant is answered as if it did not exist.

A team, team member, event or mission of another tenant returns 404: not_found, or team_not_found / event_not_found when you dispatch a team, and team_not_found when you create a mission.
A dispatch can only reference an existing production event of your own tenant.
Connectivity reports and metadata.zone_id on events only resolve zones linked to your tenant. A report for another tenant’s zone returns 422 invalid_reference; an event with another tenant’s zone code is stored without a zone.
A zone shared by several tenants keeps its common data (name, region, centre, boundary) protected: a tenant can change only its own state and active verticals on it (403 shared_zone otherwise), and cannot create a zone with a zone_code that already exists (409 zone_code_taken).
A field_operator acts only on missions of their own teams and on their own location (403 forbidden otherwise).

wede staff never see event content

wede operates the platform without access to what you send through it:

wede and country administrators never receive an event’s payload, metadata, your own event type or your catalog. They see only its vertical, priority, status, channel and timestamps.
They never see the content of audit entries, only the identifying fields.
They cannot read your parser schemas. The only parser action open to wede is locking or unlocking a field.

Payload minimisation

wede stores an event’s payload only as long as it needs it. For an event type that does not send a team, the stored payload is cleared ({}) once delivery is confirmed; for a type that sends a team, it is kept until the event is closed or its missions end, so the team keeps the data it needs, and then cleared. wede keeps the identifiers, category, channel and lifecycle as evidence of delivery. Whatever remains is removed or anonymised at the end of your retention periods (see Privacy Policy). The destination of an event (phone, email, device) is used for that delivery only. When the delivery goes through the fallback channels, it is kept encrypted with your organisation’s key while the delivery runs and removed when it ends. It is never kept with the event. For the strongest protection, encrypt sensitive fields in your payload before you send them. wede delivers the payload as you sent it.

Integrity of offline data

Events captured offline carry an integrity_hash, a SHA-256 checksum over the payload, the idempotency key and the capture time. When they are synced, wede recomputes the checksum for every event:

An event whose checksum does not match is rejected with integrity_check_failed. The other events of the batch are processed normally.
Each mismatch is recorded as an integrity incident, and your tenant administrators are alerted by email.
Incidents cannot be changed or deleted. Resolving one adds a separate resolution entry, so the original record stays intact.
The same idempotency key is never stored twice: repeated events are reported as duplicate.

The wede SDKs compute the checksum for you. Without an SDK, see Sync.

Webhook signatures

Every webhook delivery is signed with the secret you chose when you created the webhook. The X-Wede-Signature header has the form t=<unix seconds>,v1=<hex>, where the hex value is an HMAC-SHA256 of <t>.<raw body> with your secret. Verify it, and reject deliveries whose timestamp is too old, before you trust a webhook. wede keeps your webhook secret encrypted at rest (AES-256-GCM) so that it can sign each delivery.

Audit log

wede records mutating operations in an audit log: sign-ins and failed sign-ins, events, sync batches, webhooks and their deliveries, teams, dispatches, missions, parsers, users, dispatch settings, connectivity reports and integrity incidents. Each entry holds the tenant, the user (when there is one), the action, the resource type and ID, the timestamp, the IP address and the user agent. The audit log is immutable: database triggers reject any update or delete of an entry, whatever the application or role behind the request. Read it with GET /v1/audit (filters action, entity_type, entity_id, user_id, from, to, limit up to 500, offset) using a company_admin session. The compliance report summarises it by day, and the security export sends it to your SIEM, by pull with a cursor or by signed push.

Hosting and secrets

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. Secrets are kept in a managed secrets service, never in source code.

Compliance alignment

The tables below show how wede’s controls support the frameworks your organisation works under. Your own compliance depends on how you integrate and operate wede; wede gives you the controls and the evidence.

Banking and fintech: DORA

wede is designed to support financial entities that use it as an ICT third-party service provider under the EU Digital Operational Resilience Act.

DORA area	How wede supports it
ICT risk management	Multi-channel continuity, connectivity state per zone, `connectivity.degraded` and `connectivity.restored` webhooks
Incident handling	Immutable audit log, integrity incidents with alerts, event lifecycle, webhook notifications
Operational continuity	Offline capture with sync, store-and-forward and automatic channel cascade
Resilience testing	Sandbox environment with simulated connectivity per zone
Data integrity	SHA-256 checksum on offline events, idempotency on every event
Access control	Role-based access, single sign-on with your identity provider, SCIM provisioning, API key rotation, session revocation, brute-force lockout
Evidence	Daily compliance report with JSON export, security export to your SIEM

Healthcare: HIPAA

wede’s controls are aligned with the HIPAA Technical Safeguards (45 CFR § 164.312).

Safeguard	How wede supports it
Access control, § 164.312(a)	Unique user accounts, role-based access, automatic session expiry
Audit controls, § 164.312(b)	Immutable audit log of operations and sign-ins
Integrity, § 164.312(c)	SHA-256 checksum on offline events, idempotency, integrity incidents
Person or entity authentication, § 164.312(d)	Single sign-on with your identity provider and its multi-factor authentication, bcrypt-hashed passwords, token versioning, brute-force lockout, hashed API keys
Transmission security, § 164.312(e)	HTTPS for all API traffic, signed webhooks

Payload minimisation limits how long health data stays on wede, and wede staff never see event content.

Banking in the UAE: CBUAE

For licensed financial institutions in the UAE, wede is designed to support the business continuity and technology risk expectations of the Central Bank of the UAE.

Area	How wede supports it
Business continuity	Offline capture and sync, so critical operations continue without internet
Disaster recovery	Automatic channel cascade across REST, SMS, voice, satellite, LoRa and edge
Operational risk reporting	Immutable, timestamped audit log and daily compliance report
Technology risk	Integrity checksums, role-based access, hashed credentials
Data residency	Dedicated regional instance available by agreement where in-country residency is required

Government and critical infrastructure: NIS2

NIS2 area	How wede supports it
Risk management	Connectivity state per zone with webhooks on every change
Incident handling	Integrity incidents with alerts, immutable audit log, compliance report
Business continuity	Offline capture, sync on reconnection, multi-channel delivery
Access control	Role-based access, single sign-on, SCIM provisioning, session revocation, API key rotation
Cryptography	HTTPS, SHA-256 checksums, bcrypt passwords, HMAC-SHA256 webhook signatures, encrypted webhook secrets
Data residency	EU by default, dedicated regional instance available by agreement where required

Your responsibilities

Multi-factor authentication. wede applies the multi-factor authentication of your identity provider when you use single sign-on; turn on Require single sign-on so that nobody signs in with a password alone. wede does not provide MFA for the end users of your own apps: enforce it in your own identity layer where you need it.
Key custody. Keep API keys and webhook secrets in your own secrets store and rotate them when people leave or a key may be exposed.
Payload content. Send only the data the operation needs, and encrypt sensitive fields before sending.
Your integration. Test and secure your own systems and the way they call wede.

Security contact

To report a vulnerability or ask a security question, write to security@wede.pt.

Introduction

Core Concepts

Examples by Vertical

Overview

API keys

User sessions

Brute-force protection

Transport security

Role-based access control

Tenant isolation

wede staff never see event content

Payload minimisation

Integrity of offline data

Webhook signatures

Audit log

Hosting and secrets

Compliance alignment

Banking and fintech: DORA

Healthcare: HIPAA

Banking in the UAE: CBUAE

Government and critical infrastructure: NIS2

Your responsibilities

Security contact

​Overview

​API keys

​User sessions

​Brute-force protection

​Transport security

​Role-based access control

​Tenant isolation

​wede staff never see event content

​Payload minimisation

​Integrity of offline data

​Webhook signatures

​Audit log

​Hosting and secrets

​Compliance alignment

​Banking and fintech: DORA

​Healthcare: HIPAA

​Banking in the UAE: CBUAE

​Government and critical infrastructure: NIS2

​Your responsibilities

​Security contact

Overview

API keys

User sessions

Brute-force protection

Transport security

Role-based access control

Tenant isolation

wede staff never see event content

Payload minimisation

Integrity of offline data

Webhook signatures

Audit log

Hosting and secrets

Compliance alignment

Banking and fintech: DORA

Healthcare: HIPAA

Banking in the UAE: CBUAE

Government and critical infrastructure: NIS2

Your responsibilities

Security contact