E-mails and spend alerts

Copy page

Copy pageView as MarkdownOpen in ClaudeOpen in ChatGPT

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/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.

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).

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);
• 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:

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.

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);
• 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);
• 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/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.