Pulsar API

Programmatically access your Pulsar data and build BI tools for your business.

What is the Pulsar API?

The Pulsar API, (currently available in v1 and v2), is a means of connecting other tools with Pulsar in order to take advantage of what our software has to offer off-platform, as well as connect them the other way around. What precisely does this mean? Data you get from the Pulsar API is not just fed to you directly from Twitter, Facebook, or any other source.

The data you get from Pulsar API is in the same analyzed and indexed state as it can be found on the platform.

This means you can tailor the insights of Pulsar to whatever project allows you to use data like ours.

The Pulsar API was initially a very small project that allowed users to pull a handful of results and very minor search info from TRAC.

We have gone through three versions of our API, with constant tweaks and additions to now bring an entire suite of API offerings with our latest and greatest creation, the Pulsar GraphQL API.

We are in the process of fully migrating to our GraphQL API, but people who have used Pulsar API in the past are likely familiar with our REST API (which has now been sunset). Our GraphQL API offers more flexibility and functionality, as well as extending the APIs scope to include CORE, and a Pusher allowing users to upload first party data.

What Can I Do with It?

If you’re a Pulsar TRAC user, it means you can pinpoint control over the kind of data you get from the platform. More specifically, using the GraphQL API, you can:

  • Get an index of all of your active searches available on the platform

  • Get top level analysis of your search data: e.g. whole search sentiment, total engagement, total posts, etc.

  • Get more detailed counts regarding analysis: e.g sentiment for all top keywords,

    or count of posts per language for each location in your search, etc.

  • Get full results, filtered or not: e.g. all comments marked with the emotion joy, or

    posts made by males who have “gamer” in their bio, etc.

  • Upload your own first party data to be analyzed with the rest of your Pulsar data

  • Create new Searches and launch them in both realtime and with historic data

If you’re a Pulsar CORE user, the GraphQL API opens up the door for collecting CORE data off platform as well. You can:

  • Retrieve a list of all of your brands and the profiles within them, as well as the

    names of the brandsets they belong to

  • Collect filtered posts from multiple profiles within a brand: e.g. all posts from my

    Instagram, Facebook, and Twitter in Brand A that contain the keyword “sale”

  • Get collective totals from a brand or set of profiles within a brand regarding

    various metrics: e.g. total likes from across all profiles in a brand, average

    engagement for five particular profiles within a brand, etc.

  • Get special owned metric data for various owned channel types: e.g. industry

    and job type counts from LinkedIn profiles, pull video view counts from videos

    across your owned channels, etc.

Types of APIs

REST API

Pulsar's REST API is now no longer supported.

A REST API is a fixed-output sort of API, where you specify what sort of thing you need, and get the data back in a very specific way. The different things you may need are accessible via different “endpoints”. What this means in practice is that you’ll be calling multiple endpoints in order to get your final result. Think of it like a fancy restaurant.

Your courses, or calls, come in order. You get the appetizer first (searches id call), followed by your main course (searches data call), followed by dessert (results call). You can’t change the order and you can’t change the meals besides the prepackaged courses, A or B, available for that night. It’s also likely that the restaurant only serves one type of cuisine. A REST API has similar pre-baked options for you to choose from when getting results back, and they are often spread across multiple endpoints. The REST API on Pulsar, for example, requires you to query for top level search data and results from completely different endpoints. The data also must come strictly from one search per call.

GraphQL API

A GraphQL API has instead a schema for defining how the data relates to one another, and lets you not only specify what you pull with queries, but also allows you to make multiple queries at the same time.

Whereas we compared REST to a fancy restaurant with a set menu and order, GraphQL is more like an all you can eat buffet, filled with different sections of cuisine for food, where you can freely choose which types of cuisine to get every time you go back for another plate (call).

You can even get multiple types in the same call, and be very picky with what you get, allowing you to keep your calls as efficient as possible.

Why use the Pulsar API?

If you have a lot of searches running on the platform, you might want to get top-level info about all of your searches quickly.

The API allows you to run through your searches using their search hashes, and retrieve data regarding volume, sentiment, emotion, keywords, and more! Being able to run this on multiple searches in batches thanks to the GraphQL means you can accomplish this faster than ever with the Pulsar API, and it means less time clicking through pages for you and your team!

Pulsar provides data from many different sources, as well as detailed analysis of this data; it’s no surprise that many users want to get this data off platform onto their own visualizations, or to digest the information in some other manner that is unique to their needs.

While Pulsar is always working to improve the freedom of data usage on the platform, we understand that clients may want to use their data in proprietary ways that they would rather develop themselves.

For example, you might use the API to pull results data into visualizations on Google Studio, Tableau or Flourish.

The API isn’t just for pulling data from the platform; you can also use it to create searches without going on the platform, or adding data into your already existing searches.

This is especially great if you see yourself running a lot of searches quickly, and want a more structured way to establish a set of queries.

Last updated