Public API credentials, public resource ids, and provider credentials each have different security rules
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.
API keys
Server secret
Store them in secret managers or server-side environments, not in committed source or browser bundles.
Resource ids
Opaque public ids
Use encrypted ids exactly as returned and never substitute raw internal identifiers.
Connector creds
Settings-owned
Provider auth and refresh flows belong to the integrations system, not the public route DTOs.
Credential hygiene
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.
Identifier safety
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.
Connectors
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.