# Legacy v1 SMS

> The original send path. It still sends SMS, but new integrations should use v2.

`POST /v1/notification/send/` is the original send path. It still works
and still sends, through the same carrier SMS credentials and Beem
classification as v2, but new integrations should use
[Sending on v2](sending-v2).

```bash
curl -X POST https://nofy.encipher.co.tz/v1/notification/send/ \
  -H "Content-Type: application/json" \
  -d '{ "channel": "SMS",
        "title": "OTP",
        "message": "Your code is 481516",
        "receiver": "+255700000000",
        "tenant": "company-uuid-1" }'
```

Fields: `channel`, `title`, `message`, `sender`, `receiver`, `tenant`.
Without a token the send is **unattributed**: no quota, no tenant, and
since the legacy credential cleanup, no SMS is sent without a client. With
a token, `tenant` attributes the row to that tenant for quota counting.

## What actually dispatches

!!! danger "Only SMS dispatches on v1"
    `EMAIL` and `PUSH` rows are accepted and stored but never sent: a v1
    email row is an undispatched record, not a delivery. If you need Email
    or Push, use v2.

## Delivery state

`is_sent` is the whole signal, and it is only reliable in one direction:
`true` means the provider accepted the message; `false` means queued,
retrying *or* failed. The row's `delivery_reference` carries the provider
id on success, and `remarks` the reason on a permanent failure.

## Moving to v2

### Mint a client-credentials token
v2 always needs one. See [Authentication](authentication).
### Provision your tenants
`POST /v2/tenants` once per customer, with the same ids you pass as `tenant` today.
### Switch the send
Post to `/v2/messages` with an `Idempotency-Key`. The SMS shape is in
[Sending on v2](sending-v2#sms).