Keep the integration safe by treating keys, ids, and connectors as separate trust boundaries
A secure Vidbyte integration does not stop at storing the API key. You also need to respect the encrypted-id boundary on public resources, keep third-party provider credentials inside the integrations system, and avoid building request flows that leak secrets into browsers, logs, or source control.
Treat API keys like production secrets from the moment they are created
Move plaintext keys into your deployment secrets, vault, or local environment as soon as they are created. Do not commit them to source control, paste them into shared screenshots, or leave them in browser-only storage if your backend can hold them instead.
The encrypted public id is part of the security model
Vidbyte intentionally exposes encrypted public ids instead of raw internal database identifiers. That boundary prevents callers from coupling themselves to internal persistence details and reduces accidental exposure of internal ids in logs, URLs, and client storage.
If a route requires a resource id, send the public encrypted id you received from the API itself. Do not attempt to substitute internal ids from elsewhere in the system.
Provider authorization belongs to the integrations surface, not to public route bodies
Google Drive and Notion connection state is managed by the integrations system. That means access tokens, refresh logic, scopes, and connection health stay behind the account-management boundary instead of being pushed into the public route contract.
That separation is why the route layer can stay focused on `context` and resource generation while the integrations layer owns provider trust and lifecycle management.
Browser-facing apps should usually proxy through their own backend
If your product includes browser-driven actions, do not default to exposing a long-lived Vidbyte API key directly to the client. A server-owned proxy keeps key rotation, logging, and request policy under your control.
That proxy boundary is also the right place to validate user permissions before a Vidbyte route is called on their behalf.