Level Up/Cybersecurity

When the Integration Component Is Part of Your Product: 18 Months Engineering an API Security Vendor's MuleSoft Policy.

For most software vendors, the engineering partner behind an integration component is invisible to customers. For this enterprise API security vendor, that partner was responsible for something customers felt every time they ran API traffic through their Anypoint estate.

Case studyCybersecurityJuly 20266 min read
dispatch://cybersecurity, api-policyCS-06
Engineering an API Security Vendor's MuleSoft Policy API security ISV
July 2026 · 6 min readCase study
Engagement snapshotCase study #6
SectorCybersecurity
TechnologyMuleSoft Anypoint
Continuous delivery18
Validated onCloudHub, RTF, on-prem

A VC-backed enterprise API security platform serves Fortune 500 companies across financial services, technology, retail, healthcare, energy and automotive. Its product includes a MuleSoft custom policy, shipped to enterprise customers, that sits on their Anypoint estate, intercepts API traffic, and feeds the relevant data into the vendor's security analytics platform.

The policy does not do the analysis. But it has to work, at performance, across every supported Anypoint deployment model, without introducing regressions when new features ship. The difference between a well-engineered policy and a poorly engineered one is the difference between maintaining a Fortune 500 customer relationship and losing it.

The risk of a shipping product that underperforms

When Ampleshift was brought in, the previous engineering partner was not meeting the bar. Policy performance was slipping. New features were slow to ship. Customer-facing support response was sluggish. Customer relationships had begun to deteriorate.

The vendor needed a partner who could take over the engineering, stabilise and improve a shipping product, and step in directly on customer support where the existing partner had been absent.

What Ampleshift took over and how

Ampleshift engaged in September 2024. The first phase was to understand the policy as it stood: its behaviour under load, the customer deployments depending on it, and the performance and feature gaps the vendor needed addressed.

Threading was optimised. Resource consumption was reduced. Load testing was introduced as part of the validation regime, not as a one-off exercise, but as a structural safeguard on every release. If a change introduces a performance regression before it reaches customers, load testing catches it. That is the right place to catch it.

New features were shipped continuously across the 18-month engagement, against the vendor's product roadmap. Backward compatibility was treated as a hard constraint on every change. The policy runs on production estates across the vendor's Fortune 500 customer base, and a regression in a new build can break a production deployment at a customer the vendor cannot afford to lose.

Cross-environment compatibility was validated across every supported Anypoint deployment model: CloudHub, RTF, on-premises. Not just the easiest target.

Engineering plus direct customer support

The part of this engagement that distinguishes it from a standard product engineering relationship is what happened beyond the code.

When the vendor's enterprise customers had problems with the policy in production: debugging questions, deployment issues, configuration problems on their Anypoint estates, Ampleshift joined the calls. The vendor's support burden eased as a direct result. Customer relationships that had been deteriorating under the previous partner stabilised.

An engineering partner who can walk an enterprise security team through a production issue on their Anypoint estate is materially more valuable than one who cannot. That is especially true when the product is a security policy and the customer is a Fortune 500 financial services or healthcare company that holds their vendors to a different standard.

Senior expertise from day one. No billing games.

A senior developer on call as the constant across the engagement. Additional resources pulled in elastically as the work demanded. A small, senior, flexible model that did not impose the rigidities of a larger consultancy.

Specialised MuleSoft custom policy expertise, Anypoint runtime depth, security domain knowledge, load-testing rigour built into the process: this is not a commodity outsourcing model. Engineering a policy for an API security vendor requires threat-model fluency, not just MuleSoft fluency. Ampleshift brought both.

Trusted with the roadmap

Across 18 months of continuous delivery, the trust deepened. By the end of the engagement, Ampleshift was trusted with free rein over the policy roadmap, making engineering decisions that would shape how the vendor's product behaved across its entire Fortune 500 customer base.

That depth of trust is not given to a commodity outsourcing model. It is earned through delivery, through judgment, and through the willingness to stand behind the work when customers need support in production.

For security ISVs whose products run inside their enterprise customers' infrastructure, the engineering partner behind the integration component is effectively part of the product. Engineering plus direct customer support is the capability model that matches. Not engineering alone.

Continue reading

Up next.

Hand-picked from the engagements we've shipped.

Want us in your next story?

Connect with us today and let's turn your integration challenges into opportunities for growth.

Book a call