Security Best Practices

Your SALZ API key grants access to your account's optimization quota. Treating it like a password is essential. This page covers the practices that keep your integration secure.

Never Hard-Code Keys

Do not put API keys directly in your source code. Use environment variables instead.

Bad:

// DO NOT do this
const response = await fetch('https://add-salz.io/api/v1/optimize', {
  headers: {
    'Authorization': 'Bearer salz_k_a1b2c3d4e5f6g7h8...',
  },
});

Good:

const response = await fetch('https://add-salz.io/api/v1/optimize', {
  headers: {
    'Authorization': `Bearer ${process.env.SALZ_API_KEY}`,
  },
});

Use Environment Variables

Store your API key in your environment, not in files that get committed to version control.

# .env (add to .gitignore)
SALZ_API_KEY=salz_k_a1b2c3d4e5f6g7h8...

For deployment, use your hosting platform's secrets management:

• Vercel: Project Settings > Environment Variables
• Railway: Variables tab in your service
• AWS: Secrets Manager or Parameter Store
• Docker: --env-file or Docker secrets

Never Expose Keys Client-Side

SALZ API calls must happen on your server, never in browser-side JavaScript. Any key shipped to the browser is visible to anyone who opens DevTools.

Bad -- calling SALZ from the browser:

// This exposes your key to every visitor
fetch('https://add-salz.io/api/v1/optimize', {
  headers: { 'Authorization': `Bearer ${publicKey}` },
});

Good -- calling SALZ from your server:

// Next.js API route or server action
export async function POST(request) {
  const { text } = await request.json();

  const response = await fetch('https://add-salz.io/api/v1/optimize', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.SALZ_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ text }),
  });

  return Response.json(await response.json());
}

Rotate Keys Regularly

Periodic key rotation limits the damage if a key is leaked:

1. Create a new API key in the dashboard.
2. Update your application to use the new key.
3. Deploy the change.
4. Verify the new key works.
5. Revoke the old key.

Add Keys to .gitignore

Make sure your .env files are excluded from version control:

# .gitignore
.env
.env.local
.env.production

Monitor for Unauthorized Use

Check your usage dashboard regularly. Unexpected spikes in API calls may indicate a leaked key. If you suspect unauthorized access:

1. Revoke the compromised key immediately.
2. Create a new key and deploy it.
3. Review your codebase and deployment logs to find the leak.

Use Separate Keys Per Environment

Create distinct keys for development, staging, and production. If your development key is accidentally committed to a public repository, your production traffic is unaffected -- just revoke the dev key and create a new one.

Summary