Google Vault

Enable the Google Vault connector in your fastn dashboard, then let each customer authenticate their own Google Vault account. fastn handles the OAuth flow, token storage and refresh per tenant, so there is no Google Vault client code in your app and no per-customer branch in your codebase. Setup is 4 steps.

Yes. Every connection is scoped to the individual customer, so each authorises their own Google Vault account and only ever sees their own records, datasets and fields. That per-tenant isolation is the point of an embedded integration: you support the long tail of customer setups without maintaining an integration per customer.

Yes. The same connection is exposed to your agents through the fastn MCP gateway, with permissions scoped per tenant and every call audited. An agent lists open matters and the holds attached to each before summarising case coverage.

fastn does. When Google Vault changes an endpoint, deprecates a field or alters its auth, the fix lands in the connector rather than in your backlog, and your customers' connections keep working.

Only the roles the customer grants. Vault deliberately reaches content the searching user cannot open in Gmail or Drive, so access should be limited to the people who already hold that authority in the customer's organisation, and every search is logged.

Exports are asynchronous: you start one, then poll or take an event when it completes. Large matters can take a long time, so your product should treat an export as a job with a status rather than a request that returns.

A common starting point: create and list matters from your product so a hold starts where the case is already tracked. Teams also use it for the other use cases listed above, and expose it to agents for governed reads and writes.

It is included. Pricing is based on connected accounts, not on how many connectors you enable, so adding Google Vault does not change your per-connector cost. You can start free with 3 connected accounts.