19 · Integration recipes

Chapter 12 is the map: what exists, what each connector feeds, and how the platform is delivered. This chapter is the wrench: one recipe per connection, walked step by step from both sides, with You know it worked when as the finish line and To undo it so nothing you try is a commitment. Most recipes need the owner role; each says so.

One honest note on the identity-provider recipes: the platform side is exact, and the identity-provider side follows each vendor's standard flow, whose menu labels shift slightly between versions. Where a label differs from what you see, trust the shape of the step: create a SAML app, exchange metadata, assign people.

Before you begin

1. Know your gates. Everything in this chapter is configured by an org owner. Single sign on, SCIM, and the API are Enterprise-plan features (the plan table); the email rails, chat connections, folder watch, and desktop app are not plan-gated.
2. Know the operating rules, which apply to every connector: credentials are stored encrypted and used only server side, read-only scopes are requested wherever the source offers them, every sync lands under Recent activity on the Integrations page, connector-reported entitlement figures wait for human confirmation before they can drive an alert, and disconnecting a source stops its syncs immediately.
3. Sequence by leverage. If you are wiring a workspace from scratch: identity first (SSO and SCIM), then the cheap intake rails (email-in, folder watch), then one usage source and one spend source, then data-out. That order is argued in Chapter 12 and it holds.

Single sign on with Okta

SAML sign-on for the workspace, governed from your Okta org.

For: org owners, with your Okta administrator · Plan: Enterprise · Time: about 30 minutes including the test sign-in

Steps

1. In Okta, create the app: Applications › Create App Integration, choose SAML 2.0, and name it so your team recognizes it in their Okta dashboard (Vera AI works).
2. Open Settings › Security › Single sign on in the platform in a second tab, and copy the service-provider details the page shows into Okta's SAML settings, so the assertion comes back to the right place.
3. Back in Okta, finish creating the app and copy its metadata URL from the app's Sign On tab.
4. On the platform's SSO page, paste the metadata URL (or the metadata XML itself if your policy prefers a static copy), set your email domain, and save. Leave Require SSO off for now.
5. Assign yourself to the app in Okta and test: sign out, sign back in through Okta, and land in your workspace.
6. Assign the rest of the team in Okta, and only then decide enforcement. Turning Require SSO on makes Okta the only door for your domain, with one deliberate exception: org owners keep password sign-in as break-glass, and every break-glass sign-in is written to your audit log.

You know it worked when a teammate signs in from their Okta dashboard tile without a password and lands in the right workspace, and the sign-in appears in your audit log.

To undo it: switch Require SSO off first (never remove a required IdP's config while it is the only door), confirm password sign-in works, then remove the configuration.

Single sign on with Microsoft Entra ID

The same recipe with Entra (formerly Azure AD) as the identity provider.

For: org owners, with your Entra administrator · Plan: Enterprise · Time: about 30 minutes

Steps

1. In the Entra admin center, create the app: Enterprise applications › New application › Create your own application, choose the non-gallery option, then open its Single sign-on blade and pick SAML.
2. Copy the service-provider details from Settings › Security › Single sign on into Entra's Basic SAML Configuration (Entra calls the return address the Reply URL).
3. Copy Entra's App Federation Metadata Url from the SAML certificates card.
4. On the platform's SSO page, paste the metadata URL, set your email domain, save, and leave Require SSO off until testing is done.
5. Assign users or groups to the app in Entra, test a sign-in end to end, then decide enforcement. The break-glass rule is the same: owners keep password sign-in, audited.

You know it worked when the app appears in a teammate's My Apps and clicking it lands them signed in, no password prompt from us.

To undo it: Require SSO off, confirm password sign-in, then remove the configuration.

Single sign on with Google Workspace

The same recipe with Google as the identity provider.

For: org owners, with your Google Workspace admin · Plan: Enterprise · Time: about 30 minutes

Steps

1. In the Google Admin console, create the app: Apps › Web and mobile apps › Add app › Add custom SAML app.
2. Google shows its IdP details first: download the IdP metadata file.
3. Copy the service-provider details from Settings › Security › Single sign on into Google's Service provider details step.
4. On the platform's SSO page, paste the downloaded metadata as XML (Google's flow hands you the file rather than a URL), set your email domain, and save with Require SSO off.
5. In Google Admin, turn the app ON for everyone (or the org units that need it), test a sign-in, then decide enforcement, with the same owner break-glass rule.

You know it worked when the app shows in a teammate's Google app launcher and the sign-in round-trips cleanly.

To undo it: Require SSO off, confirm password sign-in, then remove the configuration.

SCIM provisioning and group mapping

Accounts created, updated, and deactivated by your identity provider, so your joiner and leaver process is the single source of truth.

For: org owners, after SSO is working · Plan: Enterprise · Time: 20 minutes, plus your IdP's first sync

Steps

1. On Settings › Security › Single sign on, issue a SCIM token. Treat it like a password; it is the credential your IdP will authenticate with.
2. In your identity provider, enable provisioning for the app you created above and paste the SCIM endpoint details and token.
3. Provision users first: membership must exist before group operations can place anyone.
4. If your IdP supports group push, push the groups that should map to Teams; joining and leaving a pushed group then grants and revokes that team's confidential access automatically.
5. Optionally map groups to roles: members of a mapped group get that role on every push (approver, analyst, member, or viewer), and leaving the group takes the role with it. Ownership is never assigned this way, by design; owners are promoted by owners, on Members.

You know it worked when a user created in your IdP appears on Members without an invite, and deactivating them there removes their access here.

To undo it: turn provisioning off in the IdP, then revoke the SCIM token on the SSO page. Existing accounts stay and fall back to manual management.

Vera in Slack

Alerts in the channel your team already watches, and the assistant on call in your own Slack workspace.

For: an org owner with Slack app-install rights; each person links their own DMs · Time: 15 minutes for the workspace; 2 minutes per person

Steps

1. An owner connects Slack under Settings › Connections › Integrations (it lives in the renewal and deal workflow group) and approves the install in Slack.
2. Pick the shared channel for org alerts under Notifications (the owners' webhook controls), and keep it money-critical only; a noisy alert channel trains people to ignore it.
3. Each person who wants renewals in their own DMs links once: send the Vera bot a direct message in your Slack, then flip the Chat DM toggle on the alert types you want under Notifications. The DM lane is strictly opt-in, per person, per alert type.
4. Use the assistant where the conversation is: ask Vera in Slack about a price, a clause, or a renewal, and the answer comes back with every figure tagged to its source, exactly as in the app.

You know it worked when a test question to the bot answers in Slack, and the note above the Chat DM table confirms your account link.

To undo it: disconnect Slack on the Integrations page; DM links and channel posts stop with it.

Vera in Microsoft Teams

The same capability for Teams estates.

For: an org owner with Teams app permissions; each person links their own DMs · Time: 15 minutes for the tenant; 2 minutes per person

Steps

1. An owner connects Teams under Settings › Connections › Integrations and approves it in your tenant.
2. Choose the shared alert channel under Notifications, same discipline as Slack: money-critical only.
3. Each person links their DM lane by messaging the Vera bot once in Teams, then opting in per alert type under Notifications.
4. Ask Vera in the channel or the DM; figures arrive cited, as everywhere else.

You know it worked when the bot answers in Teams and your linked account is confirmed on the Notifications page.

To undo it: disconnect Teams on the Integrations page.

The email-in rails

Five private addresses that turn forwarding into filing. The cheapest integration on the platform, and usually the first one worth doing.

For: an org owner provisions; the whole team uses · Time: 10 minutes to provision and share all five

Steps

1. On Settings › Connections › Integrations, provision the rails you want; each is one click, and each address is private to your organization and unguessable by design, so mail sent to yours can only land in your workspace:

- Contract email-in — forwarded proposals become tracked Analyst Benchmark.
- Deal email-in — forward a live vendor thread onto the deal record.
- Invoice email-in — forwarded invoices reconcile on Invoices.
- Purchase request email-in — teammates raise Requests by mail.
- Ask an agent by email — a question plus a document; the answer returns to the sender's inbox.

1. Put the addresses where people will actually find them: the team wiki, and as contacts in shared mailboxes. The invoice address belongs in your AP team's hands.
2. Send one real test down each rail you provisioned.

You know it worked when a forwarded proposal appears on Analyst Benchmark reading as its document, and a forwarded invoice shows line verdicts.

To undo it: remove the rail on the Integrations page; the address stops accepting.

Folder watch on Drive, SharePoint, or Box

Documents file themselves from the folder your team already saves into.

For: org owners, with access to the folder being watched · Time: 15 minutes

Steps

1. On Settings › Connections › Integrations, pick your platform: Google Drive folder watch, SharePoint folder watch, or Box folder import for bulk loads.
2. Authenticate with an account that can read the folder, and choose the folder. Subfolders are included, so the whole tree beneath your choice is watched. Prefer a purpose-named folder (Signed contracts) over a busy shared drive root, so the watch ingests intent rather than noise.
3. Drop one test document in and watch it arrive; from then on, saving to the folder is filing.
4. If the folder already holds an archive, press Import everything on the connection card. A background run walks the whole tree across in chunks, hundreds of files per pass, and each pass is logged under Recent activity until it reports the folder fully carried across.

You know it worked when the test file appears in your workspace and the sync shows under Recent activity.

To undo it: disconnect the watch; already-imported documents stay, and the folder is no longer read.

The desktop app, self-serve and IT-managed

VendorBenchmark Desk, the thick client: same account, same data, native window, drag-in from Explorer, Windows Hello lock.

For: anyone self-serve; IT for a managed rollout · Time: 5 minutes per machine

Steps

1. Self-serve: open Settings › Workspace › Desktop app, press Download the Desk, and run the installer. It installs per user, no admin rights needed.
2. If Windows shows a "Windows protected your PC" screen, choose More info, then Run anyway; the page documents this exact case.
3. Sign in with the same email, password, and two-factor code as the browser.
4. IT-managed rollout: because the install is per-user and needs no elevation, a managed rollout is distribution rather than packaging: push the installer through your software portal or endpoint tool and let it run in the user context. Updates are automatic after that; there is nothing to patch centrally.

You know it worked when the app has its own taskbar identity, a contract dragged from Explorer lands as an upload, and a notice-window notification arrives natively.

To undo it: uninstall from Windows Settings; it is a client, not a data store, so the workspace is untouched. Mac users take Download the Desk for Mac on the same page, one universal build for macOS 13 and later, and drag the app to the Bin to remove it.

The API quickstart

From no key to your own data coming back over HTTPS in ten minutes.

For: org owners create keys; your developers consume them · Plan: Enterprise · Time: 10 minutes

Steps

1. On Settings › Connections › API, create a key. You see the full value once, so store it in your secrets manager on the spot. Keys expire within a year.
2. Make the first call, the one that proves the loop, against the REST API at /api/v1 with the key as a bearer token:

curl -H "Authorization: Bearer <your-api-key>" \
  https://app.vendorbenchmark.com/api/v1/contracts

1. Read the JSON that comes back: your own organization's contracts, under your key's permissions, which is the whole authorization model demonstrated in one request. The connect panel on the API page carries the same snippet with your workspace's base URL filled in, plus endpoints for vendors, benchmarks, and Ask.
2. Build with the key server-side only; it is a credential, not a config value, and never belongs in a browser or a repository.

You know it worked when the response is your data, and the key's use appears in your audit trail.

To undo it: revoke the key on the API page; revocation is immediate.

Connect Claude and other MCP clients

Your own AI assistants querying your benchmark data, with your permissions, over the Model Context Protocol.

For: org owners create the key; anyone with an MCP-capable client connects · Plan: Enterprise (rides the API) · Time: 10 minutes

Steps

1. Create an API key as in the API quickstart; the MCP connector authenticates with the same key.
2. Open the Connect panel on Settings › Connections › API and pick your client. The MCP server lives at /api/mcp over HTTP transport, and the panel shows a ready-to-paste block per client.
3. For Claude Code, the panel's command is the whole setup:

claude mcp add vendorbenchmark --transport http https://app.vendorbenchmark.com/api/mcp \
  --header "Authorization: Bearer <your-api-key>"

1. For ChatGPT, other MCP tools, or your own agents, use the matching block from the same panel; the Claude API's MCP connector and the Agents SDK take the server URL and key in their standard remote-server shape.
2. Test with a question only your data can answer: "which of our agreements renew in the next 90 days?" A grounded answer with your vendors in it is the proof.

You know it worked when your assistant answers from your workspace's records, not from general knowledge.

To undo it: remove the server from the client and revoke the key; either alone severs access.

Webhooks and data-out

Your data as a citizen of your estate: events pushed to your systems, tables in your warehouse, the audit stream in your SIEM.

For: org owners, with whoever runs the receiving system · Time: 20 minutes per channel

Steps

1. Event webhooks: on Settings › Connections › Integrations, add your endpoint (your own service, Zapier, or Make). Events arrive as JSON, HMAC-signed with a timestamped signature. Verify the signature before trusting any payload; the signing secret exists so your systems can authenticate us the same way we authenticate inbound mail and CLM webhooks.
2. The audit webhook: point it at your SIEM and the audit log streams continuously instead of being exported quarterly. Security teams should prefer this to CSV pulls.
3. Warehouse export: connect Snowflake or BigQuery and the contracts, renewals, savings, and spend tables land where your analysts already work.
4. Send a test event end to end before declaring any channel done, and alarm on signature failures rather than dropping them silently; a failing signature is either misconfiguration or someone knocking.

You know it worked when a real event arrives, its signature verifies, and your receiving system acted on it.

To undo it: remove the endpoint or disconnect the export; delivery stops immediately.

Related: The integration catalog · Integrations (settings reference) · Connect your data and close the gaps · The owner's handbook

Next: Chapter 12 · Integrations, clients & deployment for the architecture behind these recipes.