EdgeKit ID
One reader account on every title
Every title you publish reads the same reader account, so a subscriber’s purchase, company seat and answers are known everywhere. Already run Ory, Auth0 or your own login? Keep it, and move one title at a time, without a password reset.
Titles
- LThe Ledgerledger.exampleAll-Access
- SLedger Sportledgersport.exampleAll-Access
- MLedger Moneyledgermoney.exampleAll-Access
One account0192f3…c41e
- Access
- Ledger All-Access · via company seat
- Company
- Northwind Partners · seat 12
- Sign-in
- Email code
What it does
Sign-in is where the reader account starts
Every subscription, newsletter and paywall decision hangs off one question: who is this reader? EdgeKit ID gives the whole group one answer, instead of one per title and one per vendor.
Sign-in
No passwords to reset, leak or store
Readers get a six-digit code or a sign-in link by email, or continue with Google or other social accounts. EdgeKit sends the codes, checks them and keeps the reader signed in on your domain.
- Sent from your own address through SendGrid or Resend.
- Links sign in on the reader’s click, never a mail scanner’s visit.
- One form for sign-up and sign-in.
LThe Ledger
Sign in or create an account
Emailj.okafor@example.comCode sentEnter the six-digit code4819From subscriptions@ledger.exampleSign inorContinue with GoogleNo password. Signed in on ledger.example.Your existing login
Keep the login you have. Run the paywall anyway.
Your sign-in can stay on Ory, Auth0 or a login you built. EdgeKit checks that login on every request and still runs the meter, the paywall and the offers. Readers sign in where they always have, and your sign-in pages stay exactly as they are.
- Connect with a token your backend signs, or a live check against your login service.
- Token claims, such as a membership level, feed your paywall rules.
- Each title picks your login, EdgeKit, or both while it moves.
Deploy 43 · Ledger Sport → Both, while moving · m.reyes
Moving over
Move a title over without a password reset
Set a title to both logins and each reader moves on their next page view: EdgeKit checks their current sign-in, matches them to their account by an email your login has verified, and signs them in with EdgeKit. No reset email, no new password.
- Matched only on an email your current login vouches for, never merged on a guess.
- The same reader keeps the same account, before and after.
- One title at a time, each move a numbered deploy with a name on it.
- Mon 09:12Signed in with Ory on Ledger Sport.EdgeKit checks the sign-in on every page.
- Wed 07:40 · Deploy 43Ledger Sport set to Both, while moving.
- Wed 08:05 · Next page viewMoved, in one page load.
- Ory sign-in checked
- Email verified by Ory
- Matched to account 0192f3…c41e
- Signed in with EdgeKit
- AfterSame account, nothing to re-enter.No email sent. No password chosen.
account 0192f3…c41e · unchanged
Company accounts
Sell to a whole company, seat by seat
Open a company account in the console and its people join by invitation, or on their own from an email domain you list. Seats are capped, and when the cap turns someone away, the company’s admins can see who.
- Joining by domain needs a verified email domain.
- The company’s admins invite, remove and promote their own people from screens you build on EdgeKit’s browser SDK.
- What the company buys reaches every member through their seat.
Northwind Partners
OverviewMembersInvitationsDomains
- Domain
- northwind.example · joins automatically
- Invitations
- 3 waiting
- Admins
- 2
- Access
- Ledger All-Access · Active
On ledger.example · company admin
Waiting for a seat
- p.lin@northwind.exampleTurned away at the cap
- d.osei@northwind.exampleTurned away at the cap
Registration
Ask what you need to know at sign-up
Your team adds a question in the console — job title, favourite section, company size — and the email-code sign-up asks it, with no code change. Readers who joined by link or Google answer from their own account, and a paywall rule can see whether someone has answered everything you require.
- Text, number, yes-or-no or a list of options, each required or optional.
- Rename an option at any time. Retire one and the answers already given are kept on file, not deleted.
- Answers sit on the account every title reads.
Everything in it
The details behind every account
First-party on your domain
Sign-in runs on a path of your own domain. No third-party login page, no vendor domain in the address bar.
Inbox flood limits
Three codes or links a minute per address on EdgeKit sign-in. Past it, EdgeKit refuses instead of sending.
Every staff access is logged
When your team, or EdgeKit support with your consent, opens or corrects a reader’s account, it lands in your own audit log.
No shared tables
Reader accounts sit in a database of your own, never in a table shared with another media group.
Your login stays in charge
When your login deletes a reader or signs them out, your backend tells EdgeKit in one call: the account is anonymised in place, or every session ends.
No account for browsing
Anonymous reading is counted by device and never creates an account. An account means a reader who signed up or was added by your team.
Getting live
How a title goes live
A working demo on your own domain in a day, then one title at a time. Your CMS, payment processor and email platform stay where they are, and your current login keeps working beside EdgeKit until you move a title off it.
White-glove onboarding: we set it up with you, start to finish.
- 01
Forward one path
Your domain sends /edgekit/ to EdgeKit, so sign-in is first-party on the website readers already visit.
- 02
Choose who signs readers in
Per title: your current login, EdgeKit, or both while it moves. We set it up with your team.
- 03
Draw the screens in your design
Your developers build sign-in, account and company screens with EdgeKit’s browser SDK. No hosted page, no iframe.
- 04
Publish, then the next title
A title goes live when your team publishes it. Titles you have not moved carry on as they are.
Questions
Frequent questions
Will readers have to sign in again or reset a password when we switch?
Not by design. A title set to both logins moves each reader on their next page view: EdgeKit checks their current sign-in, matches them to their account by an email your login has verified, and signs them in with EdgeKit. Nobody is emailed and nobody chooses a password. A reader whose email your login has not verified is never matched on a guess: the move is refused and logged, and that reader reads as signed out until your team resolves it.
Can we keep Ory, Auth0 or our own login?
Yes, title by title, for as long as you want. Ory is checked on every request against your own Ory project. Auth0 or a login you built connects through a token your backend signs for EdgeKit, with one algorithm pinned. Checking Ory on every request counts against your Ory request limit, so a busy title needs headroom on your Ory contract.
Our titles are on different domains. Is it still one account?
Yes. Every title reads one account per reader, so what they bought, the questions they answered and their company seat are the same everywhere. The reader signs in on each title with the same email, into the same account. Each title keeps its own meter, offers and sign-in settings.
Our current vendor already shares login across titles. What is different?
A shared login lets one sign-in work on several titles. One account is what every title’s paywall, newsletters and subscriptions read, so a purchase on one title can also be known on all of them. You choose.
Which sign-in methods can readers use?
A six-digit code by email, a sign-in link by email, or any standard social or OpenID Connect login, such as Google. Each title chooses which email methods it offers. We discourage the use of passwords for security reasons. Codes and links can come from your own address through SendGrid or Resend.
Who owns the reader accounts?
You do. Their database can sit in a region you name or in your own cloud account, and the accounts can be exported on demand.