Branding and mail

Routes are under <ADMIN_URL>/admin/<company>/api, need the role policy, and follow the change rules in The admin console.

Branding

GET branding reads the company's name, accent colour, support_url, privacy_url, when its logo was uploaded (Unix seconds), and the revision a change must name (0, with every value null, while none is set).

PUT branding with {"revision", "name", "accent", "support_url", "privacy_url", "reason"} replaces the brand whole, only over the revision read (409 changed_meanwhile otherwise):

PUT branding/logo with {"png", "reason"} takes a PNG as base64url, at most 256 KiB and 512 by 512 pixels, and keeps only the server's own re-encoding of its pixels, so nothing else in the file is ever served (logo_too_large, logo_not_png, logo_unreadable, logo_too_wide). POST branding/logo/remove takes it away.

The sign-in, consent and account pages read <issuer>/assets/brand.json and brand.css: the name is set as text, the colour replaces the house accent in the light theme, a link appears only when set, and the logo is <issuer>/assets/logo.png. With nothing set they show TessariDB's own. Every brand asset comes from the issuer's origin, so the pages' content policy is unchanged.

Mail

The server sends nine mails: reset, verify, email_confirm, email_taken, email_cancel, email_applied_old, email_applied_new, email_refused and signin_changed. Who gets a mail, and when, stays the server's decision whatever the wording says.

• GET mail lists each with the subject and text it goes out with, whether that wording is the company's own, the revision a change must name, the placeholders it may carry and those it is required to.
• PUT mail/<kind> with {"revision", "subject", "text", "reason"} keeps the company's own wording. It is plain text: a subject of 1 to 200 characters on one line, a text of 1 to 10 000 characters with no control character but a line break, {name} for a placeholder of that mail, {{ and }} for a brace.
• A mail that works by its link must keep {link}; the cancellation and the notice to the old address also name {new_address}; the sign-in notice keeps {change}. Anything else is refused as 400 template_rejected with the rule in the message.
• POST mail/<kind>/reset with {"revision", "reason"} goes back to the default.

The default is the region's: a node writes the wording the server ships with at start for every mail the region has none for, and never replaces one already kept. A stored wording that no longer passes its rules is skipped. The audit trail records each change with its reason, never the wording.

How mail is sent

A request only writes the mail, sealed under the key-encryption key, to a queue in the company's database. A background task sends what is due every five seconds, each send bounded to 20 seconds, tries a mail the relay did not take again after 30 seconds and then twice as long each time, and drops it after its sixth try as mail_abandoned. No address, subject or text is logged. The relay is set with SMTP_URL (see Running it).