IntegrationsLinear
Linear is where a customer's product and engineering work actually lives, and it is the cleanest test of a destination whose permission model is coarser than Meetext's: two scopes for a whole workspace.
MeetextDestination network Live
One productevery customer workspaceAvailable 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.
What a forward deployed engineer does by hand today.
An OAuth redirect. The customer chooses the workspace and approves, and the authorization carries actor=app so anything created afterwards is attributed to the vendor's application rather than to the admin who clicked Approve.
The person whose calendar decides your go-live date.
Any member who can authorize applications for the workspace.
Whose identity the product acts as, and where that grant lives.
OAuth 2.0 per workspace. The workspace is read from the API during the callback, because it is not in the token response.
The repeatable half, turned into software.
The OAuth flow, resolving which workspace a grant belongs to, per-workspace credential storage, renewal where the application issues refresh tokens, and revocation.
The half that is theirs and should stay theirs.
Their Linear workspace, and whether applications may read it at all.
How capabilities map onto what the platform will let you do.
Linear grants read and write, and nothing finer. Least privilege here is a decision about whether to ask for write at all, so a read-only product never does. Destructive capabilities raise the risk on the same grant rather than inventing a scope Linear does not have.
What has to execute before anyone is told it works.
A real GraphQL query: the viewer plus one page of issues. A workspace with no issues passes; a grant that cannot see issues at all does not, and that is the state a restricted workspace produces.
Rotation, expiry, revocation, and who notices first.
Refresh tokens are opt-in per application. A workspace connected through an application without them is told to reconnect for that stated reason rather than because renewal quietly failed.
What happens to this customer when you ship version four.
The frozen package decides which capabilities this workspace reaches, independently of what the vendor has since published.
What actually goes wrong, named rather than generalised.
A refusal arrives as HTTP 200 with an errors array, so a transport-level check alone would read a rejected query as healthy. The adapter reads the body.
How you learn it broke without the customer telling you.
Token validity, and whether the grant still holds the scopes the current package needs.
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.
Lifecycle coverage
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.
Connect a source, publish, and send one link. Your next enterprise customer installs itself.
2 customer environments free, forever. No card required.
