How Dify knowledge sync from Notion, Google Drive and websites works
Teams usually keep policies, runbooks and reference pages in Notion, Google Drive and public websites, and they want Dify answers grounded in those sources rather than in copies pasted into a knowledge base by hand. Dify supports three paths for this. Notion connects through an integration that a self-hosted deployment must configure in .env before Notion can be authorized, using either an internal integration (NOTION_INTEGRATION_TYPE=internal with NOTION_INTERNAL_SECRET) or a public integration with a client ID and secret. Google Drive uses the langgenius data source plugin from the Dify Marketplace for knowledge pipelines, which authenticates with OAuth 2.0 and converts Google Docs, Sheets and Slides into formats Dify can process. Website import covers public pages that the team can crawl into a knowledge base. Each path is a documented Dify method, and this page covers what each one requires, what it does to the content it imports, and what a re-sync costs.
The paths differ in ways that matter before any connection is made. Notion imports do not carry images or files, and table data is converted to text, so a runbook that depends on a diagram or a spreadsheet layout will lose information at import. The Google Drive plugin depends on which Google account authorizes it, so the team should decide whether access follows a service account, a shared drive owner or individual users, and confirm with the plugin documentation which file types and permissions it actually reads. Website import depends on what the site exposes to an automated reader, so content behind login, scripted rendering or robots restrictions should be confirmed before anyone promises coverage. None of these outcomes should be assumed from the product name alone.
Every re-sync is a cost decision. According to the Dify docs, re-syncing an updated Notion page runs the embedding process again and consumes tokens from the embedding model, so a team that syncs a large workspace on a schedule pays for the same text repeatedly whenever it changes. Before going live, confirm which embedding model the workspace uses, how often each source changes, and which pages change most. Those three facts decide the sync frequency and the monthly embedding bill, and they belong in the scope agreed before any build starts.
What a self-hosted Dify needs before any source connects
Every source in this page depends on the same base: a running Dify, a working embedding model and outbound paths that the platform allows. Set these up first, because a failed authorization or an empty index usually traces back to one of them.
Docker Compose baseline
Start from the self-hosting minimum of 2 CPU cores, 4 GB of RAM and Docker Compose 2.24.0 or later. The Compose stack runs the api, worker, web, plugin daemon, PostgreSQL, Redis, Weaviate, Nginx, a code sandbox and an SSRF proxy, and the worker is the part that performs embedding during a sync. Size the host for the number of pages you expect to import, not only for the idle stack, and confirm the ceiling with a test import.
Working embedding model
Every sync re-embeds content, so the workspace needs a configured embedding model before the first import. Choose the model and its provider credentials up front, because switching models later means re-indexing the knowledge base. Confirm that the model endpoint is reachable from the worker container, not only from your browser.
Outbound paths through the SSRF proxy
Dify routes outbound requests through the SSRF proxy, which blocks internal and private IP ranges. Notion, Google APIs and public websites must resolve to public addresses and be reachable through that path. Test each destination from inside the stack, and if a source sits on an internal host, plan an explicit allowlist rather than weakening the proxy globally.
Notion integration credentials in .env
Notion authorization fails until the instance knows which integration it is. Use an internal integration with NOTION_INTEGRATION_TYPE=internal and NOTION_INTERNAL_SECRET, or a public integration with its client ID and secret. Store these values in your secrets manager, keep them out of version control, and share each Notion page or database with the integration so the sync can read it.
Google Cloud OAuth client
The Google Drive data source plugin authenticates with OAuth 2.0, so you need a Google Cloud project with an OAuth client that points back to your Dify instance. Define which account owns the client, which Drive files it may read and who manages the secret. Google's consent screen and scope rules change over time, so confirm current Google-side requirements in the Google Cloud console before you configure the plugin.
Source access owners
Each source needs a named owner who can grant read access and revoke it. Notion access follows the pages shared with the integration, and Google Drive access follows the account that authorizes the plugin. Record who approved each source, which spaces or folders are included and how removals will reach the knowledge base, so access reviews can trace every indexed document back to a grant.
How to configure each source in order
This sequence connects Notion, Google Drive and a website to one self-hosted Dify knowledge base, so each source is confirmed working before the next one is added. Each step ends with a visible check so problems surface where they start.
Set Notion credentials in the environment file
The operator adds either an internal integration (NOTION_INTEGRATION_TYPE set to internal, with NOTION_INTERNAL_SECRET) or a public integration (client ID and secret) to the .env file of the self-hosted Dify deployment. Dify needs these values before Notion can be authorized, so this step comes first. Restart the stack so the api and worker services read the new values. The step is done when the Notion data source option appears in the console and the authorization prompt opens without a configuration error.
Authorize Notion and select the pages to import
A workspace administrator completes the Notion authorization from Dify and then chooses the pages or databases the integration may read. Pages not shared with the integration in Notion will not appear, so confirm sharing in Notion before selecting. Expect that images and files are not imported and that table data is converted to text. The check is that the selected pages appear in the knowledge base list with an indexing status, and that a sample page's text matches the source.
Confirm indexing and retrieval for the Notion source
Wait for indexing to complete on the Notion documents, then ask a question in a test app or the knowledge base retrieval test panel that the Notion content should answer. Record which parts were dropped, such as images, embedded files and table structure, so users are not surprised later. The step closes when a known Notion passage is returned as a retrieval result. This baseline also gives you a reference for measuring what a later re-sync costs in embedding tokens.
Install the Google Drive plugin from the Marketplace
An administrator installs the langgenius Google Drive data source plugin from the Dify Marketplace into the workspace, using the plugin management area of the console. The plugin is a data source for knowledge pipelines, so the workspace must allow knowledge pipeline creation. Review the plugin's listed permissions before installing, since it reads files on behalf of the authorizing user. The check is that Google Drive appears as an available data source when you create a knowledge pipeline.
Complete OAuth and choose Docs, Sheets and Slides
Authorize the plugin with Google OAuth 2.0 using an account that can read the target folders, then select the file types to ingest. Google Docs, Sheets and Slides are converted into formats Dify can process, so select those types explicitly and leave out files you do not want indexed. Confirm that the consent screen shows only the scopes your review approved. The step is done when a selected Drive file appears as a document in the pipeline preview with converted text.
Run the Google Drive pipeline and verify output
Run the knowledge pipeline and wait for processing to finish. Open a few converted documents and compare spreadsheets and slides against the originals, since conversion can flatten layout and complex formatting. Note any file that failed or was skipped. The check is a retrieval test against a known Drive document that returns the expected passage, along with a list of unsupported or failed files to resolve or accept.
Import the website and check what it captured
Create a knowledge base entry from a website using the website import option, entering the start URL and crawl options the console offers. Confirm that the target site is reachable from the Dify network, and that outbound requests pass through the SSRF proxy, which blocks internal and private address ranges. Review the imported pages for navigation text, cookie banners and duplicate content. The step is complete when a sample page is indexed and a retrieval test returns its content.
Record the re-sync cost and schedule updates
Document which sources are connected, who owns each credential, and what each import drops. Re-syncing updated Notion pages runs embedding again and consumes tokens from the embedding model, so ask the team to confirm the embedding model and expected re-sync frequency before automating it. Confirm with your provider how the embedding model is billed for your account. The check is a written runbook entry for each source that names the owner, the credential location and the re-sync trigger.
What each source imports and what it drops
This table maps each object type from Notion, Google Drive and websites to what Dify keeps after import. Read each row as a question: will this content be searchable, will it be lost, or will it change shape? The main takeaway is that Notion images and files are not imported and tables become text, so test each object type on a sample before you commit to a sync design.
| Source object | What Dify imports | What Dify drops or changes |
|---|---|---|
| Notion pages (text blocks) | Text content from pages shared with the integration | Page structure is flattened into text chunks; confirm how headings and toggles appear after import |
| Notion tables | Table data converted to text | Table layout is lost; confirm that row and column relationships survive chunking before relying on them |
| Notion images | Nothing; images cannot be imported | Any meaning carried only by an image is absent from retrieval |
| Notion attached files | Nothing; files cannot be imported | Attachments such as PDFs must be exported and uploaded separately |
| Google Docs (via Google Drive plugin) | Converted to a format Dify can process through OAuth 2.0 access | Confirm how comments, suggested edits and embedded images are handled in your test |
| Google Sheets (via Google Drive plugin) | Converted to a format Dify can process | Cell structure and formulas may not carry over as tables; check retrieval on sample sheets |
| Google Slides (via Google Drive plugin) | Converted to a format Dify can process | Speaker notes and slide visuals may be lost; confirm against a sample deck |
| Website pages (web import) | Page text from the URLs you import | Navigation, scripts and layout are not retained as content; confirm which pages are reachable from your SSRF proxy settings |
Securing the connection and the data it carries
A self-hosted Notion sync depends on secrets kept in the deployment's .env file. For an internal integration, the Notion token is held in NOTION_INTERNAL_SECRET with NOTION_INTEGRATION_TYPE set to internal. A public integration uses a client ID and secret instead. These values grant read access to whatever pages the integration is shared with, so they should be treated as production credentials. The SECRET_KEY value deserves separate attention because it signs session cookies and JWTs and encrypts OAuth credentials stored by Dify.
- Restrict file access: Limit read permissions on
.envto the service account that runs the containers, and keep it out of version control. - Use an internal integration where possible: Share only the Notion pages that belong in the knowledge base with the integration, instead of granting broad workspace access.
- Plan for SECRET_KEY changes: Changing
SECRET_KEYafter deployment logs out all users, and stored OAuth connections may need to be authorized again. - Store the file in your secrets system: Generate the
.envcontents from a vault or secrets manager during deployment rather than editing it by hand on the host. - Rotate deliberately: Record which sync connections depend on each secret so that rotation does not silently break scheduled re-syncs.
Confirm with your team which person or pipeline is allowed to read and rotate these values, and where the copy in your backups is encrypted.
The Google Drive data source plugin from the Dify Marketplace uses OAuth 2.0 and converts Google Docs, Sheets and Slides into formats Dify can process. The person who completes the authorization grants the workspace access to the files that account can see, so the choice of account is a security decision. A personal account with broad access to shared drives can expose far more content than the team intends to index.
- Choose a dedicated sync identity: Use an account created for the knowledge pipeline, granted access only to the folders that should be indexed.
- Review requested scopes: Compare the scopes shown during consent with the minimum the plugin needs, and ask the plugin publisher to document each one.
- Limit shared drives: Add the sync identity to specific shared drives instead of organization-wide groups.
- Track reauthorization: Note who authorized the connection and when, because changes to the account's access alter what the next sync imports.
- Remove access at offboarding: Revoking the connection in Google and in Dify should be part of the process for people who leave the team.
Confirm the exact scopes the plugin version you install requests and whether your Google Workspace administrator permits third-party OAuth apps for this account.
Website import makes outbound requests from the Dify server to addresses that a user supplies, which is a classic server-side request forgery risk. Dify routes outbound requests through the SSRF proxy configured by the SSRF_PROXY settings, and the proxy blocks internal and private IP ranges. This protects internal services from being reached through a crafted URL. Only the requests that pass through the proxy are filtered, so the deployment must make sure the import path actually uses it.
- Keep the proxy in the request path: Confirm in your deployment settings that website import and Notion or Google calls go through the configured proxy.
- Avoid bypass rules: Do not add internal hostnames to allowlists to make an import work without a documented reason and an owner.
- Scope crawled domains: Decide which domains and paths may be imported, and reject pages that redirect to internal targets.
- Watch for internal documentation: Intranet wikis reachable from the server may be imported by accident if filtering is loosened.
- Test with a blocked address: A simple test that a private address is refused gives evidence that filtering works in your environment.
Confirm with the Dify environment variable reference how your installed version applies SSRF filtering to each sync type, since behavior can differ between versions.
Once content is imported, the synced text becomes searchable by anyone who can open the knowledge base, use an app built on it or query it through the API. Access control in Dify is therefore a data protection question as well as a configuration task. The source system's permissions do not automatically carry over, so a page restricted in Notion may be readable by all workspace members in Dify.
- Assign roles by need: Give dataset editing rights to the people who manage sync, and reading or app use rights to everyone else.
- Separate sensitive sources: Place content from different classification levels into different knowledge bases with different audiences.
- Check app exposure: Apps that use a knowledge base may be published to end users, which exposes its content through the app.
- Review API keys: Service API keys that can query a knowledge base should be listed, owned and rotated.
- Plan for source deletions: Removing a page in the source does not necessarily remove it from the index, so define how deletions are handled.
Confirm the role permissions available in your Dify version for knowledge bases, and whether Community edition login options meet your identity requirements. Dify Enterprise adds SSO with OpenID Connect, SAML and OAuth2, with separate scopes for workspace access and web app access.
Why Notion, Drive and website imports fail
This table lists the failures teams most often hit when importing from Notion, Google Drive and websites into a self-hosted Dify knowledge base, with the likely cause and the first check for each. Work down the rows in order, because the Notion and Drive checks depend on configuration that must be in place before authorization can succeed. Treat the first check as the cheapest test to run before changing anything else.
| Symptom | Likely cause | Check first |
|---|---|---|
| Notion authorization fails | NOTION_INTEGRATION_TYPE or NOTION_INTERNAL_SECRET (or the public client ID and secret) is missing from .env, or the value was set but the services were not restarted | Confirm the variables exist in .env, then restart the Dify services so the api and worker containers reload them |
| Notion pages do not appear in the picker | The page or database was not shared with the Notion integration, so the integration cannot see it | Open the page in Notion, share it with the integration, then re-authorize and refresh the page list |
| Google Drive authorization fails or shows a consent error | OAuth consent screen or requested scopes are not set up for the Google Cloud project used by the plugin, or the signed-in account is not permitted | Review the OAuth consent configuration and scopes for your Google Cloud project, then retry with an account your organization allows |
| Google Sheets content is garbled or incomplete | Spreadsheets are converted to a text form that loses table structure, merged cells and formulas | Preview the converted output before indexing, and move critical tables into Docs or a separate structured source |
| Website import returns nothing or fails | The SSRF proxy blocks requests to internal or private IP ranges, so pages on intranet hosts cannot be fetched | Check the SSRF proxy behavior for your target host, and confirm with your security team before allowlisting any internal address |
| Images or tables missing from results | Notion images and files cannot be imported, and table data is converted to text, so layout and embedded content are lost | Treat these as expected limits, and add the visual content as text or companion files if retrieval depends on it |
| Re-sync is slower or costlier than expected | Every re-sync of an updated page runs embedding again and consumes tokens from the embedding model | Re-sync only pages that changed, and confirm the embedding model and token usage with the workspace owner before scheduling bulk updates |
What re-syncing costs in embedding tokens
Every re-sync of an updated Notion page runs the embedding process again, and that work consumes tokens from the embedding model you have configured in Dify. The cost is not in the import itself. It is in the embedding calls that follow, so the spend grows with how many pages are re-embedded, how often, and how large each one is. Unlike the initial import, which you pay for once per document, a sync schedule turns embedding into a recurring line item. Before you enable any automatic sync, confirm with the team which Notion workspaces, Google Drive folders and websites will be pulled in, because the workspace size sets the upper bound on what a full re-sync can cost.
Four drivers decide the size of that recurring bill. The first is page count and total text volume, which sets how much is embedded on each run. The second is churn rate, meaning how many pages actually change between syncs; a workspace where most pages are edited weekly costs far more to keep current than one where content is stable. The third is chunking: the chunk size and overlap chosen for the knowledge base determine how many chunks, and therefore how many embedding calls, each page produces. The fourth is the price of the embedding model itself, which is set by your provider and may differ between hosted and self-hosted endpoints. Ask the team to measure churn over a representative period and to record the chunking settings before requesting a quote.
To get a quote, ask the embedding provider for its current per-token price for the specific model in use, including any separate pricing for batch or rerank models, and whether self-hosted endpoints carry a compute cost instead. Ask the team for page counts per source, an estimate of changed pages per week, and the planned sync frequency. Confirm with the Dify documentation for your version how incremental updates are handled, because whether an unchanged page is skipped or re-embedded determines whether a full re-sync is a routine event or an occasional one. Plan a budget alert on the embedding account so that a misconfigured schedule is caught early rather than at invoice time.
Questions buyers ask before connecting Notion, Google Drive or websites
How much effort does a single knowledge source take to connect?
Effort depends less on the connector than on the source's shape and your access rules. A single Notion workspace with a few hundred pages is mostly configuration: creating the integration, setting the values in .env, authorizing, selecting pages and running a test import. The work grows when content is messy, when tables need review because they are converted to text, or when images and attached files must be handled separately, since the Dify Notion docs say they cannot be imported. Google Drive adds OAuth consent and folder scoping. Websites add crawl rules and login handling. Ask any partner to split the quote by source and to name what is excluded from each.
Can our own team connect these sources without a partner?
Yes, for a small, well-understood set of sources. The Notion path is documented step by step, and the Google Drive plugin is a langgenius data source plugin from the Dify Marketplace that uses OAuth 2.0. Teams usually need outside help when they must decide which content is allowed into a knowledge base, when several sources feed one index, or when re-sync cost and permissions must be designed and tested before users rely on answers. DeployOpen plans, configures and documents this work inside your environment under a written scope, and it can hand the runbook to your team.
What do we need to provide: admin rights, a Notion owner, or Google Workspace approval?
Plan for three roles before the work starts:
- A Dify administrator who can edit
.env, restart services and manage the knowledge base. - A Notion workspace owner or admin who can create the internal or public integration and share the chosen pages with it. Pages not shared with the integration will not appear.
- A Google Workspace administrator if your domain restricts third-party OAuth apps, because the Drive plugin's OAuth consent may need approval.
Also confirm who owns the integration credentials after handover, since a departing owner can leave the connection broken.
How do we control what a re-sync costs?
The Dify Notion docs state that re-syncing updated pages runs the embedding process again and consumes tokens from the embedding model. Cost therefore follows the volume of changed text, not the number of sync clicks. Control it by limiting sync scope to the pages that need to be searchable, excluding large archives and duplicated content, scheduling re-syncs instead of running them on every edit, and reviewing the chunk settings before the first full import. Ask your embedding provider for its per-token price and ask any partner to estimate re-sync volume from your page count and change rate.
Does website import cover pages behind a login?
Confirm this before scoping the work, because authenticated pages need a different approach from public ones. A public site can be crawled with its URLs and the Dify SSRF proxy must allow the target host. Pages behind a login need a session or token handled outside the usual import, and you must decide who owns that credential and how it rotates. Pages that require a user session may also be excluded from a shared index for access reasons. Check the current Dify documentation for website import options in your version, and test with a representative page before committing to a crawl plan.
What does a Dify knowledge import drop or change?
Expect loss in three places: images and attached files, which the Notion docs say cannot be imported, table content converted to text, which can lose structure, and anything your permissions model hides from the integration. Also expect that answers reflect the text as converted, so a spot check of representative pages should be part of acceptance. Ask for a written list of dropped element types per source before go-live.
Who should approve which content goes into the knowledge base?
Access control in the source does not carry over automatically into a shared Dify knowledge base, so the approval step is a governance decision. Name a content owner per source, decide which spaces, folders or sites are eligible, and document who may add a new source. Review permissions whenever a page is restricted in its origin system. Where the knowledge base is used by many people, separate sources by sensitivity instead of mixing them in one index.
Decisions to settle before the first sync
Each source you connect to Dify affects which knowledge base owns the content, who can revoke access, and what each re-sync costs. Settle these five questions before the first import so that the sync design does not have to be unpicked after teams start relying on the data.
Which source owns which knowledge base
Decide whether each knowledge base has exactly one upstream source. A knowledge base fed from Notion, Drive and a website mixes owners, review cycles and deletion rules, so a page removed upstream may still answer questions. Map each source to one knowledge base and one named owner, and check how each import treats content that is later deleted or moved.
Internal or public Notion integration
An internal integration (NOTION_INTEGRATION_TYPE=internal with NOTION_INTERNAL_SECRET) is tied to one workspace and suits company content. A public integration uses a client ID and secret and suits authorization by users outside your workspace. Choose the type before editing .env, because it determines who authorizes the connection and which pages the integration can see.
Drive plugin pipeline or manual upload
The Google Drive plugin runs as a data source in a knowledge pipeline and authenticates with OAuth 2.0, converting Google Docs, Sheets and Slides into formats Dify can process. Manual upload gives you direct control over each file and fewer moving parts, but nothing refreshes on its own. Pick the pipeline when content changes often, and check the plugin's conversion output on a sample of your own documents first.
Re-sync frequency and token budget
Each re-sync of an updated Notion page runs embedding again and consumes tokens from the embedding model. The cost therefore grows with how often pages change and how often you re-sync, not with how many pages exist. Agree on a schedule per source, confirm the embedding model and its price with the provider, and estimate changed content per cycle before enabling automatic sync.
Credential ownership and revocation
Decide who holds the Notion secret, the OAuth client and the Drive grant, and who can revoke them. A departing employee who authorized a personal Drive connection can silently break a sync, and a leaked integration secret exposes every page it can read. Record each credential's owner, store it in your secrets process, and test revocation and re-authorization before go-live.
How DeployOpen scopes and delivers knowledge source integrations
DeployOpen plans, builds, documents and supports Dify knowledge sync from Notion, Google Drive and websites inside your own infrastructure. Each engagement starts with a written scope that names the sources, the knowledge bases they feed and the re-sync rules that control embedding cost.
How we scope
- Inventory each Notion, Google Drive and website source, with its owner, access model and sensitivity classification.
- Decide which integration type fits Notion, either an internal or a public integration, and record the .env settings each one needs.
- Agree in writing which content types are excluded, such as images, files and table data, and what the team will do about them.
How we build
- Configure the Notion integration in the .env file of your self-hosted deployment and verify authorization against a test workspace.
- Install and configure the Google Drive data source plugin for knowledge pipelines, using OAuth 2.0 with accounts your administrators approve.
- Set up website import with crawl boundaries and test the resulting documents against the sources they came from before loading production content.
How we hand over
- Document each source mapping, sync schedule, re-sync trigger and the embedding model that each re-sync will consume tokens from.
- Provide a test report showing what each import dropped, including images, files and converted tables, so your team knows the gaps.
- Walk your operators through a re-sync runbook covering cost checks before large updates and how to roll back a faulty import.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer, including checks after Dify minor releases.
- Ask any partner for a quote built from the written scope, including the one-time setup effort and the recurring embedding cost estimate for your content volume.
