API Key Security Best Practices

Carbium keys are simple to start with, but they still need production-grade handling. The fastest way to leak budget, expose trading logic, or create noisy support incidents is to leave a working key in frontend code, a public repo, or an unrestricted endpoint.

This page covers the safest patterns for Carbium RPC and Carbium Swap API using only documented flows:

• create keys in the Carbium dashboards
• keep secrets server-side
• restrict RPC endpoints to trusted domains or IPs
• rotate keys when access changes or exposure is suspected

Part of the Carbium Solana infrastructure stack.

Which keys Carbium uses

Carbium currently documents two separate key flows:

For RPC accounts, Carbium also documents endpoint restrictions in the dashboard, including allowed domains and allowed IP addresses.

The rules that matter most

If you only remember five things, make them these:

1. Never embed Carbium keys in frontend or mobile client code.
2. Never commit keys to Git, screenshots, or support messages.
3. Store keys in environment variables or a secret manager.
4. Restrict RPC endpoints to trusted domains or backend IPs when possible.
5. Rotate keys immediately if a contractor leaves, a repo leaks, or a device is compromised.

Recommended storage pattern

Use separate environment variables for each product and environment:

CARBIUM_RPC_KEY=rpc_live_xxx
CARBIUM_API_KEY=api_live_xxx

Recommended split:

Separate keys make rotation easier and help isolate abuse, usage spikes, and deployment mistakes.

Safe server-side usage

RPC example

Use the RPC key on the server or in backend jobs, not in browser bundles:

const rpcUrl = `https://rpc.carbium.io/?apiKey=${process.env.CARBIUM_RPC_KEY}`;

const response = await fetch(rpcUrl, {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    jsonrpc: "2.0",
    id: 1,
    method: "getHealth",
    params: [],
  }),
});

console.log(await response.json());

Swap API example

Use the Swap API key in a backend route or worker and send it in the documented header:

const url = new URL("https://api.carbium.io/api/v2/quote");
url.searchParams.set("fromMint", "So11111111111111111111111111111111111111112");
url.searchParams.set("toMint", "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v");
url.searchParams.set("amount", "1000000");
url.searchParams.set("slippage", "100");
url.searchParams.set("provider", "raydium");

const response = await fetch(url, {
  method: "GET",
  headers: {
    "X-API-KEY": process.env.CARBIUM_API_KEY!,
  },
});

console.log(await response.json());

These patterns keep the key out of user-visible code and make it easier to add logging, quotas, and abuse controls around your own application layer.

Restrict RPC endpoints whenever you can

Carbium's RPC docs explicitly support endpoint restrictions in the dashboard:

• allow a specific domain
• allow a specific IP address

Use those controls as an outer guardrail.

This matters because a leaked unrestricted endpoint can be reused from anywhere until you rotate it.

What not to do

Avoid these patterns even for prototypes:

Rotation checklist

Rotate a key when:

• you pushed it to a public or shared repository
• a team member or contractor no longer needs access
• you cannot explain a usage spike
• an endpoint was left unrestricted longer than expected
• a laptop, CI variable, or secrets store may have been exposed

Practical order:

1. Create a replacement key in the relevant dashboard.
2. Update environment variables or secret manager entries.
3. Deploy the new value everywhere that depends on it.
4. Confirm requests succeed with the new key.
5. Delete or regenerate the old key.

Basic incident triage

When traffic starts failing, use the response code before you assume the problem is downtime:

For ongoing 429 responses, the right next step is usually request shaping, caching, or a higher tier, not wider key sharing.

Security review for launch

Before shipping a wallet, bot, or backend integration, verify:

• secrets live in env vars or a secret manager
• no keys appear in browser devtools, mobile bundles, or public repos
• RPC endpoints are restricted where practical
• production and non-production keys are separate
• key rotation is documented for whoever is on call