My Account

My Account at https://rotorlab.app/account is your self-service page: profile details, your preferred start page and units, your organization's settings (if you administer your organization), the subscription and billing (if you administer it or your role holds Billing), API keys and credits, add-ons, and account security. A sidebar on the left shows your name, email, and role, and switches between its sections. An organization admin has six: Account, Organization, Billing & plan, API & credits, Add-ons, and Security. A member has no Organization section, and has Billing & plan only when their role holds Billing. The page remembers which section you last used and reopens it next time; a remembered section you no longer have opens Account instead.

This page covers the Account, Organization and Security sections in full. Billing, add-ons, and API access have their own pages: see Plans, add-ons, and billing and API keys and credits.

Profile#

The Profile card holds your personal details:

• Name: editable. Press Save profile to store it.
• Email: read-only. Your email is your sign-in identity.
• Role: read-only. Your tier or role by name, for example "Organization admin", "Pilot" or "Member", set by an organization admin.
• Organization: read-only. The name of the organization your account belongs to.

Start page#

The Start page card sets the page RotorLab opens when you sign in or click the logo. The preference applies to your account only and does not affect anyone else in your organization.

Pick a page from the dropdown (choices are grouped the same way as the main navigation, and list only the pages your role opens) and press Save start page. Leaving the dropdown on Default uses your organization's start page when an admin has set one your role opens, and RotorLab's default start page otherwise; the default it uses is named in the option, and the card notes "Currently using the default." when no choice is saved.

An organization admin also sees a second picker under the card: the page a member lands on until they choose their own, for example the logbook for a one-person operator or the Builder for a class. Pick a page, or RotorLab default, and press Save for the organization. A member whose role does not open that page lands on RotorLab's default instead.

Units#

The Units card sets the units RotorLab shows distances, heights, speeds, masses and temperatures in, on forms, pages and the documents you download. Each quantity has its own picker:

A quantity left on Organization follows the organization's choice, which the option names. Press Save my units; your choice applies to you only. An organization admin also sets the organization's units below and presses Save for the organization: these are what everyone reads until they choose their own, and what every document prints in, the crash report and the Builder's reports included. Before anyone chooses, an organization flying under the United States regime reads ft, mph, lb and °F, and every other organization reads m, km/h, kg and °C. What is stored does not change: records keep their figures in metric, and a figure you leave untouched on a form is saved exactly as it was.

Units apply to the flight form's maximum height and distance and the aircraft's take-off mass; to the Builder, the Setup Wizard, Balance and CG, the Throttle Simulator and its mission legs; to the Mission Planner, the Airspace Viewer and RF Link and Range; to the Crash Analyzer, the Log Analyzer and the 3D flight replay; to a battery's own page and the pack temperatures on the Aircraft board; and to the rate, area and wind speed of a spray service record. Where these pages take a figure, you type it in your units too, and the unit is named beside the box. A reader on pounds reads a small mass in ounces (below 2 lb) and a larger one in pounds.

Your screens read in your own units: the findings the Crash Analyzer writes, on its page and on a flight's page, read in your units, as do the Log Analyzer's warnings and the observed weather on a flight in the Logbook (visibility and the altimeter setting stay as the station published them). So do the crash reason on a File Flights row and in the crash email. An airprox occurrence started from the Crash Analyzer is written in your organization's units, whoever starts it. Documents print in your organization's units, not your own, so two people in the organization who chose different units download the same document: the crash report and its PDF, the Builder's performance report and its PDF, the weather lines on job records and occurrence reports, the spray lines on the job record, the design and area dossiers and the airspace screening report. A document with no organization behind it prints as recorded: the model's and the log's figures in metric, and FAA and weather figures in their published feet.

Some figures keep one unit for everyone: prop diameter, pitch and clearance in inches, a wire's cross-section in mm² (AWG is the other choice), and figures a rule states, such as the Part 77 surface dimensions or the 55 lb weight line, in the rule's own units. Exported .plan files keep the units ground stations read, and the Airspace Viewer's KML and shapefile keep the FAA's feet.

Notices about your logs#

The Notices about your logs card turns one kind of notice on or off for you. A notice is a small message at the bottom left of the page you are on, also listed in the bell at the top of the page until you dismiss it. You get one when a log you sent to an analyzer has been read, when a log you filed has been read, could not be read or was too large to read automatically, and when logs you dropped on File Flights are ready to review. Organization admins also hear when a log from a ground station or the API could not be read or was too large to read automatically. Several close together come as one notice.

Tick or untick Show me these notices; the choice is saved at once and applies to you only. It is on until you turn it off. These notices are shown in RotorLab only and are never emailed.

Your data#

The Your data card, at the foot of the Account section, downloads everything RotorLab holds about you as one zip. It holds your account and sessions (never a secret), your API keys' names and dates, your personal settings, your pilot profile, credentials and every version of them, your currency and training, the evaluator roster entries that name you, the flights you flew and their history, your flights in the void ledger, the occurrences you reported or that name you, the maintenance you performed, inspected or released, your maintenance authorizations, the work orders and sorties that name you, your crew seats and duty periods, the documents you signed off, your own saved builds and missions (names and dates), your rows of the activity log, the security log rows about you, your notices about your logs, and your recent analyses. A manifest.json lists every file with its size and SHA-256.

• Press Download my data for the records alone.
• Press With attached documents to add the documents attached to your credentials and training records.

A colleague's records are not in it. An occurrence a colleague filed about one of your flights is listed by its reference and status only, and its full report is included only when your role reads occurrence reports. Each download is noted in your organization's activity log. An organization admin can also export everything about one member from the Users list; see Managing users.

Organization#

Organization admins see the Organization section: every setting that applies to the whole organization, in one place. It opens with Your organization's settings, an index with one row per subject (People, roles and groups, Sign-in and security, Where you operate, Notifications and email, Data and retention, Currency rules, Integrations, Start page and units, Plan, billing and add-ons). A link to a card on this section scrolls to it; a link to something kept elsewhere opens it there: Users, Roles, Groups and Email / SMTP in the Admin Console, the Retention page, the Audit page, the Pilot Logbook's Team tab, and the API & credits, Billing & plan and Add-ons sections. The cards follow, grouped under the same headings, and the next sections of this page describe them. A link to https://rotorlab.app/account#data opens the section at the organization export.

Operating jurisdictions#

Organization admins see the Operating jurisdictions card in the Organization section, under Where you operate. The picker sets where the organization flies from, which decides the details your flight, aircraft and pilot records prompt for and the wording they use. It does not decide what you are required to record, every field stays available whichever you pick, and changing it never alters a record already made. Choose and press Save. Under Also operating in, tick anywhere else you fly: each flight then records which of these it was flown under and asks for that country's details, the class-mark list on the aircraft register carries every ticked regime's marks, and the Builder's weight-class note carries a line for each. The first step of the setup guide, Say where you fly from, opens this card.

The same choice decides what RotorLab offers you from its shipped content. A new operations manual starts from the outline for your primary jurisdiction, and only outlines and shipped sections written for a country you operate in, or for no country, are offered; ticking a country under Also operating in brings its outline and sections into the list. The checklist library offers only cards written for where you fly, the occurrence determination sheet offers the categories of the country an occurrence happened under, and Install starter program on Training Programs adds the roles of every country you operate in, primary first.

Under Operator registration on the same card, record your organization's own registration as an operator where your regulator issues one: an EU operator registration number, a UK Operator ID, a CAAS operator ID. Type the Registration number (up to 80 characters) and Registered with (up to 120) and press Save. It is held once, on the organization, rather than on each aircraft, and nothing checks it against a register. Leave both empty if you hold none; saving both empty clears it.

How you fly in the United States#

Where your organization flies in the United States (its primary jurisdiction or one it also operates in), the same card asks How you fly in the United States: Civil operations under 14 CFR Part 107, the default, or Public aircraft and military operations. Part 107 covers civil small unmanned aircraft; a public aircraft or military organization flies under its own unit rules. Choose Public aircraft and military operations and press Save, and then:

• a new US flight starts with the operating category of a public aircraft operation;
• the flight form does not ask for a LAANC authorization or an airspace authorization reference first;
• a pilot is held to the Part 107 recurrent training rule (14 CFR 107.65) only after flying a flight recorded under a Part 107 category, and a US flight with no category recorded counts as your unit's own;
• each aircraft's page carries the Army flight records card, with the DA Form 2408-12 and DA Form 7752 entries read from your records, and each crew duty on the logbook's Team tab takes an Army duty symbol.

Every field stays available, and no record you have made changes. The credential list also offers System qualification (the aircraft system) and Evaluation (proficiency or standardization) for any US organization, and your unit's own currency rules can be added on the logbook's Team tab. The choice is recorded in your organization's activity log.

Time zone#

Organization admins see the Time zone card in the Organization section, under Operating jurisdictions. It sets the zone your organization keeps its records in, and everyone in the organization reads times in it: every date and time on screens, in PDFs, in emails and in exports is shown in this zone and says which zone it is (for example "2026-09-27 04:24 CDT"). The calendar follows it too: "today", authorization and certificate expiries, due dates, currency and recency windows, the occurrence filing clocks, and the Ops Dashboard periods all count your organization's days, not UTC's. A time typed with no zone, such as a flight's time in the Pilot Logbook, is read as this zone's.

When your organization is set up, RotorLab infers the zone from your billing address, or from the country you fly in when no address is on file, wherever that names one clock: Iowa, Alberta, Queensland, Germany or Japan each have one. Where the address could mean more than one zone (Texas, Ontario, New South Wales, New Zealand, Brazil), or there is no address yet, the zone is UTC until you choose. The card says which happened. Until an admin confirms the zone, every admin sees a reminder at the foot of each page with Review time zone, which opens this card; Later hides it for the rest of the browser session.

Pick the zone from the list and press Save. When the list already shows the zone the card inferred, the button reads Confirm. Use this device's zone appears when the device you are on is set to a different zone, and fills the list with it; nothing changes until you press Save.

Changing the zone never alters a record. Times are stored in UTC, and a time someone typed keeps the zone it was typed in, so a flight entered as 19:30 in Chicago still reads 19:30 CDT after the organization moves to another zone. A flight entered before time zones were recorded reads "(no zone recorded)" beside its time.

Sign-in and security#

These cards are in the Organization section, under Sign-in and security.

Require two-factor for your organization#

The Require two-factor for your organization card enforces two-factor for everyone in the organization. Tick Require two-factor authentication, set the Grace period in days (0 to 365, default 14), choose the Second factor, and press Save:

• An authenticator app or a security key (the default): either meets the rule.
• Security keys and passkeys only: only a hardware security key or a passkey meets it. You can choose it only once you hold a key yourself, so you cannot lock yourself out. A member who holds only an authenticator app gets the full grace period from the moment you switch to add a key; past it they can only add one or sign out. A member who holds a key signs in with it, or with a recovery code if it is lost, and not with an app code.

People who join later get the same grace period from their own start date. Until the deadline, anyone without two-factor sees a prompt. After it, they can only set up two-factor or sign out until they do, and their personal API keys are refused until two-factor is on.

Organization admins need two-factor whether or not this card is on. Each organization admin has 14 days to set it up, counted from the day they became an admin; demoting and promoting someone again, or disabling and enabling their account, does not start the 14 days over. When the organization's own rule gives an earlier deadline, the earlier one applies.

Sessions and sign-in#

The Sessions and sign-in card sets, for everyone in the organization, the Session length in hours (1 to 2,160; 14 days by default), the Idle timeout in minutes (0 for none, up to 1,440; 12 hours when you have never set it), the SSO re-check period in hours, and Require SSO (refuse passwords for members). Press Save. A shorter session length or idle timeout applies to sessions already open: a session that has run past the new limit ends on its next request. See Accounts for what each does.

Apply government settings sets everything a public body usually asks for in one step, after you confirm: sessions of 12 hours, an idle timeout of 15 minutes, two-factor required for everyone with no grace period (anyone without a second factor, you included, sets one up at their next page), Require SSO when your single sign-on is on, and builds kept out of the public community. Sessions already open that run past the new limits end on their next request. Each value can be changed afterwards on its own card. Applying it is a security row in the activity log.

Publishing builds to the public community#

The Publishing builds to the public community card says who in your organization may publish a build to the public community, where anyone can view and fork it. Choose Who may publish: Any member, Organization admins only, or Nobody: builds stay inside the organization, and press Save. Builds already published stay published; the rule governs what is published from then on. Questions and answers in the community are not covered. An organization that is a public body starts at Nobody until an admin chooses otherwise; every other organization starts at Any member. See Community.

Your email domain#

The Your email domain card confirms the domain your colleagues' addresses use. Single sign-on needs it. Type the domain, pick the administrative address at it to send to, and press Send confirmation; the link emailed there confirms the domain. It has to be a standard administrative address that only somebody who runs the domain can read, so you cannot nominate your own.

A confirmed domain lists your organization to people who sign up with an address at it only when you choose so under the Admin Console's Join requests: Require my approval lists it and sends each request to you, and Let them join automatically lets them in. Until you choose, your organization is not listed to anyone. See Managing your organization.

Single sign-on#

The Single sign-on (OIDC) card lets your identity provider (Google Workspace, Microsoft Entra, Okta, or any OpenID Connect provider) sign your people in. It only ever signs in addresses under your confirmed email domain. Enter the Issuer URL, Client ID and Client secret, register the redirect URI the card shows with your provider, press Save, then Turn on. The secret is stored and never shown again; leaving the field empty on a later save keeps it.

By default single sign-on signs in only people already added to your organization. Two options change that:

• Add people on their first sign-in: anyone your provider signs in under your confirmed domain gets a member account on their first sign-in, inside your plan's user limit. A sign-in past the limit is refused with the reason.
• Groups claim and Group to role: the claim your provider sends the person's groups in (groups when left empty), and one line per group, the group's name as your provider sends it, an equals sign, then a role by its name on the Roles page, for example Drone Pilots = Pilot. At each sign-in a member takes the role of the first listed group they belong to; with no match their role stays as it is. Deleting a role removes its line.

Single sign-on never makes anybody an organization admin, and never changes an organization admin's tier. Every account it adds and every role it sets is a row in the activity log. If your provider enforces two-factor, you can leave RotorLab's own two-factor requirement off.

Notifications#

The Notifications card is in the Organization section, under Notifications. Messages are delivered to your administrators, not to RotorLab. If notification email is not available yet, the card says so; your settings are still saved and apply once it is. Press Save notification settings to apply everything on the card.

Event emails (an aircraft grounded by a new work order, urgent work, a crash in a filed log, a component at a life limit, an insurance policy running out, an occurrence open past its review point, the operations manual due for review, a manufacturer you link to revising a type's maintenance items (ICA), a manufacturer you link to ending support for a type) are sent once you tick Send my organization notifications. You can set a specific recipient in Send to (leave it empty to use every administrator) and tick the individual events you want. The crash email states the analyzer's reason with its figures in each recipient's units: a member's own units, or your organization's units for a Send to address that is not a member's.

Ahead of time lists the notices that are on until you switch them off, whatever the switch above says:

Each is said once when the item comes inside its lead time and once if it lapses, by email and in the bell at the top of every page. Credentials that expire covers the medical expiry on a pilot's details too. A recency rule's date moves with every flight that keeps it inside the lead time: the open notice follows the new date rather than being said again, and it is said again only if the rule leaves the lead time and later comes back inside it. It goes to your administrators (or the addresses in Send to) and to the person concerned; an authorization renewal goes to the administrators. An authorization renewal's lead time counts back from the date its renewal has to start by where its kind carries one (a 44807 exemption's petition 120 days before expiry, a Part 107 waiver's application 90 days, a UK SORA-based authorization's re-application from 28 days; see Authorizations) or where the authorization carries a Renewal lead of its own, and from the expiry for any other kind; an EU standard scenario declaration with no expiry entered is read as lapsing 2 years after it was declared.

The first time the notices run for your organization, anything that had already lapsed is recorded as already told: it shows in the bell but is not emailed. Only what is coming due inside its lead time is emailed on that first pass, and from then on anything that lapses is emailed when it lapses. Set each lead time in days ahead, from 0 to 365; a value outside that range is refused and nothing is saved. A notice whose item has been dealt with (a renewal recorded, a course signed off) leaves the bell. In the bell, Dismiss hides a notice for you; it stays on the record. Untick a notice to stop it for the whole organization.

Your organization's data#

These cards are in the Organization section, under Data and retention. How long positions, stored log files and records are kept is on the Retention page, and the activity log on the Audit page.

The organization export#

Your organization's data takes everything on your organization's record as one archive of JSON and CSV files another system can read: aircraft (with each aircraft's origin and covered foreign UAS list record in aircraft_origin.json), flights (voided flights included, with their history and log files), maintenance, missions, types and bulletins, manuals, occurrences, jobs and authorizations, the safety register (every hazard with its score history, its mitigations with their state and every correction, and each acceptance with its band, the mitigations it rests on and whether it still applies or lapsed and why) with your risk policy in sms_risk_policy.json, and with them your roles and who holds each one, groups, sign-in, session and single sign-on settings (never a secret), webhooks (never their secrets), the plan and add-ons, retention settings, builds with every saved version, the list of audit packages handed out, every document issued with a verification code with the record data it printed (issued_documents.json), the photos and documents withdrawn from records whose files are kept or were deleted (withdrawn_files.json, with the date each file is kept until), and the independent timestamp proofs.

1. Leave Include attached documents and photographs ticked (the default) to carry every document attached to a record (authorizations, insurance certificates, license scans, sign-off sheets, release certificates) and your job and occurrence photos as files. Their index is in every export either way.
2. Tick Include raw flight log files if you want the stored log files in it too; the archive can then be very large.
3. Choose how the CSV files separate their cells: Comma-separated CSV or Semicolon-separated CSV (Excel in Europe). The archive's manifest.json records the choice under csv, and every CSV file starts with the UTF-8 byte-order mark.
4. Press Export organization data.

The manifest lists every file with its size and SHA-256, README.txt describes each file and its fields, and the archive carries a verification code you can check at https://rotorlab.app/verify, with HOW-TO-VERIFY.txt and verify_package.py inside to check it offline. See Verifying documents. In the CSV files a list reads a; b and a set of values reads as JSON. A stored log file that could not be read is named in the manifest under not_written rather than left out silently. Every export is a row in your organization's activity log and on its list of handed-out packages, naming who took it.

Audit binder#

Download the audit binder downloads the audit binder.

Model annotations#

RotorLab can annotate your records with advisory scores, such as flights that look unusual against the airframe's own history and component life projections. Every score names the signals and the model that produced it, and nothing ever gates on one. Untick Annotate this organization's records for zero model output: off means absent everywhere, exports included. Separately, your data is used to train shared models only if you switch that on below it, and you can switch it off at any time.

Outside services#

The Outside services card says what your organization's records send outside RotorLab, and holds the three switches you decide. Each switch saves as soon as you tick or untick it, and the note under it says where it stands.

• Read this organization's encrypted DJI logs through DJI's keychain service. Current DJI flight records are encrypted, and reading one sends its key identifiers to DJI's keychain service (DJI is a company based in China). The switch is off by default: encrypted DJI logs are kept with their flights and are not read until you switch it on, and then they are read as they arrive. Older DJI logs, which are not encrypted, never need it.
• Use outside map and lookup services for this organization's members. On by default. Off, your members' maps draw on the plain grid (or the service's own map, where it has one) instead of imagery and terrain from Esri, USGS, OpenStreetMap and AWS, and no forecast, weather observation, place lookup, elevation lookup or address autocomplete is made for them. Where no terrain can be loaded, the Mission Planner and the Airspace Viewer say so instead of drawing level ground.
• Count this organization's members in usage analytics. On by default. Off, nothing about your members' visits (page views, the time zone, language and time on page their browser reports, and Google Analytics) is recorded or sent while they are signed in.

Under the switches, a line says whether precise positions, stored log files and live recordings, saved missions, area outlines and stored credentials are sealed at rest on this service. When the service runs in offline mode, the card says "This service is in offline mode: it makes no connection outside its own network." Nothing is then sent to DJI or any other outside service; single sign-on, email and webhooks reach only the hosts inside your network that your copy lists. Every outside service RotorLab can call is listed on the trust page at https://rotorlab.app/trust#outside.

Integrations#

These cards are in the Organization section, under Integrations. Personal API keys and the organization's key list are under API & credits; see API keys and credits.

Webhooks#

Organization admins with Fleet Manager add webhooks here: RotorLab pushes events (flights filed, bulletins issued, work orders raised and closed, occurrences filed, defects reported, members added or disabled) to your own systems as they happen. The events, signatures and retries are described under Webhooks.

Devices#

The Devices card enrolls ground stations and servers that file flights on your organization's behalf, such as a TAK Fleet Server or a ground station running the RotorLab Connector. Name the device and press Enroll device, then copy its Device Key: it is shown once and cannot be recovered, so a lost key is replaced with a new one and the old one revoked. A Device Key can file flights, checklists and logs; it never spends your analysis credits, filing is never metered, and it is not bound by a person's role or sign-in rules.

Traffic source#

Organization admins can give RotorLab a source of manned-aircraft traffic to draw on for the flight record. It is not a live map and it is never shown while flying: it fills in the Manned traffic card on a flight's analysis for aircraft that do not carry an ADS-B In receiver of their own, with the same closest-approach figures and the same caveat, that what is shown is what this source heard.

RotorLab ships no feed. The free aggregators allow non-commercial use only and the paid ones meter by request, so the source is yours: a receiver of your own running readsb, dump1090 or tar1090 and publishing aircraft.json, or an aggregator point endpoint you are entitled to use (adsb.fi, adsb.lol, airplanes.live and ADS-B Exchange through RapidAPI all answer in the same shape), on its terms and your bill. A key is stored masked and never appears in an export or the audit binder. A receiver on your own network may use plain http; anything on the internet must be https. A redirect from the source is not followed.

Pick the kind, enter the URL (for a point endpoint, with {lat}, {lon} and {dist} where the position and radius go, plus the center and radius to ask about), give it a name, and turn it on. Test now asks the source once and says how many aircraft it heard. The server then listens while a sortie is out on Dispatch, or for the two hours a Listen window opens, polling every ten seconds and keeping what it hears for two days. When a flight's log is read, its window is matched against those contacts by the log's own GPS time and track, and the encounters are frozen onto the flight with the source named on each. A flight whose window the source never covered says so on the card rather than showing an empty sky.

Billing & plan#

Shown to organization administrators and to members whose role holds Billing. It shows What you pay (every plan, add-on and bundle, how each is paid, and the totals a month and a year), your current plan and usage, billing details, and orders and invoices. Cancel at period end asks, optionally, why you are leaving and lets you add a note of up to 1000 characters; both go to RotorLab only, and Resume subscription clears them. A member with Billing: view reads them, and the section says that changing the plan, the billing details or buying needs Billing: manage. The details are covered on Plans, add-ons, and billing. When your organization's plan has ended, the plan line reads Plan ended with its stage and links to the Plan ended page; see When a plan ends.

API & credits#

Create and revoke named API keys, watch your daily usage and credit balance, and buy credit packs. See API keys and credits for the full walkthrough.

Add-ons#

For an organization admin, or a member whose role holds Billing: manage: one card per purchasable capability (live access, Crash Analyzer, Fleet Manager, and the rest), plus bundles. Each card says in one line what the capability does, and states whether it is included in your plan, active from a purchased add-on, or not active. An included capability that comes through another product names it, for example "Training Programs is included in your current plan, with Currency & Training Programs." Currency & Training Programs is one add-on that turns on both the currency screens and Training Programs: the Training Programs card says it comes with Currency & Training Programs, and buying that one add-on turns both on.

Any other member sees What your organization has instead: one line per capability with whether your organization has it, and the note "Your organization administrator manages the plan, billing and add-ons." It shows no prices or offers. See Plans, add-ons, and billing.

Security#

Password#

The Password card links to the change-password flow. Press Change password to open it. A new password must be at least 8 characters and must not be on RotorLab's list of commonly used passwords; one that is gets refused with a message, and you choose another.

Two-factor authentication#

The Two-factor authentication card adds a second step to signing in, on top of your password. The second factor can be a code from an authenticator app, a hardware security key or a passkey, or both. Every organization admin needs two-factor: an admin without it sees how many of their 14 days are left on the card, and after 14 days the account opens only the two-factor setup until it is on.

An authenticator app works with Google Authenticator, Microsoft Authenticator, Authy, 1Password, Bitwarden, and any other app that supports standard time-based codes. RotorLab does not talk to any of them, so nothing about your account leaves the server. To turn it on:

1. Press Set up two-factor.
2. Scan the QR code with your authenticator app, or enter the displayed secret key by hand.
3. Type the six-digit code the app shows and press Turn on.
4. Save the recovery codes that appear. Each one signs you in once if you lose your phone or your key. They are stored hashed, so this is the only time they can be shown. Press I have saved them when done.

Security keys and passkeys, under the same heading on the card, answer the sign-in instead of a typed code: a hardware security key, or a passkey on your phone or computer. A key signs only for RotorLab's own site, so a look-alike page cannot capture and replay it the way it could a typed code. To add one, press Add a security key, give it a name you will recognize, press Continue, and touch the key or confirm on your device when the browser asks. Your first key turns two-factor on and shows your recovery codes, as the app does. The list shows each key's name, when it was added and when it was last used. Remove takes a key off after you confirm your password; removing your only second factor turns two-factor off. You can hold an authenticator app and keys together. A current Chrome, Edge, Firefox or Safari can register a key; the card says so when your browser cannot.

When you sign in with a key on the account, the sign-in page offers Use security key after your password; you can still type a code or a recovery code instead, unless your organization takes security keys only.

While two-factor is on, the card offers New recovery codes (issues a fresh set; requires your password) and Turn off (also requires your password), which removes the authenticator app, every security key and the recovery codes.

If your organization requires two-factor, the card tells you how many days you have left to set it up, and warns you when the deadline has passed. Past the deadline your personal API keys are refused too, until two-factor is on. If your organization takes security keys and passkeys only, the card says so: an authenticator app alone does not meet the rule, and once you hold a key you sign in with the key or a recovery code, not an app code.

Active sessions#

The Active sessions card lists every device currently signed in to your account: the device (for example "Safari on iPhone"), the address it signed in from, and the session start and expiry times. Your current session is marked with a this device pill; every other row has an end link that ends that one session. Press Sign out of all other sessions to end every session except the one you are using.

The session length and idle timeout your organization sets apply to every session; see Sessions and sign-in.

Recent account activity#

The Recent account activity card shows a timestamped log of security-relevant events on your account (sign-ins, key changes, and similar), each with a severity level and detail line. Use it to spot activity you do not recognize.

Related#

• Plans, add-ons, and billing
• API keys and credits
• Accounts and signing in
• Security