# E-mails and spend alerts

> What Wheelmachine e-mails - invitations, spend alerts, notices of the credit and security e-mails - how an alert differs from a limit, who gets them, and how to turn alerts off in one press.

We e-mail four things: invitations, spend alerts, credit notices and security e-mails. Each comes as plain text and HTML saying the same, and nothing in it tells us you opened it.

PUT /v1/usage/alerts:

```http
PUT /v1/usage/alerts HTTP/1.1
Authorization: Bearer ak_live_...
Content-Type: application/json

{"alert": 50}
```

## Invitations

An invitation to an e-mail address is e-mailed to it: who invites you, to which organisation, as what, and until when its link works. The link works once, for seven days, for that address alone, and the e-mail says so; if you did not expect it, ignore it - nothing happens unless you join. Whoever invites is shown the same link in the dashboard, to send another way, and the answer says whether it was e-mailed (`emailed`). An invitation to a GitHub login is not e-mailed. An organisation e-mails at most 100 invitations a day, and 5 to one address; past that, the link is given to send by hand. See [Invitations](https://docs.wheelmachine.ai/organisations.html#invitations).

## Spend alerts

An alert tells you, and stops nothing; a limit pauses machines. Each account may have an alert amount for the month, in its currency, set on the Usage & limits page or with `PUT /v1/usage/alerts` - in your own account by you, in an organisation by its owners and admins. You also get an alert at 50%, 75%, 90% and 100% of every limit for the month: the account's, each team's budget, and each person's own limit in an organisation ([Usage and limits](https://docs.wheelmachine.ai/limits.html#alerts)).

| Passed | Who gets it |
|---|---|
| The account's alert | In your own account, you; in an organisation, its owners, admins and billing |
| 50%, 75% and 90% of the account's limit | The same |
| The account's limit | The same - and its running machines are paused, everything in them kept |
| 50%, 75%, 90% and 100% of a team's budget | The organisation's owners, admins and billing, and the team's full managers |
| 50%, 75%, 90% and 100% of your own limit | You alone, in the organisation where it is yours |

Each is sent once a month: a new month starts them all again, and an alert or a limit moved is sent again when it is passed. If several pass at once, only the highest is sent. What passed this month is on the Usage & limits page, and in `GET /v1/usage/alerts` and `GET /v1/usage/limits`. The figures are those of `/v1/usage`, a minute or so behind the machines.

## Notices of the credit

The account's owners and billing - you, in your own account - are e-mailed:

- when credit is added, once Paddle confirms a purchase (Paddle e-mails the receipt);
- when the credit is running low - below 1 of its currency or a fifth of the latest purchase, whichever is more - and when it runs out, each once until the next purchase;
- when the credit has run out while the account's folders hold files: on that day, after 7 days and 9 days before the files are deleted, each with the exact time, the balance and how much credit brings it above zero ([Billing](https://docs.wheelmachine.ai/billing.html#when-it-runs-out));
- for an account made before billing began: the day it is first charged, at least 30 days before, and - should its balance be zero or below - a reminder three days before that day.

Each says its amounts in the account's currency.

These are notices about the account and its files, not alerts you choose, and cannot be turned off.

## Security e-mails

These are always sent, and cannot be turned off:

| When | Who gets it |
|---|---|
| Your account is signed in to from a browser it was not signed in from before | You - at most once a day for one browser, and ten times a day in all |
| A program signs in through the browser (`wm login`, an app) | You; if the key is an organisation's, its owners and admins too |
| A key is made | In your own account, you; in an organisation, its owners and admins - one by one, 25 a day; past that, the rest of the day's keys in one e-mail once the day is over (UTC) |
| Your own GitHub or GitLab link stops working | You - at most once a day for one link |
| An account's GitHub App is suspended or removed on GitHub, or its GitLab connection is no longer taken | In your own account, you; in an organisation, its owners and admins - at most once a day for one connection |
| Your account closes | You, once, at the address it had |
| You ask for a confirm code | You ([Confirm codes](https://docs.wheelmachine.ai/emails.html#confirm-codes)) |

A new sign-in's e-mail says which browser and system it was, when, and the IP address it came from. Your first sign-in to a new account sends nothing. A key's e-mail says who made it, what it may do and where - never the key itself.

A new sign-in's e-mail has a link that signs you out everywhere: every dashboard sign-in ends, and every program signed in through the browser loses its key. Keys made on the Keys page or by another key keep working: revoke any you do not know. The link works once, for 24 hours. If it was not you, change your GitHub or Google password first. See [the reference](https://docs.wheelmachine.ai/reference.html#signOutByLink).

## Confirm codes

These steps need a 6-digit code we e-mail you, as well as everything they always needed:

- closing your account ([Your account](https://docs.wheelmachine.ai/account.html#close-your-account));
- deleting an organisation, and transferring one to another owner - each its primary owner's alone - and making someone an owner, by their role or by an invitation, or sending an owner's invitation again ([Organisations](https://docs.wheelmachine.ai/organisations.html));
- making a key with full access (`cloud:*`), one that makes keys (`cloud:keys:write`) or one that gives machines secrets (`cloud:secrets:write`) - on the Keys page, with `wm keys create`, or with another key - and approving a program that asks for any of these as it signs in through the browser (`wm login`). A key that reads, or works machines, needs none.

The dashboard asks for the code where you do the step, and `wm` asks for it in the terminal. Through the API, the step is refused with `403 confirm_required`, and the error's `confirm` says what the code must be for. Send that to `POST /v1/confirm-codes`, and make the same call again with the code in `X-Confirm-Code`:

POST /v1/confirm-codes:

```http
POST /v1/confirm-codes HTTP/1.1
Authorization: Bearer ak_live_...
Content-Type: application/json

{"step": "full_access_key"}
```

A code is yours alone, for that one step. It works once, for 10 minutes, and five wrong tries spend it. A new code replaces any still waiting. If you did not ask for one, ignore it.

## Turning alerts off

Every spend alert says why you got it, and carries a link that turns spend alerts off in that account. Your mail program may show an Unsubscribe button beside it: one press there does the same, nothing to fill in. The link works for 60 days and does nothing else; the page it opens asks before it turns anything off, and can turn them back on.

Signed in, choose for each account on your Account page, under Spend alert e-mails, or with `PUT /v1/mail/preferences/{account_id}`. Invitations have no choice: one comes only when someone invites your address. Nor have notices of the credit, nor security e-mails.

## Addresses we stop writing to

When an address bounces for good, or its reader marks one of our e-mails as spam, we send it no more e-mail. The answer to an invitation says `emailed` all the same, so it never tells whoever invites anything of the address. We keep such an address only as a one-way code, from which it cannot be read back, and keep it when an account closes.