Connectors let Vidbyte work with third-party content before it becomes API request context
Connect external knowledge sources through connectors
Connectors are the bridge between a user's third-party content systems and Vidbyte's generation flows. They let a user authorize an external provider account, choose the items they want Vidbyte to read, and then bring that material into the same context pipeline that powers the rest of the API.
Current providers
Google Drive + Notion
Google Drive and Notion are the first supported connectors in the repo today.
Connection surface
Integrations settings
Users connect or reconnect providers from the authenticated integrations settings page.
API role today
Context input source
Connector content becomes input for the context layer rather than a separate route family.
Concept
A connector is a trusted link between Vidbyte and a user's external workspace
The connector model exists so users do not have to copy and paste source material manually every time they want to generate a roadmap, quiz, exam, project, or quickhit. Instead, they connect a provider account once, choose the specific external artifacts they want Vidbyte to read, and let Vidbyte normalize that content into the same request pipeline the API already understands.
That keeps the public API contract simpler. Your application still reasons about context. The connector system handles the provider-specific authorization, resource discovery, and content import work behind the scenes.
Available now
Google Drive and Notion are the first connectors in the repository
Google Drive: designed for Drive files, folders, and Google Docs selection, with document and text-file import support in the current integration layer.
Notion: designed for page selection today, with page content normalized into Vidbyte-readable text blocks.
User flow
Users connect providers from the integrations settings surface, not from a public API route
Provider connection is an authenticated account-management action. A user signs in to Vidbyte, opens the integrations settings page, authorizes the provider, and then manages connection health, reconnects, or disconnects from there.
That design keeps provider credentials out of the public API contract and lets Vidbyte own the OAuth, token refresh, and provider health responsibilities in one place.
How it fits into requests
Connector content supports API requests by feeding the context layer
The live public route contract does not expose a first-class `connector` request field today. Instead, connector-selected content is imported through the integrations layer, normalized into Vidbyte-readable content, and then supplied through the existing `context` model that create routes already accept.
That keeps the route surface truthful to the backend while still making connectors useful in practice. You connect the provider once, select the items you want, and then use the imported material as context when calling the generation APIs.