How installation normally works
What a forward deployed engineer does by hand today.
An OAuth redirect. The account that authorizes is the account the deployment acts as, and the workspace it belongs to is read and recorded during the callback.
IntegrationsAsana
Asana
Asana is the strictest test of credential handling here. Access tokens last an hour and the refresh token rotates, so a single dropped replacement loses the customer's grant a day later, looking like something they did.
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 Asana user who is a member of the workspace this is for.
Identity and OAuth model
Whose identity the product acts as, and where that grant lives.
OAuth 2.0 for one user, scoped in practice by the workspace recorded at installation. A token reaches every workspace that person belongs to, including personal ones, which is why the workspace is pinned rather than inferred per call.
What Meetext owns
The repeatable half, turned into software.
The OAuth flow, storing each rotated refresh token, refusing an exchange that returns no replacement, the recorded workspace, and revocation.
What the customer owns
The half that is theirs and should stay theirs.
Their Asana workspace and the account that authorized it.
Capability and permission model
How capabilities map onto what the platform will let you do.
Granular scopes are opt-in per application. Meetext always asks for the narrow set, so an app without them grants more than was requested rather than less, and that difference is visible in the granted scopes rather than hidden.
Validation
What has to execute before anyone is told it works.
A real read of the recorded workspace's projects, plus a check that a refresh token was actually stored, because without one the install stops working within the hour.
Credential lifecycle
Rotation, expiry, revocation, and who notices first.
Rotating. The replacement is stored on every exchange and an exchange without one is refused at the moment it happens rather than discovered as a dead grant the next morning.
Deployment versioning
What happens to this customer when you ship version four.
Per customer. Publishing does not move an installed workspace.
Typical failure modes
What actually goes wrong, named rather than generalised.
A first exchange that returns no refresh token, which is refused rather than recorded as an installation that expires in an hour.
Operational monitoring
How you learn it broke without the customer telling you.
Token validity and whether the rotating refresh token is still stored, which is the thing that breaks quietly here.
Common questions
- Does Meetext support Asana?
- Asana 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 Asana customer deployments.
- Who has to approve a Asana installation?
- Any Asana user who is a member of the workspace this is for.
- What goes wrong with Asana deployments?
- A first exchange that returns no refresh token, which is refused rather than recorded as an installation that expires in an hour.
Current support status
PreviewAsana
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.