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

# Sender identifiers

> Learn when from, instanceId, and other resource selectors accept a readable identifier instead of an internal ID.

## In a few words

* `from` accepts different values by channel: a phone number, address, @username, or resource name.
* When an ID or alias is supplied, the backend resolves it inside the API key workspace and enforces the key's resource restrictions.
* Prefer resource IDs in long-lived integrations; aliases can make configuration and payloads easier to read.

## What each channel accepts

| Channel / resource | Accepted values in `from` |
| - | - |
| WhatsApp — messages | Instance ID, line's E.164 phone number, or instance name. A sending pool ID or name is also accepted. |
| WhatsApp — presence and calls | Instance ID, E.164 phone number, or instance name. Pools do not apply to presence or calls. |
| Instagram | Instance ID, name, or connected account username, with or without `@` (for example, `shop` or `@shop`). |
| Telegram | Instance ID, name, or bot username, with or without `@` (for example, `alerts` or `@alerts_bot`). |
| RCS | Instance ID or branded agent name. |
| Push | App ID or name. `pushAppId` remains available on routes that expose this legacy field. |
| SMS and voice | Source number ID or an active E.164 phone number available to the workspace. |
| Email | Sender email address on a verified domain, optionally with a display name, such as `Support <help@example.com>`. This is not an instance ID. |

Each endpoint documents its own field. For example, WhatsApp presence accepts `from` and keeps `instanceId` as a legacy alias; the email send API expects an email address in `from`.

## Example: select Instagram by @username

Use the username of the connected Instagram account as the sender selector:

```json theme={null}
{
  "from": "@myshop",
  "to": ["17841400000000000"],
  "type": "text",
  "payload": { "text": "Hello!" }
}
```

`to` is still the recipient identifier required by the official API (IGSID). `@` only selects the sender account.

## If an alias does not identify one account

If duplicate names match more than one resource, the API returns `409 AMBIGUOUS_SENDER` and asks for the resource ID. An alias from another workspace can never select resources there: resolution is limited to the API key workspace. `instanceIds`, `pushAppIds`, and equivalent API key restrictions still apply after resolution.

The legacy `instanceId` field remains accepted by routes that declare it. On routes with `from`, that is the preferred field. Check the channel reference to confirm which aliases a specific operation accepts.


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