Skip to content

Synq is pre-launch. Early access is by request. Ask for early access

Synq

Changelog

What’s new.

What changed in Synq, by day. Synq is pre-launch, so these changes are in its code and tested, ahead of the first release. Follow it by RSS.

  1. Sign-in on your own domain

    • On Pro and up, a brand’s sign-in can run on a domain you own, such as login.acme.com. Add one CNAME record, and Synq checks it, issues the certificate and emails you when it’s live: a second issuer for the brand, with the same users, apps and keys.
    • The dashboard’s Domain tab walks you through it, with the record to add, each problem’s fix, and what to change in your apps. The management API and MCP can add and check one too.
    • Passkeys made on your brand’s Synq host also work on your domain, in browsers that support related origins.
    • If your plan changes to one without custom domains, the domain keeps working for 14 days, and an upgrade in time keeps it.

  2. Email from your own domain, and replies that reach you

    • On Pro and up, your brands’ sign-in email can come from your own domain, such as mail.acme.com, signed with it. Add the domain, publish its DNS records, and Synq verifies it and keeps checking it; whenever it can’t send from your domain, the email still arrives, from “Acme via Synq”.
    • On every plan, set where replies to your brand’s email go. The address is used once someone who reads it confirms it, and without one, replies never reach Synq: the email says they aren’t read.
    • The dashboard has an Email domains tab for each org and an Email tab for each brand, with exactly what your users’ next email will carry and a test you can send yourself.

  3. Your own provider apps on your own host, and every provider in MCP

    • An app you bring to a sign-in provider now sends people back to your brand’s own sign-in host. Register your brand’s own callback with it; an org-wide app registers one callback per brand.
    • Apps built on @synqauth/nextjs can add a way to sign in to someone’s account, and signing in again in the same browser no longer signs the person out.
    • MCP hosts can turn Apple, X and Facebook sign-in on and off, and the tools name every provider.

  4. Social sign-in, passkeys, token gates and plans

    • Brands can turn on sign-in with Google, Microsoft, Discord, Apple, X and Facebook, through Synq’s apps or your own.
    • People can sign up and sign in with passkeys that the issuer verifies itself, and your apps can ask them to add one.
    • Sign in with any Solana wallet that follows the Wallet Standard, against a request the issuer makes for each sign-in.
    • Orgs on Pro and up can gate sign-in on token holdings, checked at every sign-in and refresh. When a gate refuses someone, they can add the wallet that holds the tokens right there.
    • People can add a wallet, Google, Microsoft or an email address to their account, and remove one, from your app.
    • The sign-in page shows “Last used” on the way someone last signed in on that device.
    • Every org has a plan, listed at GET /v1/plans, and GET /v1/orgs/{org}/billing/usage shows its monthly active users against its allowance.
    • Ending a user’s sessions, disabling them or resetting their password tells your apps through back-channel logout.
    • People and tenants can see and withdraw the consents Synq remembers.
    • Synq’s MCP server lets your admins read your org and make small changes from an MCP host.
    • Next.js and React apps can sign people in with @synqauth/nextjs and @synqauth/react, with every Synq token kept on the app’s server.
    • A flood of events at one org no longer delays other orgs’ webhooks.