Handling Keys and Errors

An API key proves who you are and often ties to billing. If it leaks, others can run up your bill or abuse your access. Treat it like a password.

This lesson covers storing keys safely and handling the errors that real-world calls inevitably throw, so your integrations stay secure and reliable.

Pasting a key directly in your code is the most common mistake. It ends up in version control, screenshots, and shared snippets where anyone can grab it.

Instead, keep keys out of source files entirely. Ask your assistant to refactor any hardcoded key into a safer location before you commit.

The standard place for keys is an environment variable, often loaded from a .env file kept out of version control. Your code reads it by name at runtime.

This keeps secrets off the page and lets each environment, local or production, use its own key without changing code.

Keys placed in front-end browser code are visible to anyone who opens dev tools. For sensitive APIs, the call should happen on a server you control.

A small backend route holds the key, calls the API, and returns only the data. Your assistant can scaffold this proxy pattern for you.

If a key ever leaks, rotate it: generate a new one in the provider's dashboard and revoke the old. Do not just delete it from code, the leaked copy still works.

Assume any key that touched public code is compromised. Rotating is fast and the only safe response.

Networks drop, services go down, and limits get hit. Robust integrations assume failure and handle it, rather than crashing or showing a blank screen.

Wrapping calls so errors are caught and turned into friendly messages is what separates a demo from a real app.

In code, a try block holds the call and a catch block handles thrown errors. But fetch does not throw on a 404 or 500, so you must also check response.ok.

Checking the status code yourself catches errors the try block alone would miss. Ask your assistant to add both layers.

APIs often return a JSON error body explaining what went wrong, like "invalid_api_key" or "missing parameter city". This message is more useful than the status alone.

Log and surface this body during development. Your assistant can map common error codes to fixes for the specific API you use.

A 429 status means you exceeded the rate limit. The response often includes a Retry-After header telling you how long to wait before trying again.

Good clients back off and retry instead of hammering. Ask your assistant to add a retry with a delay that respects that header.

A call that hangs forever freezes your app. Set a timeout so slow requests fail fast, then show cached data or a retry button as a fallback.

Designing for the unhappy path keeps users in control. Describe the fallback you want and let your assistant wire it up.

A production-ready call hides the key on a server, checks the status, catches errors, respects rate limits, and times out gracefully. Each layer is small.

You rarely write all this by hand. You describe the requirements and your AI assistant assembles a robust, secure integration you can trust.

Test your understanding of keys and error handling.

Keep keys out of code in environment variables, off the client, and rotate them if leaked. Expect failures and handle them with try/catch plus status checks.

Read error bodies, back off on 429s, and add timeouts with fallbacks. With these habits and your AI assistant, your API integrations stay secure and resilient.