How We Use to Test 233 API Endpoints in Seconds

How We Use to Test 233 API Endpoints in Seconds

Product, Technical

SendGrid actively supports SDKs across 7 programming languages, with each of these SDKs supporting 233 API calls. We needed a way to test each endpoint, ensuring we don’t break basic usability while rapidly evolving our code base to support all of our new v3 APIs, without creating custom mocking code in each testing framework. made this extremely easy with its Prism mock server, giving us a Swagger/OAI-driven mocked version of the SendGrid API server. In this post, we will describe the specific workflows that allow us to test all of our endpoint interfaces in seconds rather than minutes.

The first stop on this journey is the documentation tools. For us, this was the most tedious part of our challenge, as we had 233 API calls to document. However, we were able to speed up this process dramatically by using’s discovery tools. We simply proxied through and browsed around and automatically began documenting our endpoints. Then we used the API Design tools, depicted below, to refine our definitions.


Once we completed the documentation with our final touches, using the pleasurable interface references above, we were able to export a Swagger/OAI definition of our API with the click of a button.

For example, here is a snippet of the SendGrid Swagger/OAI definition that highlights the GET call on our /user/webhooks/parse/settings endpoint (Imagine having to write and manage this, especially at scale!):

Next, we created an SDK automator in-house (stay tuned, we will explore this topic in a future post) that builds documentation, examples, and test API calls for all of the endpoints across all 7 SDKs using the generated Swagger/OAI definition. These tests simply make an API call and checks for a correct response. Without Prism, we would have needed to mock all of those calls.

Here is what creating a basic mock server looks like in Java, and this is not even a realistic example as we still need to define all the expected responses based on the incoming endpoint and its parameters:

After installing Prism and pointing it to our Swagger/OAI file, we were able to run our local tests against a local mocked server and their hosted service.

Today, we can have code like the following for our tests, without needing to create a custom mock function, making it very easy to do a quick system health check across all of our endpoints and SDKs:

Even with all this progress, there was still one more problem! Within Travis CI, we were using the hosted service for the 233+ tests. With so many tests, this was taking longer than we would like and unnecessarily taxing’s servers.

So, Tom, Engineer, once again demonstrated outstanding customer service and created a script that automatically installs Prism onto Travis CI, runs the mocked server, executes the tests and then shuts down the server. This also works locally with the added benefit of automatically determining the appropriate version of Prism for your OS, allowing you to get your development testing environment up and running without even a single click.

Now that we have an easy way to mock out a SendGrid server, the door is open to other use cases, such as the ability to mock out your interface to SendGrid and perform all of your integration testing and prototyping before using a single SendGrid credit.

We would love to learn how you are planning to use the ability to mock out SendGrid’s API servers. Share with us on Twitter, LinkedIn, or Facebook.

More Posts by Elmer
Elmer Thomas is SendGrid's Developer Experience Engineer. His mission is to help SendGrid live up to its slogan: "Email Delivery. Simplified" by improving the lives of developers, both internally and externally. Via all sorts of hackery, of course. Follow his exploits on Twitter and GitHub.
Follow Elmer