Stephane Castellani: Hi Duane, can you please present Stoplight.io in a few words?
DT: Launched in 2015 at Techstars Austin, Stoplight 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.
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 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 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 “Hubs”, not just simplistic generated reference docs from OAS models.
Organizations can create compelling on-boarding experiences for API consumers by pulling together multiple OAS definitions into a single experience with context. Each Stoplight “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, 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’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 3rd parties to extend the product with plugins for 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’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 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 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’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 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 is at the Design First “front end” of this factory.
SC: Can you share with us your product presentation video?
DT: Sure, here are some of them:
- Stoplight vs. SwaggerHub – The power of visual modeling vs. a text editor
- Stoplight API NEXT OpenAPI Modeling: Introduction
- Stoplight API NEXT OpenAPI Modeling: Using $refs / Model Sharing
- Stoplight API NEXT OpenAPI Modeling: Inheritance
- Stoplight API NEXT OpenAPI Modeling: Common Library
SC: Thank you Duane for this conversation. I wish you a lot of success for Stoplight.io and its customers.