Short guides to the things operators do every day.
GuidesShort walkthroughs of the work that comes after setup, from answering a customer who cannot sign in to sending your own emails and deciding who can sign up at all. Most run about a minute, and each is written out in full beside the video. For setting up your first Application, watch the walkthrough.
Help a customer from the panel
Someone writes in and cannot sign in. Find them by email, read their account, and fix it without asking them for a password or running a query by hand.
Find the person
Every Application keeps its own list of end users. Search it by email address.
Read the account
One page carries the whole account, split into tabs: overview, subscriptions, devices, credits, security, and data.
Support actions
Clear an account lockout, resend verification, send a password reset, reset devices, or sign them out everywhere. Each one is recorded in the activity trail with your operator id.
Subscriptions and devices
What they pay for and when it renews, then the devices their sessions are bound to. Releasing a device ends that session.
Security history
Every security event on the account, including sign-ins that failed, so you can tell a lockout from a forgotten password.
Give a teammate less than everything
A support contractor needs to read end users and nothing else. Operator permissions restrict a workspace member area by area, and the panel stops rendering what they cannot use.
Invite as a member
Scopes apply to the MEMBER role. Owners and admins are not restricted by them.
Restrict area by area
End users, billing, sign-in configuration, developer, organizations, activity and overview each take none, read, or read and write.
Save
The panel does not grey out what a member cannot reach. It does not build those tabs at all, and the API refuses the calls behind them.
Decide which emails Rekey sends, and who they come from
Rekey sends verification, reset, magic-link and welcome email for you. Set the name and addresses that mail carries, switch it off for one Application or one email at a time, and read the log of what went out.
Settings shows the transport
The top card names what carries this Application's mail: your own Resend or SMTP, the shared pool, or nothing yet.
Sender
Set a from name and a Reply-To address. On the shared pool the name gets a "(via ...)" suffix naming the pool, because the address is the pool's. The support address goes in the "Need help?" footer of the built-in emails and is never a mail header. Saving transport credentials leaves these alone.
One switch for every end-user email
Turning email off is per Application, so a test Application can go quiet while production keeps sending. Workspace mail, such as operator invitations, is not affected.
Or one email at a time
Templates lists the built-in emails; open one to change what it says. Welcome and the dunning reminder each have their own switch. Verification, magic link and password reset have one too, until a live sign-in method depends on the email, and then the row says so rather than offering a control. Two are never switchable here: workspace invitations and the operator unapplied-payment notice go out through a path this Application does not gate.
Custom templates
Emails you write yourself and send from your backend by key. They have their own guide below.
Delivery
Every send is recorded with its recipient, subject, transport and status, so you can show a customer what was sent to them and when. Message bodies are not stored.
Send your own emails by key
Write a transactional email in the panel, preview it, send yourself a test and publish it. Your backend then sends it with one call that carries only the key, the address and the values.
Your own Resend or SMTP
Custom templates only go out through the Application's own Resend or SMTP, never the shared pool. You can write drafts before the provider is connected; publishing and sending wait for it.
Key, subject and variables
The key is permanent and is what your backend sends by, such as export_ready. Declare every variable the backend will pass, with a sample value for previews. A send with an undeclared or missing required variable is refused with EMAIL_VARIABLES_INVALID, and nothing goes out.
A draft, written in the editor
A new template starts as a draft and cannot be sent. Build the body in the editor, where your declared variables are the merge tags.
Preview and test
The preview renders the draft with each sample value and sends nothing. Send test to me mails the draft to your own address through the Application's provider, and counts toward the send limits.
Publish
Publishing snapshots the draft as the next version. Sends only ever use a published version, so editing the draft changes nothing until you publish again. A send can pin an older version.
Send from your backend
Call rekey.email.send() from @rekey.dev/node, or POST /api/v1/email/send, with the template key, the recipient, the variables and an idempotency key. The call never carries a subject or HTML, and it needs a secret key with the email:send scope.
Choose which addresses can sign up
Limit self sign-up to the domains you choose, refuse the ones you do not want, and turn away disposable inboxes, all from the Auth page.
Allowed domains
One per line. When the list has any entries, only those domains can sign up. Leave it empty to allow every domain.
Blocked domains
Same matching. A blocked domain wins over an allowed one. acme.com matches that domain only, and *.acme.com matches its subdomains, so list both to cover both. Up to 500 entries in each list.
Disposable inboxes
One switch refuses throwaway-inbox services such as mailinator.com, using a list that ships with Rekey and updates with each release.
What a refused person sees
Self sign-up from a refused address answers 403 SIGNUP_EMAIL_DOMAIN_NOT_ALLOWED, never the list itself. A magic-link request for a refused address answers as if it sent, so the rules cannot be probed.
Who is not checked
People who already have an account keep signing in. Users you create or import from the panel or the API skip the rules.
Welcome new users at the right moment
Choose when the welcome email goes out, then subscribe your backend to the lifecycle events that start your own onboarding: new users, first sign-ins, accepted invitations and trials.
When the welcome email goes out
On sign-up sends it as the account is created, except that while Require a verified email is on, an unverified address gets it once confirmed. After email verification always waits for a confirmed address. Never turns it off.
Addresses that are already proven
With either timing, magic-link sign-ups, and OAuth sign-ups whose provider vouches for the address, get the welcome straight away. Users you create or import never get one.
A webhook endpoint
Add an endpoint on the Webhooks tab and pick its events, or subscribe to all of them. Each delivery is signed with HMAC-SHA256 in the X-Rekey-Signature header.
The lifecycle events
user.created for a new account, session.created for each real sign-in, organization.invitation.created and organization.invitation.accepted, subscription.trial_started, and subscription.trial_will_end three days before a trial ends.
The first sign-in
session.created carries firstSignIn, true only for the first session a person ever gets. It is never sent for a token refresh or an organization switch, so it is a clean trigger for onboarding.
Where to go next
Everything on screen is sample data. The names and addresses belong to nobody.
If you would rather read than watch, the same ground is covered step by step on the blog, and the documentation has the API behind each one.