How you stay current on dev technology

Interviewing SendGrid for API World 2016

SG_Logo_Full_Color_Light_Background_RGB


In preparation for the API World 2016 Conference, here at DevNetwork, we have Brandon West, Director of Developer Relations at SendGrid, talking about their API.

What services do you currently enable developers to build on via your API’s?

We have a variety of partnerships with services like Heroku, Microsoft Azure, Google Cloud Platform, etc, so developers can build on those. Reading it another way, we enable developers to build email­ related services without having to maintain their own sending infrastructure or instrument their own analytics.

What are some of the most interesting/innovative applications that developers have built on top of your API?

As a company that started off primarily as a provider of email infrastructure, most of the innovation that we enable happens farther up the stack. When engineers at companies like HubSpot don’t have to spend time maintaining email servers, they are able to focus on building innovative stuff. We’re similar in some respects to a payment gateway provider or a hosting company. What we do is a critical component to driving engagement and business growth for many companies. That said, we have seen some creative uses of our API. I met a student at a hackathon recently that was applying for jobs. He used SendGrid to send his resume out and implemented the Event Webhook to let him know when recipients were opening his emails and clicking to read his resume. He was able to follow up with the interested companies in a very timely manner as a result.

How do API’s factor into your company’s long-term growth strategy? Do you see your company becoming an “open-platform” of integrations?

Our API is still the core of our business so it’s an essential part of our long-­term strategy. We are focused on making sure we offer a world­-class developer experience, all the way from signup to implementation. When I think of a platform, I think of a multisided­marketplace (thanks in large part to Ryan Sarver’s work: https://sarver.org/2013/09/26/what­is­a­platform/). In that sense, I don’t believe we’ll be becoming an open platform soon. Certifying third­party code, finding a way to securely host it, and ensuring that it can scale to millions of requests per day is non­trivial.

Are the growth of open API standards important to your industry?

Email as an industry has always depended on open API standards to define how SMTP servers and clients interact and how messages can be defined. Open API standards for HTTP­based APIs have been a blessing because of the amount of API­related tooling they enable. We maintain an OpenAPI 2.0 spec of the SendGrid API. Being able to share this spec with developers, import it into client tools like Postman, or use it to generate tests and documentation has been a great help.  

What are some ideas for apps or integrations that developers or startups could build on your API?

We can help with everything from email address confirmations for account signups to processing inbound emails.

Do developers “mash-up” your API with other 3rd party API services? What are some interesting mashup examples?

Most companies these days use so many different APIs and SaaS platforms that I don’t think it makes sense to think of these services in a context where they are NOT integrated in some way or another. “Mashed-up” is more often than not the default mode of operation now. I’ve seen some cool mashups with Full Contact, where email addresses are enriched with social profile information before being passed on to the recipient.  

What has your team learned about building scalable, accessible API’s? What advice can you give to other teams building their own API?

An ongoing Developer Experience strategy is more important for success than how your API is designed. You have to treat your API as a product from the start. Instrument things for analytics from the beginning so you can see how developers are actually using your product. It’s impossible to validate or invalidate a hypothesis without data. Get out in the field and watch how developers use and struggle with your product. It doesn’t matter how great your API is if the documentation is terrible, or if onboarding is impossible. Sometimes none of that matters if you don’t have an SDK in a person’s perferred language. Make sure you spend time and effort communicating the concepts and value of an API to the non­technical departments within your company. Never lose sight of the fact that the API should be an interface for delivering the real value of your business. If your product isn’t valuable, generally speaking the API won’t be either.