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:

Product	Where to create it	How requests are authenticated
RPC	https://rpc.carbium.io dashboard	Endpoint URL with ?apiKey=YOUR_RPC_KEY
Swap API	https://api.carbium.io dashboard	X-API-KEY: YOUR_API_KEY request header

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:

Environment	Recommendation
Local development	Use separate dev keys with low blast radius
Staging	Use distinct keys so test traffic does not pollute production
Production	Use dedicated keys per service or app

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

Safe server-side usage

The safest default is to let clients send intent to your own backend, then let the backend call Carbium with the relevant server-side key.

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 X-API-KEY header. The current Q1 quote flow uses src_mint, dst_mint, amount_in, and slippage_bps:

const url = new URL("https://api.carbium.io/api/v2/quote");
url.searchParams.set("src_mint", "So11111111111111111111111111111111111111112");
url.searchParams.set("dst_mint", "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v");
url.searchParams.set("amount_in", "1000000");
url.searchParams.set("slippage_bps", "50");

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.

If your backend needs an executable transaction back from Q1, add user_account server-side after your app has validated the wallet public key and requested amount. Keep the Carbium API key out of the browser even when the wallet signs the returned transaction.

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.

Workload	Best restriction
Browser-based internal dashboard	Trusted domain
Backend API or worker	Static server IP
Multiple backend services	Separate keys per service, each with its own restriction set

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:

Risky pattern	Why it is risky	Better option
Hard-coding keys in React, Next.js client components, or mobile apps	Users can extract the key from shipped code or network traffic	Proxy requests through your backend
Calling api.carbium.io directly from the browser with X-API-KEY	The request works, but the key is visible in browser devtools and network logs	Browser sends swap intent to your backend; backend calls Carbium
Sharing one production key across every service	One leak affects everything	Use separate keys per app or environment
Reusing the same key for dev, staging, and prod	Traffic mixes together and rotation becomes painful	Split keys by environment
Posting keys in Discord, tickets, or screenshots	Secrets spread fast and are hard to fully revoke	Share request IDs or redacted examples instead
Blindly retrying after 401/403/429	Retries do not fix bad auth or plan restrictions	Check auth format, plan access, and throttling behavior first

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:

Code	Likely cause	First check
401	Missing or invalid key	Did the request include the right key and auth format?
403	Feature or plan restriction	Are you trying to use a gated product or tier?
429	Rate limit exceeded	Is traffic bursting too fast for the plan?

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

📘 Carbium's RPC dashboard supports endpoint restrictions by domain or IP. Use them together with server-side secret storage instead of treating the raw endpoint as a public credential.

🔶 Building a wallet, trading bot, or backend on Solana? Start with the documented setup flows at carbium.io and keep keys server-side from day one.