RevOps

View pricing

Where it fits

Every system has a log. The artifact does not.

Clay writes the proposal. Claude writes the dashboard. n8n runs the schedule. Then the HTML they produce lands as an attachment, a screenshot, or a file in a drive folder, and the workflow goes dark at the exact moment a human starts reading. Everything else in the revenue stack has an API, a webhook, and a log. The artifact has none of them.

HTMLvault is the step in between, and it does not replace anything you already run. Clay still owns the sequence, n8n still owns the plumbing, Salesforce is still the record. It takes the HTML those systems already produce and gives it the same contract as everything else: create it over REST or MCP, patch it in place, and get a signed event back the moment somebody reads it.

Nothing changes for the recipient. No viewer to install, no account to create, no login wall between them and the thing you sent. They click a link on your domain and the page is simply there. The open comes back into your stack as a payload you can route, filter, and join to a contact by name.

INTEGRATES WITH EVERYTHING

YOUR STACK, UNCHANGEDVAULT ITYOUR BUYERYOUR DATASalesforce, the warehouse,a Clay tableYOUR TOOLSClay, n8n, Claude,already making HTMLHTMLVAULTa URL you own,every open loggedYOUR RECIPIENTopens a link,never an attachmentLINK.VIEWED FIRESTRIGGER A NEW ACTION

How it works

From automation to attribution

Step 1

Create programmatically

Your workflow calls the API, or your AI agent uses the MCP server, and gets a tracked link back.

Step 2

Patch it in place

Update a live page over the API with the diff, not a re-upload. Same slug, same URL, and the analytics history stays attached.

Step 3

Events stream out

link.created, link.viewed, link.expired, link.updated, usage.threshold. HMAC-signed to your endpoint, with retries.

Step 4

Report across the org

Account-wide analytics endpoints roll per-link data up for your dashboards and your warehouse.

Worked example · The dashboard that updates itself

One slug, patched every Monday at six.

Leadership does not want a fresh link every week. They want the bookmark to be right. So publish the KPI dashboard once and never send it again.

Every Monday at six a scheduled action pulls the numbers and sends a patch carrying only the sections that changed, leaving the rest of the document untouched. The slug survives. The bookmark survives. So does the whole view history, on one URL instead of scattered across nine attachments with nine different filenames.

Then it tells you something the BI tool cannot: which of the nine people actually opened it before standup. That is new information about your leadership team, and it arrives every week without anyone asking for it.

  • The patch sends the diff. Three sections change, three sections move. You are not re-uploading a document to correct one number.
  • The slug outlives the update. And so does the bookmark, and so does the analytics history sitting behind it.
  • Signed, logged, retried. HMAC-SHA256 on every delivery, a Postgres delivery log, and three retries with backoff if your endpoint blinks.
PATCH A LIVE PAGE IN PLACE
EVENT LOG7 EVENTS · 2 HR
TIMEStateEVENTTOOL / SOURCEDETAIL
MON06:00Step completedSchedule firesn8n, Zapier, a cronnobody has to remember
MON06:00Step completedPull the numbersthe warehouse, the CRM14 metrics, the same queries
MON06:01HTMLvault stepPatch three sectionspatch_linkthe diff, not the document
MON06:01Signal receivedEvent fireslink.updatedsame slug, same url
MON06:02Step completedAnnounce itSlack · #weekly-forecastthis week’s numbers are live
MON08:14HTMLvault stepCheck the reachget_analytics6 of 9 leaders, before standup
MON08:14Signal expectedThree to golink.viewedthe three who never open it

Use cases

Plumbing that behaves like infrastructure

  • Links that fire off deal stages

    A deal hits Proposal Sent, your automation creates the tracked link, writes it back to the record, and pings the rep. No human in the loop and no copy-paste step to forget.

    • REST API
    • API keys

  • Engagement as a pipeline source

    Webhook deliveries are HMAC-SHA256 signed, logged, and retried with backoff. Treat view events like any other source feeding the warehouse.

    • Webhooks
    • HMAC signing
    • Delivery log

  • Reps never leave the chat

    The MCP server and the GPT action are ready to install, so a rep creates a tracked link from Claude or ChatGPT without opening another tab.

    • MCP server
    • Integrations

  • Usage you can put in a budget

    Tracked views meter against a soft cap. Serving never stops, overage settles against prepaid blocks, and the alert fires at the threshold you picked.

    • Usage metering
    • usage.threshold

  • Key hygiene at org scale

    Personal keys for reps, org-scoped keys for systems. Each one is prefix-identified, revocable on its own, and carries a last-used date.

    • Org API keys
    • Key revocation

  • Joins that resolve to a person

    Per-recipient URLs mean a view event joins cleanly to a contact in the CRM. Engagement by name, not by anonymous fingerprint.

    • Recipient links
    • Analytics API

What actually changes

Five answers you stop chasing.

“somebody has to re-upload it”
one patch, same slug
“we think it got opened”
a signed webhook, seconds later
“the engagement export is manual”
view events streaming to the warehouse
“a rep pasted it somewhere”
a named key with a last-used date
“we went over and it stopped working”
overage settles, serving never stops
Also built for

Wire it into the stack this afternoon.

REST, webhooks, and MCP: documented and ready.

New linkView pricing