When Integration Matters: Building Webhooks for the Fortune 500

“Integration isn’t a feature. It’s infrastructure.”
That was the mindset shift that drove us to redesign how VersionOne talks to the outside world.

VersionOne powers product planning and agile execution for some of the largest enterprises in the world—including a significant portion of the Fortune 500. These teams don’t just manage work—they orchestrate massive systems of people, tools, and platforms.

And increasingly, those systems weren’t isolated. They needed to talk to each other.

We needed a way to let our customers know—immediately and reliably—when something changed.

So we built webhook subscriptions: a flexible, secure, and expressive system for triggering outbound HTTP calls when events happen in VersionOne.

The Problem: Agile at Enterprise Scale Means Complexity

From CRM to CI/CD, issue tracking to observability, our customers live in a constellation of tools. When something changes in VersionOne—a story moves forward, a defect is resolved, a test fails—it’s often the start of a workflow, not the end.

But prior to this effort, integration meant polling our API or building brittle connectors. That wasn’t scalable. And it certainly wasn’t real-time.

🛠️ What We Built: A Webhooks System with Enterprise DNA

This wasn’t just a wrapper around a pub/sub model. We designed webhook subscriptions to reflect the complexity of enterprise product teams:

  • Fine-Grained Event Modeling
    Webhooks can fire on two core event types:

    • AssetCreated – whenever a new object (like a Story, Defect, or Test) is created
    • AssetChanged – when any attribute of an object is updated

  • Selective Triggering
    Want to be notified for any Story status change? Easy.
    Want to know only when a Story in Project A, owned by Susan, changes status? Also easy.
    That’s possible thanks to:

    • attributes – trigger only on specific fields
    • filter + with – express rich conditions
    • userContext – respect project-level security boundaries

  • Customizable Payloads
    Select the specific fields you care about (select), and we’ll send a projection of that asset directly in the webhook’s snapshot. This keeps payloads clean, relevant, and aligned with your needs.

  • Retry Logic & Delivery Guarantees
    Every webhook includes a sequenceId, letting external systems re-order events if delivery is out-of-order. And we monitor delivery success—disabling subscriptions after repeated failures to prevent noisy integrations.

  • Authorization & Metadata
    Webhooks can be configured with an authorizationHeader to meet security requirements. Each payload includes the instigator—who made the change—with name, email, role, and more.

How It Works: From Change to Callback

Let’s walk through a real use case:

Trigger: A Story in Project X, owned by Susan, changes its Status.
Event Definition:

{
  "type": "AssetChanged",
  "from": "Story",
  "attributes": ["Status"],
  "filter": ["Scope=$Scope"],
  "with": {
    "$Scope": "Scope:0"
  },
  "userContext": "Member:1002",
  "select": ["Name", "Owners.Name"]
}

Result: A webhook is fired to the customer’s external system, with the following:

  • Who triggered it (Susan)
  • What changed (Status from "In Progress" to "Done")
  • When (timestamp + sequence)
  • Snapshot details (Story name, Owner info)

The customer system can act on that event immediately—updating dashboards, triggering workflows, notifying teams, syncing with downstream tools.

What It Enables

This wasn’t just about writing JSON to a URL. It was about unlocking modern automation inside our customers' ecosystems:

✅ Real-time sync with tools like Jira, GitHub, Jenkins, and ServiceNow

🔔 Alerting & notifications in Slack, Teams, or custom UIs

🔄 Automated workflows across QA, release management, and compliance

🔍 Improved traceability, with system-of-record updates pushed to the right people

Scaling for the Enterprise

We built webhook subscriptions with constraints—but with growth in mind:

  • Start with 5 active subscriptions per instance, but built for expansion
  • Simple, secure HTTP + token delivery model
  • Fully self-serve configuration, so teams can define their own rules
  • Backed by the same event pipeline infrastructure we trust internally

And critically: we designed this feature with a contract-first mindset. We knew customers would build systems around it, so it had to be predictable, observable, and future-proof.

What We Learned

Expressiveness is essential. Customers don’t want a webhook for everything—they want control.

Security can’t be bolted on. userContext and authorizationHeader were non-negotiable.

Observability matters. Sequence IDs, retry counts, and clear status codes help teams debug fast.

Integrations are never one-size-fits-all. The more composable your system, the more powerful it becomes in the hands of others.

🚀 Outcomes

⚡ Real-time updates in mission-critical systems

🔒 Secure, audit-friendly delivery

💬 High customer adoption, especially among enterprise customers with integration-heavy environments

🔁 Event reuse across multiple endpoints—from dev workflows to executive reporting

Our customers didn’t just want updates—they wanted awareness. They wanted VersionOne to be an active participant in their ecosystem, not just a passive database of work items.

Webhook subscriptions made that possible.

Conclusion

When you serve the Fortune 500, your software doesn’t exist in a vacuum. It lives in an ecosystem of platforms, tools, and people—each demanding awareness, context, and control.

By turning events into integrations, and changes into callbacks, we gave customers a new way to connect VersionOne to the rest of their world.

We didn’t just build a feature. We built a foundation.

Browse articles