Google Distance Matrix API in Zapier: Setup Guide + Key Restrictions
Set up Google Distance Matrix API in Zapier: create a Google Cloud project, enable billing, generate an API key, and apply safe restrictions so your Zap runs.
How to Grant Notion Integration Permissions Safely (Without Making Someone an Admin)
Notion integration permissions can be secure without admin access. Use this least-privilege checklist to scope tokens, capabilities, and page connections safely.
TABLE OF CONTENTS
If you have ever tried to create a Notion integration token and hit a permissions wall, you are not alone. The safe approach is to use the least privilege setup: have a workspace owner create the integration, grant only the capabilities you actually need, and then scope the integration to only the pages and databases it should touch.
In this guide, you will learn how to do that, plus what to do when your workspace plan does not support granular page access controls.
The problem: integrations can look “all or nothing”
When you create an internal Notion integration, Notion asks you to associate it with a workspace. Only Workspace owners can create those integrations and retrieve the token.
That leads to a common (and risky) workaround: making a teammate a workspace admin or owner “just so they can create the integration.”
Do not do that.
Quick definitions (so we are talking about the same thing)
- Workspace roles: owner, membership admin, member, guest. Workspace roles control access to workspace settings and member management.
- Page permissions: full access, can edit, can comment, can view.
- Internal integration: a private integration intended for one workspace, typically used for API automations.
The safe approach (least privilege checklist)
1) Decide what the integration actually needs to do
Before anyone creates an integration, write a short requirements list:
- What data needs to be read?
- What needs to be created or updated?
- Does it need comment access?
- Does it need user directory reads?
- Does it need webhook subscriptions?
Only request capabilities that are required.
2) Have a workspace owner create the integration
In most workspaces, creating internal integrations is owner-only. Owners can create the integration, set capabilities, and retrieve the token.
If you are a member who cannot see the workspace in the integration creation UI, that is a signal that your role is not sufficient to create the integration in that workspace.
3) Limit the integration’s capabilities at creation time
When defining the integration, choose the narrowest permission set that still supports your workflow.
Examples:
- If the automation only reads data, do not grant insert or update.
- If it only writes to one database, do not grant broad access across the workspace.
4) Scope access to specific pages and databases (when available)
Notion supports an “add connections to pages” model where integrations are added to specific pages. In Enterprise workspaces, owners can also manage which pages an integration can access.
Practical recommendation:
- Create a dedicated “Integration Access” page or teamspace.
- Place only the databases and pages the integration should touch under that area.
- Add the integration connection only where required.
5) Use page-level access when the goal is “users should only see the rows they are assigned to”
If your real problem is people permissions (not integration permissions), Notion’s page-level access can enforce record-level visibility using a person property rule.
This is useful when you want a shared database but need strict visibility boundaries between teammates.
Common mistakes (and safer alternatives)
Mistake 1: Promoting someone to workspace admin “temporarily”
Risk: admin and owner roles are powerful enough to change workspace settings and membership.
Safer alternative: have an owner create the integration and hand off the token via a secure secret manager, or a controlled internal process.
Mistake 2: Granting broad integration permissions “just to get it working”
Risk: the integration can read or write more than intended.
Safer alternative: start with read-only, validate the workflow, then add write capabilities only when you have confirmed exactly what needs to be updated.
Mistake 3: Relying on filtered views for security
Risk: a user can often navigate to the source database, change filters, or open records outside the intended view.
Safer alternative: page-level access rules enforce restrictions at the record level.
When you should consider a different architecture
Sometimes the “right” answer is not more permissions.
Consider these approaches:
- Forms for submit-only workflows: Let someone create new entries without browsing the full database.
- Separate intake database + relation to a private master database: Users work in a limited-access table, and you relate or roll up into the master table.
Final checklist (copy/paste)
Owner creates the internal integration
Integration capabilities are the minimum required
Integration is connected only to the pages/databases it should access
Token is stored and shared securely
People permissions are solved with page-level access (when needed)
CTA
If you want help designing a secure Notion permissions model (including integrations, databases, and teamspaces), book a free consulting call.
Related Posts
