Skip to main content
Going live on mainnet requires whitelisting: NEAR Auth issues you dedicated production Auth0 credentials and grants access to the mainnet contracts. This page explains what you get and walks you through the approval process.
Building locally? You can develop against testnet using the values in Resources → Testnet, then come back here when you’re ready to ship on mainnet.

What whitelisting grants you

On mainnet, each production app gets its own Auth0 domain, clientId, and signingAudience, plus access to the mainnet NEAR Auth contract at fast-auth.near. This is what the whitelisting process below grants you.

Apply for production access

Submit the production access form

Open the application form to request mainnet whitelisting for your app.

How the approval process works

Submit your application

Fill out the production access form with details about your app and how you plan to use NEAR Auth. See what to prepare below so you can fill it out in one pass.

Review

The NEAR Auth team reviews your submission and may reach out for additional information about your use case or expected volume.

Approval

Once approved, you receive everything you need to go live:
  • Production Auth0 credentials — your dedicated domain, clientId, and signingAudience (the JWT aud).
  • Access to the mainnet NEAR Auth contract at fast-auth.near.
  • Guidance for production deployment.
Drop your production credentials into your provider config with network: "mainnet" — the rest of your integration stays the same.

What to prepare

Have these details ready before you open the form so you can submit in a single pass. Each field maps to a setting on your production application.
required
The name NEAR Auth displays to your users during login and when they approve a transaction. Use the public-facing name you want people to recognize — e.g. Acme Wallet.
required
A short summary of what your application does. It appears next to your name on the NEAR Auth login and transaction-approval screens, so write it for end users. One or two sentences.
A square logo shown alongside your app name on the login and approval screens. Provide a PNG or SVG (recommended 256×256 px) served over HTTPS. A recognizable logo helps users trust the request.
required
Your best estimate of monthly active users (MAU). This lets us provision capacity and set appropriate rate limits for your app. Choose one bracket: Less than 1,000, 1,000–10,000, 10,000–25,000, or more than 25,000.
required
The exact HTTPS URL NEAR Auth is allowed to redirect back to after login and after a signature request. It must match the redirectUri you configure in the SDK. Any redirect to a non-whitelisted URL is rejected. Example: https://app.example.com/callback.
Optional. An HTTPS URL users may be returned to after logging out. Only needed if you pass a return URL when calling logout; leave it blank otherwise. Example: https://app.example.com.
required
The origin — scheme + domain, no path — where your app is served and from which it calls NEAR Auth. Used to authorize your domain and enforce CORS, so only your app can start the auth flow. Must be HTTPS. Example: https://app.example.com.
required
A monitored email for the person we should contact about your application: approval, credential delivery, quota changes, and security notices. Example: dev@example.com.
Multiple environments — the Callback URL, Logout URL, and Web Origin fields each accept several comma-separated values, so you can register your production and staging URLs together. Developing locally? You don’t need this form for testnet — use the shared testnet credentials.
HTTPS is required for the Callback, Logout, and Web Origin URLs on mainnet. Plain http:// URLs are rejected.

Go live on mainnet

Once you’re whitelisted, point your provider at mainnet using your production credentials.
main.ts
Use the mainnet contract account ids when you construct the client:
client.ts
Production requires your own approved credentials. Only the dedicated clientId, domain, and signing audience you receive from whitelisting will authenticate against the mainnet NEAR Auth contract.

Next steps

Networks

Compare testnet and mainnet configuration side by side.

Mainnet resources

Production contract addresses, RPC, and explorer links.

Testnet resources

Shared testnet credentials to keep building right now.

Authenticate users

Wire up login and logout with your provider.