Element-Level API
Turning an internal implementation detail that power users had quietly adopted into a governed, sustainable enterprise product.
The Challenge
The Element API was never meant to be a product — it was an internal endpoint that powered Semrush's own dashboard elements. Technically sophisticated enterprise clients found it anyway, and started pulling raw platform data straight into their own BI tools. It worked well enough that a handful of accounts became heavily dependent on it.
That created a real problem: a small number of workspaces were generating the large majority of load on an API with no rate limits, no documentation, and no stability guarantees, built on internal fields that could change without warning. Left alone, it was a platform-stability risk. Locked down carelessly, it would break real, revenue-bearing integrations clients had already built their workflows around.
The Solution
I led the effort to bring this "shadow product" under control without breaking it for the clients depending on it or shutting down the demand it represented. That started with real usage data — traffic concentration, cost per request by product area, which accounts would be affected at which limits — rather than a limit picked out of thin air.
I used that analysis to define a limits strategy (daily requests, hourly burst, and data-scanned caps) that protected platform stability while keeping nearly all existing usage patterns intact, and won engineering and commercial alignment on it up through CPO sign-off. Rather than flip on hard limits overnight, I designed a phased rollout: a warnings-only period to validate the limits wouldn't generate false positives, followed by enforcement — with clients who outgrow the tool redirected toward our Standard API and a real support conversation, instead of just hitting a wall.
In parallel, I worked with engineering on the harder architectural question underneath: the API was a raw, unstable pass-through, which is not something you can safely promise stability on. Aligning the team around a path toward a stable, documented contract — without blocking the near-term rollout on that longer-term fix — was as much a part of this project as the limits themselves.
Project Details
Senior Product Manager, leading a cross-functional squad of 5 (engineering, data, design)
Semrush
Strategy through phased rollout (Ongoing)
Key Leadership Decisions
Grounding Policy in Real Usage Data
Before proposing any limit, I dug into the actual traffic and cost data: which workspaces drove volume, which drove cost, and how those two things diverged by product area. That analysis is what made the eventual limits defensible instead of arbitrary.
A Phased Rollout, Not a Switch Flip
Warnings before enforcement, real redirect guidance instead of a dead end, and an explicit exception window for the account most affected by the change. The rollout was designed to de-risk the launch as much as the limits themselves.
Aligning Engineering and Commercial Priorities
Engineering wanted this locked down for stability; the commercial side had already sold against it and didn't want to alienate paying accounts. I built the case that let both be true: sustainable limits that protect the platform while explicitly carving out room for large accounts to keep growing on it.
Treating an Engineering Risk as a Product Opportunity
It would have been easy to treat an unsanctioned internal API as a bug to squash. Instead, I built the case for governing and eventually stabilizing it as a real, monetizable product path — because the demand behind it was already real and paying.
Impact
The rate-limiting strategy protected enterprise accounts worth over $500k in MRR while avoiding roughly $10k/month in added infrastructure cost, with sign-off secured across engineering and up through the CPO. The phased, data-led rollout meant the largest, most exposed accounts had a clear path forward instead of an abrupt cutoff — turning what started as an unmanaged risk into a governed part of the Enterprise product line.