Account, concepts (Plan & API: billing, usage, API keys, webhooks)

The Admin nav group covers Plan & API (/account), the tenant’s self-service surface for billing visibility and programmatic access, so a tenant admin can run their own account without asking engineering to curl an endpoint on their behalf. Notification preferences and the audit log have dedicated pages (/notification-settings and /audit). This doc covers those related Admin concerns below.

Where you land after signing in, and the time range the app opens with, follow the persona set on your account. Pick a different time range once, and the app keeps your choice from then on.

What’s in this area

The five tabs above live on the single /account route, there’s no separate page per tab. The tab state is client-side. Two former tabs moved to their own pages and are covered by their own how-tos, not this page’s tab set:

Domain objects

API keys and the Excel/OData feed

An API key authenticates a request to Spall’s public API (/api/public/...) outside the browser session, for scripts, integrations, or Excel. Keys are created and revoked (DELETE /api_keys/{id}) from the API Keys tab. Mutating actions here are admin-gated on the server, so a non-admin sees a read-only view with create/revoke controls hidden.

A specific, named use of this: the OData feed (/api/public/odata/) lets Excel’s Data → Get Data → From OData Feed pull live Spall data directly into a spreadsheet. Excel’s OData connector can’t send a custom Authorization header, so this feed alone also accepts the key as a ?api_key= query parameter as a fallback, every other API surface expects the key in a header. This exists specifically so stakeholders who live in Excel get numbers without asking anyone to build them a report.

Webhooks

A webhook is a tenant-registered URL that receives outbound event deliveries (e.g. new alerts). Each webhook can be test-fired (POST /webhooks/{id}/test) to confirm the endpoint is reachable before relying on it, has a deliveries log, and can be deleted.

Two factor authentication (Security tab)

Two factor authentication adds a six digit code from an authenticator app (or a recovery code) to signing in, on top of your password. It is personal, per account, and self-service: anyone signed in can turn it on for themselves from the Security tab, whether or not their tenant requires it. Enrolling scans a QR code (or enter the code shown next to it by hand) with an authenticator app, then confirms with the current six digit code. Turning it on also generates ten recovery codes, shown once, each usable one time if you lose access to your authenticator app, save them somewhere safe. Once enabled, signing in becomes two steps: password, then the code. The Security tab also lets you regenerate recovery codes at any time (a fresh ten, the old ones stop working) and shows a warning once you are down to two or fewer. Turning two factor authentication off, or regenerating codes, asks for your password (disable only) and a current code or recovery code, first.

If you lose both your authenticator app and your recovery codes, you cannot self-serve back in. Your tenant admin, or Spall support, can reset two factor authentication on your account (Users page, or hello@spall.cc), the same effect as disabling it yourself, so you sign back in with just your password and can re-enroll when ready.

Admins additionally see a tenant wide Require MFA for admins setting. Off by default. When on, admin accounts on the tenant that have not yet enrolled see a reminder banner until they do, it is a prompt, not a lock out. Super admin accounts always require two factor authentication once they enroll, regardless of this setting. See How to set up two factor authentication.

Notification preferences (own page: /notification-settings)

Distinct from webhooks, notification preferences are personal (per signed-in user), not tenant-wide, and control which channels, email, SMS (needs a phone number on file), or push (needs the installed app on at least one device), an alert reaches that user through, plus a minimum severity floor and quiet hours. Webhooks are not one of these channels: a registered webhook is a tenant-wide, integration-scoped delivery, not a personal notification preference, so it has no per-user toggle here. This is the routing layer sitting on top of the alerts described in Now → Alerts: an alert exists tenant-wide the moment it fires. Notification preferences decide who personally gets pinged about it and how. Push is per device, not a single toggle, a user with a phone and a tablet both installed can enable each separately and tell them apart by name. An admin can also set up a teammate’s channels and severity floor on their behalf (for example, putting a new supervisor on downtime alerts), the affected person always sees who set it up for them and keeps full control, saving their own preferences hands it back to purely personal settings. See How to configure notification preferences and How to enable push notifications on your phone or tablet.

Audit log (own page: /audit)

A running, read-only record of admin actions on the tenant (who did what, when, actor_email shown, or an em-dash when the actor can’t be attributed). Its dedicated page shows the most recent 100 entries. There’s no mutating action here, it exists purely for accountability review. See How to review the audit log.

How the pieces relate

Plan & Usage and API Docs are read-mostly visibility surfaces on /account. API Keys and Webhooks are the two ways data or events leave Spall toward something else from that same page, a key toward Excel/a script, a webhook toward another system. Security is about who can sign in, not what leaves the account. Notification preferences (routing an alert to a person) and the Audit Log (accountability review) cover related but now-separate concerns and live on their own pages outside Account. All mutating controls on /account share one gate: a non-admin sees the same tabs but with create/revoke buttons hidden, and the server enforces the same restriction on its own.