> ## Documentation Index
> Fetch the complete documentation index at: https://docs.wede.pt/llms.txt
> Use this file to discover all available pages before exploring further.

# Notices to the person who made a request

> Tell whoever made a request when it is received, dispatched, on route and on site, by the best channel their app has, in your organisation's name.

When someone makes a request from your app (an emergency, an incident, a service request), wede tells them when its state changes. Your organisation writes the text, wede delivers it by the best channel the person's app has at that moment, and every notice goes out in your organisation's name. The name and domain of wede never appear.

## The four states

| State | When |
| - | - |
| `received` | wede accepted the request (online, by sync, by SMS or another degraded channel) |
| `dispatched` | A team was sent (a mission was created) |
| `on_route` | The team reported it is on its way |
| `on_site` | The team reported it arrived |

Your organisation writes one text per state, per event type, in its [catalog](https://docs.wede.pt/api-reference/event-types.md#notices-to-the-person-who-made-the-request): one line of up to 160 characters, with no personal or health data. A state without text sends nothing, so your organisation decides which states its people hear about. Each state is notified once per request.

## How the notice reaches the person

Each side is independent and uses the best channel it has. The person's app and your systems do not need to be online at the same time, and having no channel at all is a valid state: the notice waits.

**1. Internet**

The app reads its notices with [`GET /v1/devices/{device_id}/notices`](https://docs.wede.pt/api-reference/devices#notices-for-the-app-that-made-a-request) and confirms the ones it showed. Directly, through your server, or through your organisation's wede edge node, where the delivery is recorded as `edge`.

**2. SMS asked by the app**

Without data, the app sends an encrypted status request by SMS to your organisation's wede number. wede answers with one readable SMS per notice: your sender name, your text and a link to your app on your verified domain (`https://your-domain/<link code>u#...`) or, without it, a code your app reads. With no news, a short SMS says so. The notices the app already opened from an SMS are confirmed in its next status request. This path works only when your organisation turned on `sms_requester_status`.

**3. The queue**

With no channel at all, the notice waits for the app for 24 hours. Each new state makes a new notice.

Your systems receive every notice too, by the [`event.requester_update`](https://docs.wede.pt/api-reference/webhooks/events) webhook, with the request key, the app installation, the state and your text, never a phone number.

## What your developers do

The wede SDKs (2.11.0) do the work. In each SDK:

| Step | JavaScript, React Native, Swift, Android | Python |
| - | - | - |
| Register the app installation | `register()` | `register()` |
| Send each request from the device (the SDK adds its `device_id`) | `captureEvent(...)` | `capture_event(...)` |
| With network: read and confirm | `requesterNotices()`, `ackRequesterNotices(list)` | `requester_notices()`, `ack_requester_notices(lst)` |
| Without data: ask by SMS | `requesterStatusRequest()` then `sendSmsReply(...)` | `requester_status_request()` then `send_sms_reply(...)` |
| Read the answer (SMS text, link or code) | `openMessage(text)`: `kind` `U`, `state`, `request_key`, `text` | `open_message(text)` |

The app never shows the same notice twice: a notice opened from an SMS and listed again online is confirmed silently. For the link to open your app on iPhone, the iPhone file on your domain must cover the path `/<link code>u`; the file shown in the dashboard (Settings, Link in SMS) already includes it. Without it, the links for your teams keep working and these notices go out with the code. On Android the App Links file covers the whole domain.

## The person's number

wede does not keep the numbers of your end users. There is one exception, decided per organisation: when your organisation turns on **SMS notices to the people who make requests** (`sms_requester_status`, off by default, in Settings, SMS to teams), wede keeps:

* the number of a person who made a request by SMS or call;
* the number a person chose to share in your app, sent with the request as `requester: { phone, shared: true }`. Only when they chose it; never collected by default.

In both cases the number is used only to answer that person about that request. When their app did not get a notice over the internet within a minute, wede tells them by SMS (your text and the link) or by voice (your text, read twice), following your organisation's channel order. The number is:

* encrypted with your organisation's key;
* linked to that request only;
* removed when the request is completed or closed, with no other time limit, because a case can last more than a day;
* never stored with the event, and never in logs, webhooks, events, the audit log or exports.

Turning the switch off removes every number kept for your organisation at once. Each SMS and call counts towards your organisation's communications.

## What your organisation reviews before turning it on

The terms and privacy policy of your app are yours. Before turning on `sms_requester_status`, make sure they say:

* that sharing a number is optional, and what it is used for: to receive notices about the person's own request;
* that the person may receive SMS or a call about that request;
* that the number is kept only until the request is completed or closed;
* that wede processes it for you, under your data processing agreement with wede.

The texts in your catalog reach the person by SMS too: keep them free of personal or health data.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.