SocialScrape, who uses the power of APIs to collect data from social media sites, has scaled very quickly over the last year, growing from less than a million API calls a month to 12+ million calls a month. They’re a distributed team with a non-technical founder, working in an industry that regularly has API outages. Because of these factors, it’s vital that they have access to detailed real-time metrics. Using Developer Dashboard has made it easier for them to quickly provide developer support, see which endpoints get the most usage, and improve their developer onboarding.

Chris, the founder of SocialScrape, was looking for visibility into how customers were using their product and what problems they were running into. He says, “I really didn’t want to jump into the database every day and try and figure out what queries to use for pulling metrics and data there. It all stemmed from asking, ‘okay, is there a no-code platform?’ Is there something that's visually easy for me to understand? Can I find a way to debug customer issues without asking our team of developers?”

From Docs to the Dashboard 📊

When SocialScrape initially started using ReadMe, they were purely focused on the documentation features. At the time, they were only using 3-5 endpoints total. As the number of endpoints increased, Chris was presented with a dilemma: “Do I get my developers to build out an internal metrics dashboard that’s essentially just for me?” The time commitment involved would be prohibitive, and the ROI wouldn’t exactly be phenomenal, with only one person using it. That’s when he learned about Developer Dashboard and its built-in metrics dashboard.

Now, I could actually drill deeper into the logs for specific companies. What were the error ratings like? What endpoints are most heavily used? Are we listing endpoints that we’re getting no usage from? This gives us a ton of data points that we wouldn’t have had, or would have had, but it would have taken a few developers taking the time to sit down, query something, and figure it out together — but this is literally at my fingertips. Chris, CEO

Now, they have more than 60 endpoints being pushed through ReadMe, across various platforms. The amount of data being processed through those endpoints can be challenging to keep up with, especially with the amount of outages that happen regularly on social media platforms. This makes it vital for the SocialScrape team to be able to keep a very close eye on metrics, so they can mitigate potential issues as quickly as possible.

Getting Ahead of the Curve 🚄

SocialScrape has been using ReadMe from the beginning as the business has scaled, and the Developer Dashboard features in particular have been a game-changer for them. Chris uses the metrics dashboard to help him immediately see problems:

I’ve found it to be invaluable. Looking at it, I can immediately see — do we have any outages? Are we getting 500 errors and I need to reach out to someone to fix something? Do we have certain customers going absolutely crazy with the API? It’s the first thing I check in the morning and the last thing I check at night.

SocialScrape does use endpoint monitors to make sure that uptime is okay on average, but the extra information that ReadMe provides is very helpful. The team uses it to keep an eye on what specific errors and responses are and the volume of calls coming through. With some large customers doing as many as a million calls in a matter of hours, it’s necessary for SocialScrape to be aware of their capacity and bandwidth at any given moment.

Due to the nature of their product, SocialScrape can also use the data provided by ReadMe to guide their product decisions. They start out with the endpoints that they think will be relevant to their users, and pay close attention to the metrics for each endpoint and the feedback around the endpoints. “Pretty much all of the business decisions are made by looking at who our top customers are and how they’re using the endpoints. And if it does come down to mitigating issues or outages, we need to know who the power users are, to reach out and say we’re down at the moment but trying to get everything back up as soon as possible,” notes Chris.

Elevating Customer Experience 🤩

Speaking of reaching out to customers, the team also uses the Metrics features to monitor the volume of errors and use them to flag when something is amiss. If Chris starts seeing lots of red 500s in his dashboard, he knows that he needs to figure out what’s going on. Their endpoint monitors don’t always see all of the errors — there have been instances where they’ve had an endpoint go down and haven’t received a notification, or where a 500 error is showing up as a 200 error.

That level of detail is crucial to debugging issues — without having the full request and the full response, it’s much harder to see what the issue is and fix it.

If we get something from a customer saying their API isn’t working, I’ll grab their email address, search for it in ReadMe, and check the last 10-15 requests. Using that data, I can debug something in usually about five minutes, and the customer gets a response soon after.” Chris, CEO

Being able to independently debug issues is especially helpful with a remote team, distributed across multiple time zones. The SocialScrape development team is three hours ahead of Chris, so when he sees an issue, they may already be asleep or clocked out for the day. But, even though he can’t implement any fixes immediately, he can still figure out what the issue is and communicate that to the customer (along with the timeline for it being fixed). Then, when the development team is back on the clock, they have all the information they need to fix the issue.

Having a streamlined workflow like this (and giving Chris the ability to easily debug issues himself) has helped SocialScrape scale much faster than they would have been able to otherwise. And, of course, it helps that they don’t have to build or maintain these tools, as they did consider building their documentation and metrics solution in-house. “Our team wouldn’t be able to maintain and support the endpoint, if they had to maintain and support that as well,” Chris notes. And, at the end of the day: “We’re not in the business of building docs, so if we can find a really stellar solution to do that through ReadMe, it’s a no-brainer.”