How installation normally works
What a forward deployed engineer does by hand today.
An OAuth redirect that ends in Notion's own page picker. The customer selects which pages and databases the integration may reach.
IntegrationsNotion
Notion
Notion is the destination that breaks the scope model, which is exactly why it is worth having: it proves the deployment unit survives a provider whose permission system is a page picker rather than a scope list.
PreviewSee the deployment model
MeetextDestination network Live
One productevery customer workspaceClaudeChatGPTAtlassianGoogle ChatHubSpotMicrosoft 365SalesforceServiceNowSlackAsanaCursorLinearNotionVS CodeZendesk
✓Customer scoped✓Least privilege✓Continuously checked
Available today
The adapter is real and something is incomplete, either a part of the destination or real-provider proof for part of the lifecycle. The gap is stated on the page rather than discovered during an evaluation.
The adapter is complete and every path is covered by tests against a provider simulator, which proves our logic and not the provider's. Not yet exercised with real provider credentials: authorization, installation, execution, refresh and reconnect, validation, failure handling.
Who has to approve it
The person whose calendar decides your go-live date.
Any workspace member who can add integrations, though what they can share is limited to what they can see.
Identity and OAuth model
Whose identity the product acts as, and where that grant lives.
A bearer token for the workspace, issued against HTTP Basic credentials because Notion refuses them in the request body.
What Meetext owns
The repeatable half, turned into software.
The OAuth exchange, the workspace and bot identity recorded from the token response, per-workspace credential storage, and revocation.
What the customer owns
The half that is theirs and should stay theirs.
Their workspace, and the selection itself. Sharing can be withdrawn inside Notion at any time without touching the grant.
Capability and permission model
How capabilities map onto what the platform will let you do.
There are none in the OAuth sense. What is shown is what the integration will be able to do with whatever the customer picks, in Notion's own words, so the page and the consent screen say the same thing.
Validation
What has to execute before anyone is told it works.
A real search. An integration can authorize perfectly and have nothing shared with it, which reads as green everywhere else and returns nothing to every capability. That is reported as a failure with the fix.
Credential lifecycle
Rotation, expiry, revocation, and who notices first.
The token does not expire and cannot be refreshed. Stated as an answer rather than left as a missing renewal path.
Deployment versioning
What happens to this customer when you ship version four.
Per customer. The API version is pinned by Meetext so an account created next year behaves like one created last year.
Typical failure modes
What actually goes wrong, named rather than generalised.
The quiet one: somebody removes the integration from the pages it was connected to. No OAuth event fires, the token stays valid, and everything returns nothing. Health checks for it.
Operational monitoring
How you learn it broke without the customer telling you.
Token validity, and whether the integration still reaches any shared content at all.
Common questions
- Does Meetext support Notion?
- Notion support is in preview. The adapter is complete and every path is covered by tests against a provider simulator, which proves our logic and not the provider's. Not yet exercised with real provider credentials: authorization, installation, execution, refresh and reconnect, validation, failure handling. Meetext does not yet operate production Notion customer deployments.
- Who has to approve a Notion installation?
- Any workspace member who can add integrations, though what they can share is limited to what they can see.
- What goes wrong with Notion deployments?
- The quiet one: somebody removes the integration from the pages it was connected to. No OAuth event fires, the token stays valid, and everything returns nothing. Health checks for it.
Current support status
PreviewNotion
The adapter is real and something is incomplete, either a part of the destination or real-provider proof for part of the lifecycle. The gap is stated on the page rather than discovered during an evaluation.
The adapter is complete and every path is covered by tests against a provider simulator, which proves our logic and not the provider's. Not yet exercised with real provider credentials: authorization, installation, execution, refresh and reconnect, validation, failure handling.
- Implementation
- A complete adapter.
- Proof
- Covered end to end against a provider simulator. Never run against the real provider.
Lifecycle coverage
- authorization · simulated
- execution · simulated
- failure handling · simulated
- installation · simulated
- refresh and reconnect · simulated
- validation · simulated
This label is generated from a proof registry in the deployment code, not written on this page. Available requires a complete adapter and either dated real-provider evidence or an explicit owner attestation after simulator-complete testing. The proof row above keeps those foundations apart.
2 environments free
Stop assigning an engineer to every customer.
Connect a source, publish, and send one link. Your next enterprise customer installs itself.
2 customer environments free, forever. No card required.