API - Do You Use It and What For?

I’m interested to know what others use the API for.

There seems to be a really strong push for improvements in the API itself. Everything I picture using the API for should really just be included in a billing platform in the first place… so I may just be short-sighted when thinking about it. What do you use it for?

I would just look at it as a way to extend Sonar in a way that allows you to implement your own business practices or desires.

Some of the things I know people use it for:

  • Building ticketing/scheduled job dashboards for their existing NOC monitoring
  • Integrating IPAM/inventory management with external provisioning systems that aren’t part of Sonar
  • Tying Sonar into their website for lead collection, job scheduling, etc
  • Implementing external texting services to trigger events on inbound texts
  • Bridging multiple Sonar instances together to enable resellers to have their own Sonar instance, and push data into the primary instance
  • Many different types of reporting/data collection integration with third party systems

It doesn’t just have to be something to build new features though, it’s used for the customer portal, the import tool, and many other things we’ve released/built. Having a strong API is the best way to make a platform capable of doing anything you might need it to in the future, especially for bigger ISPs. You’re never going to get a system that’s capable of doing every single thing you need, especially when you start talking about very custom business logic.

1 Like

@Christopher_Gray I agree with you as a small ISP, I’ve had to hire an outside consulting firm to use the API to get some additional features. I continue to put in requests for new features as well however.

We are using the API for the portal (Sonar set this up for us) and we are using it to hook into our current CRM (although we are hoping Sonar will become the CRM we are looking for). The first iteration for the CRM, we used a recommended developer from our CRM. It worked, but was really sloppy development. We needed some improvements, so we are now using Solutions4ebiz.

We are just getting started with Sonar and we have some internal systems that we are going to be utilizing the API to interact with (mostly to do with our DOCSIS provisioning/mgmt setup). But we will also be utilizing the API to be able to push things from our other systems back into Sonar for reporting and other uses. Like Simon said, it really is just a way to extend Sonar for your use case.

I can definitely see the value in having a robust API in general. In this case, it just feels like it is taking away from time that would otherwise go toward functionality that should be included in the first place.

On the other hand, I have spent a significant amount of time laying out parts of my network and business that don’t feel like a good use of time, but I know I will be thankful in the future that those components were well thought-out in the beginning instead of waiting to do it later.

Thanks for the ideas.

It might feel that way, but it’s not true. The API just exposes underlying functionality that has to already exist for Sonar to work. In v2, the public API and the private API are the same thing, so it’s literally zero extra work!

1 Like

Nice, all of the benefit with none of the work, I like it.

At the moment we’re using Sonar as a central repository for (nearly) all our customer information. We’ve used the API to integrate with our provisioning systems (we have 3 or 4 different ones) so that as soon as a change is made in Sonar, the corresponding update is made in the provisioning system. (For example, an internet customer’s account is deactivated in Sonar, so we automatically disconnect their service.)

We’ve also used the API extensively for custom reporting. We have a wide range of customer types, so it’s nice to be able to pull the raw information out of Sonar and create specific reports for each type.

Lastly, we’ve recently made use of it to allow customers to sign up for free trials of some of our web-based services. Once the customer signs up online, a sonar account gets created for them and the integrations I mentioned above automatically provision their account in the appropriate system.

As far as improvements go, I’m really looking forward to some of the flexibility that v2 is aiming to provide. Right now it’s a bit challenging to select subsets of accounts to report on. E.g. “All accounts that were activated between Jan 15-30, 2018 and have account_type_id=5”.

I haven’t looked at the v2 spec recently, but I seem to recall GraphQL was being bandied about and that would be all kinds of fun.

It is GraphQL based, and will allow you to do exactly what you’re looking for (and a lot more.)

Awesome! I took a quick skim over GraphQL a while back and it seems ridiculously powerful, which will be great!

We do a lot of ad-hoc querying against Sonar and GraphQL will make that process much more streamlined. At the moment we actually just mirror a bunch of data from Sonar into an external SQL db (kept updated using webhooks!) so that we don’t bog down the system with hundreds/thousands of API calls per report.

We have used Sonars API for the Azure Chat bot, SMS notifications (Sending SMS on job creates, updates, etc.), and some other small stuff.

We love the API. We use it for:

  • Integrating with Slack (auto-coordinating cust serv with engineering), such as disconnects, tech support requests
  • Built a better full body text search for ticketing
  • Better filtering of open/closed tickets by group and category (greatly lacking in v1)
  • Improved UI flow of ticketing (reducing clicks for cust serv people by 50% by using Chrome Extension)
  • Automating many data functions from our server to Sonar to ensure consistent data
  • Customized portal for customers based on customer-type, and adding on to portal