Onboarding a New Teammate onto One Shared Aggregator Key: A Step-by-Step Checklist

Why a Shared Key Needs a Checklist

Handing a teammate the same API key is convenient but risky. A structured onboarding prevents accidental key leaks, misconfigured clients, and billing surprises. This checklist walks through the essentials for a new developer joining a project that uses a single aggregator key.

What to Share (and How)

• Base URL and endpoint – The aggregator provides an OpenAI-compatible API endpoint. Share the exact base URL from the dashboard. Most SDKs expect it in a baseURL or api_base setting.
• API key – Deliver it through a secure channel (password manager, secrets vault). Never paste it in chat or email.
• Environment variable names – Standardize on APIKEY and BASEURL (or your project's convention) so code is portable.
• Model identifiers – Provide the list of available models (e.g., claude-3-5-sonnet, gpt-4o, deepseek-chat) but clarify that names match the aggregator's documentation, not the upstream provider's.
• Billing model – Explain that usage is charged at official price × 1.3 and that contributors receive credits at official price × 1.1 (or × 1.2 for premium models) in USDC. This helps them understand cost implications.

What NOT to Share

• The key itself in plaintext – Use a secrets manager or environment variable injection. Avoid committing keys to Git.
• Billing and top-up details – The new teammate doesn't need access to the USDC wallet or payment history. Keep financial operations separate.
• Rate limit specifics – While you can mention that limits exist, avoid sharing exact thresholds unless necessary; they may change and could encourage testing against limits.
• Admin dashboard access – Only give read-only or no access to the aggregator dashboard unless the role requires it.

Step-by-Step Onboarding

1. Verify prerequisites – Ensure the teammate has a development environment with Python/Node.js and Git configured.
2. Provision the key – If possible, create a new key specifically for this teammate (if the aggregator supports multiple keys). Otherwise, share the existing key via a secure method.
3. Set environment variables – Guide them to add APIKEY and BASEURL to their .env file (and add .env to .gitignore). Provide a .env.example template.
4. Test with a simple call – Use curl or a minimal script to confirm connectivity. Example:

```bash
curl $BASE_URL/chat/completions \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"gpt-4o","messages":[{"role":"user","content":"Hello"}]}'
```

5. Configure the SDK – Show how to set the base URL in popular clients (OpenAI SDK, LangChain, etc.). Emphasize that the API is OpenAI-compatible, so most code works with minimal changes.
6. Review security practices – Remind them never to log the key, hardcode it, or share it further. Use environment variables in production.
7. Document the setup – Add a README section or internal wiki page with these steps for future teammates.

Common Pitfalls to Avoid

• Hardcoding the key – Always use environment variables or a secrets manager.
• Using the wrong base URL – Double-check the endpoint; missing /v1 or trailing slashes can cause errors.
• Assuming model names – Model identifiers may differ from upstream providers; always refer to the aggregator's model list.
• Ignoring billing implications – A shared key means shared costs. Set up usage alerts if the dashboard supports them.

Final Check

Before the teammate starts coding, confirm they can make a successful API call and that they understand the security and billing boundaries. A little upfront effort keeps the shared key safe and the project running smoothly.