Connect APIs without leaking keys.

Choose the boundary

The list below breaks this down into the parts that matter most. Read through each one and note anything that applies to your own setup.

• Public read-only data can use a client request if the provider allows it.
• Private keys, paid APIs and privileged writes belong in a backend function.
• Long-running or retryable work belongs in a queue or function, not a click handler.
• Webhooks must verify the sender before changing application state.

Function checklist

Work through these steps in order. Each one builds on the last, so resist skipping ahead even if a step feels familiar.

1. Define the smallest input and output contract.
2. Read the secret from the managed secret store.
3. Validate and authorize the incoming request.
4. Call the provider with a timeout and useful error handling.
5. Return a safe response and record non-sensitive observability data.

Production readiness

Add idempotency for retried writes, validate webhook signatures, set sensible timeouts and handle provider rate limits. Test invalid input and provider failure, not only the happy path.

Diagnostic sequence for a failing function

Here is the process broken into clear steps. Take them one at a time and check each off before continuing.

1. Reproduce the call with the same payload from a REST client to isolate the browser.
2. Check the function logs for the actual error, not just a generic 500.
3. Confirm the secret exists in the environment the function is actually running in.
4. Check the outbound provider's status page and rate limit headers.
5. Add a temporary verbose log line, redeploy, reproduce, then remove the log line.

Warning signs a function needs redesign

Before making changes, work through the points below. Each one covers a different part of the picture, so treat them as a set rather than picking favourites.

• A single function does authentication, business logic and third-party calls with no separation.
• Retrying a failed request creates duplicate records rather than updating one.
• Errors are swallowed and the browser only ever sees a generic failure message.
• The function's average response time keeps climbing as data volume grows.

Handover checklist

A few moving parts are involved here. The points below cover each of them, so you can see the full scope before deciding where to start.

• List every secret in use, which provider it belongs to and who owns rotation.
• Document the expected request and response shape for each function.
• Note any rate limits, quotas or paid tiers the integration depends on.
• Record where logs and error alerts are viewed.