If you're distributing software through the Replicated Enterprise Portal, you already have a built-in path for getting your software into customers' hands. However, to recognize revenue under ASC 606, vendors also need to be able to report the timeframe when the software was transferred to customers.
The specific timeframe you use for revenue recognition depends on your company's policy and your auditors. Some of the most common definitions include when access to the software was provisioned, when the customer first accessed it, when the software was first downloaded, or when it was confirmed running in their environment.
Over the past quarter, we've shipped a set of capabilities that make it possible to track each of these milestones. With the latest updates to Replicated's event notification system and the customer API, vendors can report on the full customer lifecycle: from when the Enterprise Portal invitation was sent, to the moment the software is up and running in the customer's environment, and several other milestones along the way. It's also possible to connect the Vendor Portal to Salesforce (or HubSpot, or Attio) programmatically so that the right data flows to the right people automatically.
This post walks through what's available, how the pieces fit together, and how to start integrating them into your revenue workflows.
What's new
Enterprise Portal access lifecycle tracking
You now have full programmatic visibility into your customer's Enterprise Portal access lifecycle, from invite sent through first software pull. Three new notification events cover the key moments:
- Invite sent - when an Enterprise Portal invitation is sent to the customer
- Access granted - when the customer first gains access to the Enterprise Portal
- User joined - when a user joins the Enterprise Portal
You can subscribe to each of these via webhook or email through the Vendor Portal. You can also use the customer API to query the timestamps for each event.
The critical detail for revenue recognition: milestones are tracked per license type. So, if a customer first activates on a trial and later converts to paid, the "first access" and "first pull" events fire again for the paid license type.
This means that you're not recording the moment they first accessed a trial as your proof of delivery for a paid contract.
Here's what the API response looks like for a customer who started on a trial and converted to paid:
[.inline]curl -s -H "Authorization: $REPLICATED_API_TOKEN" \[.inline] [.inline]"https://api.replicated.com/vendor/v3/app/$APP_ID/customer/$CUSTOMER_ID" \[.inline]
[.inline]| jq '.customer.enterprise_portal'[.inline]
[.inline]{[.inline]
[.inline]"enabled": true,[.inline]
[.inline]"first_invite_sent_at": "2026-03-01T14:30:00Z",[.inline]
[.inline]"access_granted_at": "2026-03-01T15:12:00Z",[.inline]
[.inline]"access_method": "invite",[.inline]
[.inline]"total_active_users": 3,[.inline]
[.inline]"first_software_pulled_at": "2026-03-01T15:45:00Z",[.inline]
[.inline]"first_software_pulled_asset_type": "helm_chart",[.inline]
[.inline]"first_software_pulled_asset_version": "1.4.0",[.inline]
[.inline]"access_milestones": {[.inline]
[.inline]"trial": {[.inline]
[.inline]"access_granted_at": "2026-03-01T15:12:00Z",[.inline]
[.inline]"access_method": "invite"[.inline]
[.inline]},[.inline]
[.inline]"paid": {[.inline]
[.inline]"access_granted_at": "2026-03-15T10:00:00Z",[.inline]
[.inline]"access_method": "saml_jit"[.inline]
[.inline]}[.inline]
[.inline]},[.inline]
[.inline]"software_pull_milestones": {[.inline]
[.inline]"trial": {[.inline]
[.inline]"first_pulled_at": "2026-03-01T15:45:00Z",[.inline]
[.inline]"asset_type": "helm_chart",[.inline]
[.inline]"asset_version": "1.4.0"[.inline]
[.inline]},[.inline]
[.inline]"paid": {[.inline]
[.inline]"first_pulled_at": "2026-03-15T10:30:00Z",[.inline]
[.inline]"asset_type": "helm_chart",[.inline]
[.inline]"asset_version": "1.5.2"[.inline]
[.inline]}[.inline]
[.inline]}[.inline]
[.inline]}[.inline]
To pull just the paid milestones for revenue recognition:
[.inline]# When did the customer first access the Enterprise Portal on a paid license?[.inline]
[.inline]curl -s -H "Authorization: $REPLICATED_API_TOKEN" \[.inline]
[.inline]"https://api.replicated.com/vendor/v3/app/$APP_ID/customer/$CUSTOMER_ID" \[.inline]
[.inline]| jq '.customer.enterprise_portal.access_milestones.paid.access_granted_at'[.inline]
[.inline]# When did the customer first pull software on a paid license?[.inline]
[.inline]curl -s -H "Authorization: $REPLICATED_API_TOKEN" \[.inline]
[.inline]"https://api.replicated.com/vendor/v3/app/$APP_ID/customer/$CUSTOMER_ID" \[.inline]
[.inline]| jq '.customer.enterprise_portal.software_pull_milestones.paid.first_pulled_at'[.inline]
If the key is absent or null, the customer hasn't hit that milestone yet for that license type. The [.inline]access_milestones[.inline] and [.inline]software_pull_milestones[.inline] maps are keyed by license type ([.inline]trial[.inline], [.inline]paid[.inline], [.inline]community[.inline], [.inline]dev[.inline]), so you can check any combination.
Auto-invite on customer creation
You can now opt in to automatically sending an Enterprise Portal invite when a new customer is created with an email address. This removes a manual step that vendors reported their teams routinely missed, leaving customers without the access they needed. With this toggle enabled, every new customer gets an Enterprise Portal access invite as part of customer creation, streamlining the onboarding flow.
This is especially relevant for vendors automating customer creation from their CRM. If your Salesforce integration creates a customer via the Vendor API when a contract is activated, enabling auto-invite means the customer gets access to your software immediately; no separate manual step required.
Vendors who prefer a more hands-on invite process can leave it off.
Self-serve signup lead qualification
Two new self-serve signup capabilities give you more control over who enters your trial funnel, and what information you collect from them when they do:
- Custom signup fields let you add text fields (e.g. job title, company size, use case) to the self-serve signup form. Submitted values are included in the [.inline]customer.pending_signup[.inline] webhook payload, the pending signups table in the Vendor Portal, and email/Slack notifications. This means your CRM automation can enrich the lead record at creation time, before anyone on your team has to touch it.
- Email domain filtering lets you block consumer email providers (gmail, yahoo, outlook, etc. with a built-in preset) or restrict signups to specific company domains. Blocked users see a generic error that doesn't expose your filter rules. This reduces noise in your trial pipeline so your team spends time on real prospects.
Both are configured per-app in the Vendor Portal under Enterprise Portal settings and default to off.
Instance Ready and Instance Upgrade Completed events
Two new notification events let you distinguish between "a customer started an install or upgrade" and "it actually succeeded":
- Instance Ready - fires when an instance is confirmed up and healthy for the first time after initial install
- Instance Upgrade Completed - fires when an instance is confirmed up and healthy after upgrading to a new release version
Previously, the Instance Upgrade event fired on first telemetry with a new version, before the app was necessarily healthy. Vendors had no way to know if an upgrade actually completed without manually checking. These new events make it possible to trigger post-deployment workflows (onboarding outreach, success team notification) only after confirming a successful install or upgrade of your software is reporting back as ready, and not just that one was attempted.
For tracking the customer’s lifecycle, Instance Ready is particularly useful. In online installations, this event gives you a programmatic signal that the software is successfully running for the first time on that instance, not just that it was downloaded. Depending on how your team defines delivery, this could be another valid recognition milestone.
Event notifications with webhook delivery
All of these events are delivered through the new event notification system (currently in beta, no opt-in required). If you're not familiar with it yet, the short version: you set up subscriptions for the events you care about, scope them with filters (application, customer, channel, license type, custom license field values), and route them to email or a webhook endpoint.
For revenue workflows, the webhook delivery is what makes this actionable. When an event fires, your automation can receive it, update your CRM, and trigger an internal workflow or record a timestamp, all without anyone logging into the Vendor Portal.
Learn more about event notifications here.
Timestamps to use for revenue recognition
The specific timestamp you use for recognition depends on your company's policy and your auditors. The platform now covers the most common definitions:
- "When access to the software was provisioned" - [.inline]first_invite_sent_at[.inline] (queryable via API, subscribable via webhook)
- "When the customer first accessed it" - [.inline]access_milestones.{license_type}.access_granted_at[.inline] (queryable via API, subscribable via webhook)
- "When the software was first downloaded" - [.inline]software_pull_milestones.{license_type}.first_pulled_at[.inline] (queryable via API, subscribable via webhook)
- "When it was confirmed running in their environment" - Instance Ready event (subscribable via webhook)
You pick which one applies to your policy.
Putting it together: connecting the lifecycle across systems
These capabilities are most valuable when you connect them end to end. Here's what that looks like in practice, tracking the customer lifecycle from trial signup to paid conversion:
- A prospect finds your product and signs up for a trial through a self-service signup experience you've configured on your Enterprise Portal. Domain filtering ensures only signups from valid company email addresses get through. They verify their email and get access to the portal and your software.
- The [.inline]customer.pending_signup[.inline] event fires when the prospect submits the signup form. Your webhook automation creates a lead in your CRM at signup, pre-populated with the custom field values the prospect submitted (job title, company size, use case, or whatever you configured). When they verify their signup code, the [.inline]customer.created[.inline] and [.inline]customer.ep_user_joined[.inline] events fire. Your CRM converts the lead to an account and opportunity, already enriched with qualification context, no manual data entry required.
- As the customer engages (downloading releases, creating instances, upgrading), those events flow into your CRM as engagement signals. Your sales team sees activity without leaving Salesforce.
- The deal closes. Your CRM automation calls the Vendor API to convert the trial license to paid and update entitlements.
- The customer accesses the Enterprise Portal on their paid license. The [.inline]access_milestones.paid.access_granted_at[.inline] timestamp is recorded. When they pull software, [.inline]software_pull_milestones.paid.first_pulled_at[.inline] is recorded. These are your revenue recognition evidence points, specific to the paid license type.
- Instance Ready fires when the software is up and healthy. This is another potential recognition milestone, and a signal for your customer success team to begin onboarding outreach.
A reference implementation with Salesforce
Chuck D'Antonio from Replicated has built and demoed a full reference implementation of this integration with Salesforce. He walks through the full bidirectional flow:
- Replicated to Salesforce: webhook notifications from Enterprise Portal events create leads, convert them on login, track instance activity as engagement signals, and record activation dates on orders for revenue recognition.
- Salesforce to Replicated: contract activation triggers customer creation via the Vendor API, with license entitlements mapped from the Salesforce product configuration.
The code is available in his GitHub repository as a reference implementation.
There's no turnkey Salesforce integration in the Replicated product today. Every vendor's Salesforce is different, with different objects, different workflows, different automation. The mappings often have to be hand-crafted. What we do offer is the API surface and event system to make it possible, a working reference implementation to start from, and we will absolutely pair with you to help you get it set up. If this is something your team wants to pursue, reach out to your account team and we'll connect you with the right people to make it happen.
While the reference implementation uses Salesforce, the same patterns work with any CRM that can receive webhooks and make API calls. HubSpot, Attio, and others all support this.
As Chuck put it in his demo: "The people who need to think about it from the perspective of delivering the software, they have the Replicated Vendor Portal. And the people who are more revenue oriented, they have the system that they're always in."
The goal is to make sure those two systems talk to each other.
Where to start
- Configure your signup funnel. If you're using self-serve signups, set up domain filtering to keep your pipeline clean and add custom fields to capture the qualification data your sales team needs. This pays off immediately when you connect webhooks to your CRM.
- Start with the API. Query the [.inline]enterprise_portal object[.inline] on a customer you know has Enterprise Portal access. See what milestones are already populated. This gives you a feel for the data before you build anything.
- Set up a webhook subscription. Subscribe to the Enterprise Portal events and point them at a logging endpoint. Watch the payloads come through as you walk through the trial signup flow.
- Talk to your finance team. Figure out which moment they define as "delivery" for ASC 606 purposes. Map that to the specific timestamp or event from the list above.
- Look at the reference implementation. Even if your CRM isn't Salesforce, Chuck's repo shows the patterns for receiving webhooks, calling the Vendor API, and connecting the two systems.
Reach out. If you want to build this integration, we'll pair with you on it. Talk to your account team or connect with us directly in Slack.