Have a question that isn’t answered here? Reach out to us via our help widget in the bottom-right corner of this screen.

​
General

We don’t support deleting users from your dashboard view. However if you are requesting to delete any PII user data on behalf of the user we can absolutely process those requests.
Magic offers a Deletion Request API that enables developers to delete users’ information in compliance with GDPR.
Magic developers can specify which domains are allowed to use their application’s publishable API key by configuring Domain & Mobile Access Whitelisting from the Settings page within the Magic Dashboard. The Domain & Mobile Access Whitelisting configuration is disabled by default for all newly created apps. Only the domains you specify will be accessible by your application when enabled.To configure domain access, open your application’s Settings Page from the Magic Dashboard. From there, you can Edit the list of domains you want to support. Specific domains and wildcards using * are supported. Examples are below:
  • http://localhost
  • https://example.com
  • https://*.example.com
  • http://example.com:8080⁠
There is no need to whitelist domains required to complete any Social Login (i.e., https://accounts.google.com, https://facebook.com, etc.) or Private Key Export (i.e., https://reveal.magic.link) flow. Magic automatically accepts these domains and any other domains on your whitelist.
Magic is not meant to replace your database, so if you need to store any information about users, you’ll manage your own DB. We also won’t store any custom user data, (only email, public address and issuer) but that doesn’t stop you from prompting users for more info (such as first name, last name, etc) and storing that in your database. Magic also does not support importing user data.
Absolutely. The Magic code to power the authentication will be the same regardless of if it’s a first time user signing up or a returning user logging in. However if you want to prompt new users for additional information to store in your database such as name or address, you can have a separate login and register page. To check if a user is new, you can simply query your database for the email before calling loginWithMagicLink and if the email doesn’t exist you know it’s a first time user and redirect them to the register page.
Magic comes with essentially no vendor lock-in, so migrating away is easy. You will have the user’s unique ID (issuer) and email both stored in your database (and any other user info) so are free to choose another service or move authentication in-house should you want to do that.

​
Questions Around Email

Rarely, a user may not receive an email immediately after requesting one. This is usually due to a spam filter holding onto the email before eventually displaying it in the user’s inbox. If it’s a personal email, adding our sending domain [email protected] to their email contacts list should solve the problem. If it’s a corporate email, asking the user to have their IT team add our [email protected] email domain to their internal allowlist should prevent emails from being held up by the spam filters.
If a user loses access to their email account, they need to contact their email service provider (i.e.: Gmail, Microsoft Outlook, iCloud Mail) and follow steps for account recovery.

​
Questions Around SMS

Some country codes are blocked due to heavy spam traffic from the region. If a user’s country code is blocked they may still authenticate through email.Currently blocked country codes:
+7, +20, +53, +62, +92, +94, +98, +221, +225, +231, +234, +235, +241, +243, +244, +249, +263, +291, +370, +375, +591, +670, +855, +870, +880, +881, +882, +883, +961, +962, +963, +964, +968, +992, +994, +996, +998, +44745, +44778, +44783, +447624, +4477003, +4478299

​
Sessions and Tokens

By default, users remain authenticated with Magic for up to 7 days (or until they logout or browser data is cleared). Developers can enable and configure auto refresh sessions in our developer dashboard, extending the session up to 90 days instead of 7. See Session Management for more.If you’re building a custom backend, we recommend our Decentralized ID token as a way to initiate server-side sessions. The DID Token is a cryptographically-generated proof of user authentication. Your resource server simply needs to validate the token and set an HTTPS session cookie. This option gives you the flexibility of maintaining your own sessions without storing user secrets.
The session (how long a user is logged in for) is set by Magic through cookies/browser storage. Client-side, you can tell if a user has a valid session by calling magic.user.isLoggedIn which will return true or false.A DID token is proof of authentication, not necessarily proof of having a valid session. That’s because the getIdToken sdk method can create a token that expires far in the future, and just because a token was theoretically created with an expiration for one year in the future, the session set by Magic may not still be valid. The DID token that’s returned from loginWithMagicLink has a default lifespan of 15 minutes and is generally used to send to the server after login to validate its authenticity with the admin sdk validate function. The DID token can be used to access a protected API route on the server if stored in a cookie or client-side storage. You can create a token with getIdToken any time a user is logged in.Developers can control how long the Magic session lasts in the developer dashboard.
The issuer is the unique ID provided by Magic for each user. The DID token shouldn’t ever be used as the unique ID because for each user, and each login, the token is unique. When decoded, it contains information about the login, including a timestamp.
When a user logs out, the session will expire but a previously generated DID token is not automatically invalidated. The only way for a once-valid DID token to be invalidated is for it to expire. That’s why it’s best to create short-lasting DID tokens when the user is logged in and re-generate them as needed (if needed) by your application.

​
Refresh Token Security

While the Auto Refresh sessions feature is enabled, Magic will use the browser’s IndexDB to store refresh tokens under your domain. These refresh tokens can be exchanged for a Magic session. If your application is vulnerable to Cross-Site Scripting (XSS), it is not within Magic’s control how an attacker will exfiltrate these refresh tokens. We strongly recommend that you review OWASP’s documentation on XSS vulnerabilities. OWASP also provides a great starter sheet for XSS prevention.If you are a Web 3 developer, we strongly encourage you in particular to understand your application’s exposure to XSS. A successful XSS attack targeting a Magic refresh token on your application could translate to the attacker owning your end user’s Web 3 address/wallet.

​
Blockchains

Developers can now call the revealPrivateKey method to initiate the private key reveal flow within their apps. Users no longer need to leave your app to get their private keys! This method is available on our Web, React Native, and Android SDKs. If your app is not able to use this method please continue reading about how you may request a private key reveal page.
For applications that aren’t able to call the reveal private key method, ⁠Magic creates a private key reveal page for your users to log into using the same login methods as your app. This page is only made for your app upon request. When the user logs in they will follow intuitive prompts to reveal their private key. If you would like your users to be able to view and export their private key, please contact us using the chat widget in the bottom-right corner of this page with the following information:
  • Your API key (starts with pk_live)
  • A list of blockchains you are using
  • Your app name for the endpoint, such as https://reveal.magic.link/your-app-name
The login methods available on your reveal page will match the login methods that you have activated in your Magic developer dashboard (found under “Passwordless Login” and “Social Login”). Please make sure to deactivate any login methods that you are not using. Login methods can be added and removed at any point and changes will be immediately visible on your reveal page.The look of the UI for your reveal page will also match the settings configured within the “branding” section of your developer dashboard. This includes the logo shown, the primary color, as well as choosing between light/dark mode. More details on branding and UI customization can be found here.
If you have an existing private key reveal page hosted by Magic and need to make changes, please reach out via our support widget in the bottom-right corner of this page.

​
App Store Review

You can create a test email account and provide the login credentials on submission. The reviewer can authenticate by logging into the test email account and clicking the link or getting the OTP code.Alternatively, you could provide the reviewer with a test email address you already own, such as [email protected] and click the link when triggered by the reviewer to log them in.