Skip to main content

Production Backend Auth

Production traffic should treat the FastNear API key as a backend credential.

  • Store the key in env vars, a secret manager, or your deployment platform's secret store.
  • Inject it from a server, worker, proxy, or agent runtime that you control.
  • Log and monitor usage server-side.
  • Rotate the key if it leaks or if a team member no longer needs access.

Never do this in production​

  • Do not ship the key in browser bundles.
  • Do not keep the key in browser localStorage and call that "secure".
  • Do not expose the key to end users through public query strings, visible headers, or client-side config payloads.

Example: server-side fetch​

const response = await fetch('https://rpc.mainnet.fastnear.com?apiKey=' + process.env.FASTNEAR_API_KEY, {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    Accept: 'application/json',
  },
  body: JSON.stringify({
    jsonrpc: '2.0',
    id: 'my-service',
    method: 'query',
    params: {
      request_type: 'view_account',
      account_id: 'root.near',
      finality: 'final',
    },
  }),
});

Operational guidance​

  • Redact credentials from logs, traces, crash reports, and copied curl examples.
  • Prefer a thin backend proxy when browsers need FastNear-backed features.
  • Give agents or workers their own runtime-owned credentials, not credentials borrowed from a developer browser session.
  • Document key ownership and rotation so the team knows who can revoke and replace credentials.

Troubleshooting​

My backend works locally but fails in production​

Check the deployment environment first: missing env vars, wrong secret names, or filtered outbound network rules cause more problems than request shape.

I see keys in logs or error reports​

Fix that before expanding usage. Treat any logged key as compromised and rotate it.

The browser still needs direct FastNear access​

Put a controlled backend or edge proxy in front of FastNear and make that service own the key.