Building A New Developer Program From The Outside In
By Laura Klemme, Su Kyeong Ku, Manoj Gaddam, Anand Komarraju & David Timby
--
Ever wonder what it would be like to take a massive cargo ship and turn it into a speedboat? Well, we can tell you (metaphorically speaking).
At StubHub, we just unveiled our brand-new Developer Program. At the heart of the program is an online portal that provides our business partners, system integrators and third-party developers an entirely new set of application programming interfaces (APIs) to bring innovative ticketing solutions to fans of all stripes.
The APIs offer something that’s in high demand these days: simplicity.
We’ve made it simple for developers and sellers to rapidly integrate with our platform — and we did it by rebuilding the developer experience from the ground up. This new program, which we developed over the course of a year, has already made available to our partners an entirely new set of APIs that address key business processes like event cataloging, inventory management and order management.
Four key features of the new StubHub Developer Program include:
- API experience that reflects our customer journey and was built from the ground-up by taking an outside-in approach.
- Self-service: Developers are now able to get going faster than before. They can create apps with products they want to use and try them out right on the portal.
- Faster onboarding: StubHub now offers a new seamless process for registration — creating API tokens, tiers and subscriptions — accelerating the partner onboarding process from approximately one month to less than 24 hours.
- One-stop API access: StubHub’s API product catalog now houses all APIs in one centralized location with the latest documentation, sample code and reporting metrics.
We knew from the beginning that recreating our APIs was going to be a hard engineering problem to solve, especially when we have billions of dollars in ticket inventory for sale annually on our platform.
Quickly, we realized the smartest way to tackle this problem was by taking an outside-in approach.
Understanding the Problem
What we set out to build was a one-stop shop portal for all types of partners. This was going to be a platform of choice for third-party tool providers and developers, powered by a best-in-class portfolio of APIs that allow for quick self-service integration and world-class support.
To know how to build this, we first had to understand the limitations of the old system.
Professional sellers and commercial partners rely on our APIs to do several e-commerce transactions on StubHub. These APIs hold tremendous value — a significant percentage of the ticket supply on StubHub comes from sellers using these APIs.
Until recently, integrating with these APIs was painful for both our partners and for us. The most significant challenge was due to the lack of a self-service functionality. There were other notable pain points our partners were experiencing as well, like point of sale (POS), third-party tool providers and large brokers.
Among them, there was a lack of governance for API subscriptions. We were hearing from some of our biggest partners that their inventory was not making it to our site.
Complicating matters was the fact that we had not one but four developer portals to maintain for different types of partners. We had initially created a small team to “firefight’” the issues that were happening on a regular basis. This team walked our partners through the bugs and escalations that they brought to our attention. The more we did this, the more it sank in that firefighting alone wasn’t sustainable in the long run.
The quality of response of our API support team was impacted due to the high volume of inbound support calls from partners. There was low partner satisfaction because of the long turnaround times for support. Despite our firefighting, we were actually losing 2% of our inventory per month. The excessive use of our system resources, due to inefficient integrations, led to several high-priority system downtimes.
Needless to say, we had big issues to fix, and we realized that taking a customer-centric, outside-in approach in designing the new API product lines was the best operating principle.
Seeing It from an Outsider’s POV
We put this philosophy into motion by first interviewing some of our 100 partners. In the past, our primary reason for communicating with one another was about tech issues and challenges. Clearly, that isn’t the best basis for a strong relationship. Instead, we wanted to maintain regular communication to ensure our partners were being heard.
What we learned from them was invaluable: The onboarding process was confusing and time-consuming (the average time being 30 days). There was an average of 20 service requests until successful seller deployment. We learned we had to make the customer experience easier and had to give our partners more autonomy. In building our new Developer Program, we wanted to achieve the following:
- 24 hours to onboard and start integrating.
- Provide useful analytics and diagnostics for our users on the portal.
- Have a standardized and seamless process to approve quota and API requests within 24 hours.
- Split APIs into product lines based on use cases.
A key element in this transition was partnering with Google’s Apigee to get the program off of the ground. Specifically, we worked with their Day 0 Engagement team using the SPRINT framework — a strategy that typically aims to solve big problems and test new ideas in just one week.
In that first week, we were able to achieve these important steps:
- Identified multiple major pain points within the partner onboarding path.
- Defined our MVP & MVBO.
- Defined a path moving forward to create a new self-service developer portal.
- Defined set of API products that directly address the pain points defined in Sprint 0.
- Defined registration and login (back end and front end).
- Defined architecture and security issues.
We followed this with three “sprints” of work over the course of seven weeks that eventually culminated in these achievements:
- End-to-end architecture defined
- Infosec and security enterprise team approvals started
- One API functioning end-to-end
- Company/account integration, custom approval flows, interactive API documentation and full StubHub branding
- Redefined account tiers
- Alignment on industry best practice
The Day 0 approach and subsequent sprints ultimately improved company/account integration. These sprints helped us streamline custom approval flows and provided interactive API documentation.
The New Architecture
In structuring this new portal, we made the following adjustments from this:
…to this:
As evidenced in the above diagram, we made a series of pivotal modifications that incorporated the feedback we received from our partners to create a new architecture that would improve their overall user experience:
- Decentralized gateway that allows us to focus on the partner experience, independent of other internal API consumers. This also enabled us to tune/optimize for our partner needs and reduced ~270 APIs to 40–50 APIs organized in six product lines. Now APIs are easy to discover, more intuitive, targeted for the varied needs of these partners in the ticketing ecosystem.
- Introduced BFF patterns to minimize dependencies between teams; affords each experience to have swim lanes preserved from other teams.
- MVP façade layer in our datacenter, with the goal to move it into the cloud in the next phase — without any customer impact.
- StubHub Identity platform with the ability to support any Open ID solutions used by our partners (Future).
- Isolated Partner traffic to ensure other StubHub experiences are not impacted.
- A developer portal that hosts APIs and their documentation, widgets & SDKs, and analytics to provide insights into our partners’ integration with StubHub.
We tapped developers from 1Ticket and Ticket Attendant as beta users early on in the development process and they were successfully able to migrate to the new StubHub listing and pre-delivery APIs. They found the integration more efficient and the experience less painful.
The fact we got to this point is a testament to our ability to solve multiple pain points, to address partners’ specific needs and to ensure that integration is more efficient. This efficiency translates to an enhanced and improved experience for our customers. Because when partners can integrate more seamlessly, the StubHub marketplace delivers a more robust inventory for our fans.
We achieved this through experimentation and by employing new ways of working. Most importantly, we did so without slowing down StubHub’s modernization journey.
Learn more about the many talented contributors from this article: Laura Klemme, Technical Program Manager; Su Kyeong Ku, User Experience Designer, Enterprise; Manoj Gaddam, Product Manager; Anand Komarraju, Engineering Lead, and David Timby, Sr. Manager of Supply Business Operations.
Interested in working on projects like our new developer program? Come join us.
