Innovator Spotlight

XO Group
XO Group: APIs for Internal Communications and Strategic Partnerships

"Our API strategy is divided between internal communication and trusted partners."

Jason Sirota
Chief Architect
XO GROUP

 

XO Group Inc., formerly The Knot Inc., is a lifestage media and technology company dedicated to providing information, products, and services to couples planning their weddings and future lives together. Trading on the NYSE under "XOXO", the XO Group's flagship brand is The Knot, the Internet’s most-trafficked one-stop wedding planning solution. Other brands include: The Nest, The Bump, WeddingChannel, and GiftRegistry360.com.

Jason Sirota, XO Group’s chief architect spoke with Apigee about how XO Group is using APIs to simplify the architecture and integration of their internal systems as well as expand reach to their trusted partners.


What is XO Group’s API strategy?

XO Group uses APIs across all of our brands. We use APIs specifically for communicating internally between different platforms, mostly for data management and data movement. Some examples include our content management system that needs to access information from our tools platform or our local platform where it retrieves that information via HTTP APIs. We usually put Apigee in between those two systems to allow us to monitor and control the access between these systems at a high level.

We also use APIs for our external partners - our API strategy is divided between internal communication and trusted partners. From a technical perspective, we don’t use SOAP at all. For our API strategy, we decided to use a web-based XML or JSON over HTTP approach.

What problem were you trying to solve with your API strategy?

Our problem would manifest as we would develop a system, especially a database, and that database would over time be accessed directly by a number of applications across our enterprise. When somebody wanted to retire an application they would not realize that the database layer was actually called by a number of different applications. For example, shutting down a database would throw a major amount of errors on some part of our site. What we realized very quickly was that sharing information at the database connection level wasn’t going to scale to the eight to twelve verticals we were planning on releasing.

In 2007-2008, we experienced a quadrupling in the amount of our content. We went from having one to two vertical teams talk back and forth to each other without much problem to having eight or nine vertical teams where they all needed to exchange data, but doing so at the database level was really brittle. So we moved toward an approach to have the ability for individual teams to expose services over HTTP. The team knows that if they want to shut down that application they will also need to shut down that service.

What APIs are you exposing to your partners?

We have exposed access to our membership system to allow users to create and access membership information on some of our trusted partner sites. The other area we’ve been able to successfully expose is all of our mobile applications. For example, our mobile apps on iPhone use only our HTTP APIs to access data. The mobile development of iPhone apps is driving the need for APIs and the inter-connectedness of our verticals as mobile becomes more the focus of our business.

How do you work with Apigee’s API platform?

We put Apigee in the middle – in between the access layer and the database layer. This helps us understand what the usage patterns are for any particular platform and how that platform is being accessed. We also added the capability of adding or removing access to individual applications at the API layer and also at the action level. This allows us to say, "this set of APIs can be accessed by these applications but this other set of APIs cannot." This was very easy for us to do with Apigee. We didn’t have to develop an entire security layer because a security layer was already built in. Apigee’s API platform provides us the capability to understand where our performance bottlenecks exist. For example, when we launch access to an API from a particular application and if we notice that application is seeing significant traffic, we have the ability to easily add client-side caching. Apigee allows us to look at the inter-connectedness of our systems and be able to monitor and manage them.

What benefits have you seen with APIs?

On the business side, we look at media and the user experience. On the technical side, we focus on being able to move quickly and offer new experiences at a rate that our customers want. The big benefit for the business is not having to worry about rebuilding things. So if we create APIs as part of our standard part of our development process, we can meet the specific business needs of our partners who need access to our data. With Apigee it’s as simple as creating a key and setting up the correct access.

What is your vision for your API Program?

Our vision is to reach a state where all of our systems are built completely from APIs. We would like to be able to rebuild the front-end of a system without having to change the data platform. We want to do this in a tiered format so that we can segment our systems and build interesting user and customer experiences without having to go all the way down the stack. Our goal and philosophy for our API program is to have everything we do be exposed as a service.

 

 

INNOVATOR SPOTLIGHTS