Trusted integration boundary
Secrets and API Calls
Secrets stay server-side. This guide details safe call patterns so credentials never leak into client-visible code or logs.
Zero-gap secret usage patterns for secure outbound integrations.
Implementation focus
Apply these rules before integrating external APIs, OAuth, or webhook signatures.
Expected outcomes
- Keep credentials out of vibe source and runtime payloads.
- Use server-side secret injection for outbound API requests.
- Protect multi-tenant trust boundaries under real traffic.
Secret boundary
Secrets belong in trusted backend code, not in vibe source, runtime bundles, client-side logs, query strings, public metadata, screenshots, or examples that users are likely to copy into browser code.
Pulse code can use owner-managed secrets to call external APIs, but the response should only contain data the viewer is allowed to see.
- Store provider keys in the secret manager, not source files.
- Restrict host usage when the platform exposes host restrictions.
- Never echo secrets in errors or debug output.
- Rotate credentials if they were ever pasted into public code.
External API calls
External API calls that require credentials should run in Pulses. Browser-side calls are appropriate only for public APIs or user-provided credentials that are intentionally visible to that browser session.
Use env.fetch with env.secrets.bearer(), env.secrets.header(), or env.secrets.query() when a provider request needs an API key. That keeps the credential out of source code and lets the runtime attach it through policy-controlled outbound fetch.
Treat every outbound integration as a trust boundary: validate input, constrain destinations, handle provider errors, and return a safe response shape.
- Keep API tokens server-side.
- Normalize provider errors before returning them to clients.
- Avoid storing raw provider payloads unless the product requires it.
Example and read next
Example: a vibe needs a private API key. Store the key as a Pulse secret, call the provider from the Pulse, and return only the app-level result that the browser actually needs.
Use these related pages when you need the next layer of guidance. They point to the most likely follow-up tasks, not every page that happens to touch the same system.
- Read next: Calling Pulses (/docs/calling-pulses)
- Read next: Pulse SDK & Handlers (/docs/handlers)
- Read next: Approved CDNs (/docs/approved-cdns)
- Read next: Automation Safety (/docs/automation-safety)