For this new interview, I’m really happy to welcome this week Duane Tharp, VP Strategic Sales & Services at Stoplight.io.
Stephane Castellani: Hi Duane, can you please present Stoplight.io in a few words?
DT: Launched in 2015 at Techstars Austin, Stoplight.io offers a wide range of API tools to thousands of developers and organizations all over the world. Our customers are all trying to solve the same problem: how to deliver automation, collaboration and quality services across a large technical organization operating in this new API-centric world.
Our customers cover the entire spectrum of API Developers including over 300 businesses like SendGrid, Chargify, Zendesk, Quicken and Blackboard.
SC: How do you address API design?
As the application architectural landscape has shifted away from monoliths to microservices, it has become clear that a team approach to an API Design involving the customer, product management, and development is crucial for success.
For API Design, modeling technology is the key differentiator of the Stoplight.io API NEXT platform which has purpose-built visual modeling tooling for OAS and JSON Schema standards. Most other “API First” design solutions are text editors with auto-completion capabilities which can be difficult to scale as OAS files grow to thousands of lines.
Because of the visual modeling technology in the Stoplight.io API Next platform, users are not required to know the details of the OAS/JSON Schema specifications, so ALL team members are able to collaborate quickly and make needed updates. Technical users who have OAS/JSON Schema experience have the freedom to edit the underlying specification directly in either their own tooling or Stoplight’s embedded real-time editor.
This approach differs from a traditional API First Design process of creating a spreadsheet or using a text editor to create OAS/JSON Schema models by hand because it fosters collaboration and increases consistency between teams.
SC: How do you address API documentation?
DT: Within the platform, companies create engaging API documentation using Stoplight.io “Hubs,” not just simplistic generated reference docs from OAS models.
Organizations can create compelling onboarding experiences for API consumers by pulling together multiple OAS definitions into a single experience with context. Each Stoplight.io “API Hub” can target multiple audiences or document different use cases. Each Hub, and the remote resource it references (like OAS files) can be versioned and worked on independently. This supports the microservice based architectures we are seeing today in our customers.
SC: How do you address API testing?
DT: Auto-generate and auto-update the contract testing of your API. Developers are being asked to test more. With Stoplight.io, developers can quickly create and automate contract tests, leveraging their OAS files, without having to learn a new language and platform. This ensures that the specification and underlying service are in sync.
SC: How do you address API mockups?
DT: Push button mocking, leveraging your OAS files, that contract tests your API while it is being developed. Simple and fast.
SC: You combine all those products into a single platform?
A: Stoplight.io’s API Next Platform uses the models for automation in each of the other aspects of the solution–documentation, mocking and testing, making users more productive. Further, the platform was designed to allow third parties to extend the product with plugins for a new capability which insulates the users from point products and vendor lock in.
SC: Which channels do you sell your product through? Online, via sales teams, via partners?
DT: Stoplight.io’s API Next Platform is available as a SaaS online product. For larger enterprise accounts, we have an on-premise installation option.
SC: What’s your pricing model?
DT: Stoplight.io pricing is free for public projects, and charges per user for private projects.
SC: Can you share with us a recent customer success story, indicating the challenges they faced and the outcomes they got with your product?
DT: Stoplight.io customers usually have an API Gateway, like Axway’s Gateway, SmartBear’s SOAPUI Testing solution for QA Teams, and Swagger UI for generated API Reference documentation. Taking an API Design First approach to microservices development is driving the need for new and improved processes and tooling to meet their needs.
SendGrid Contract Test Success Story
SendGrid actively supports SDKs across 7 programming languages, with each of these SDKs supporting 233 API calls. Sendgrid needed a way to contract test each endpoint, ensuring they didn’t break basic usability while rapidly evolving their code base to support all of the new v3 APIs, without creating custom mocking code in each testing framework.
Stoplight.io made this extremely easy with its Prism mock server, giving Sendgrid a Swagger/OAI-driven mocked version of the SendGrid API server. In this post, Sendgrid describes the specific workflows that allow them to test all of their endpoint interfaces in seconds.
Large Financial Use Case
A large financial institution has identified 400 critical business services that they would like to move to a microservices based architecture. They are using Stoplight.io’s advanced modeling technology to quickly allow their product managers to work with the API consumers in a collaborative API Design First way.
The purpose-built OAS visual modeling components in Stoplight.io minimize the need for each of the API participants in the design process to have to know the details of the OAS specification (v2, v3, future versions) which increases the number of APIs they can create with fewer errors. They are calling this process their “API Factory” and Stoplight.io is at the Design First “front end” of this factory.