Live Data APIs

Live Data provides APIs for all user-facing functionality -- your use case will dictate which API is best for you. This page describes the APIs at a high level and provides general API philosophy and guidance. But before we get started...

💡

You probably shouldn't be using our APIs to get people data!

Our name is Live Data for a reason - our records change frequently - every time we detect a job change. Due to this, the most effective way to get people data from us is by setting up a Stream. This allows you to receive data from us when we detect a change you care about - either by tracking specific people you care about, or by matching criteria you provide relative to peoples' jobs or companies/industry profiles.

After reading the above, please note that you can still use our APIs to get people data, it's just not the best way to interact with us.

Additionally, APIs are available for all administrative tasks and for configuring data streams.

The Live Data API Family

Identity API - Provides core identity and access management capabilities, including user management, invitations, logins, etc. When using our APIs, you'll interact with the Identity API to get session credentials, usually using service accounts associated with your organization.

Ledger API - Ledgers provide you with the ability to upload contacts you care about to ensure they are being tracked by Live Data and to provide update streams about each individual. Use Ledgers when you have a list of specific people that need to be tracked (i.e. from a CRM, contact list, etc.).

People API - This set of endpoints provides direct access to the Live Data Warehouse and the full person objects. You can search for individual people or for people that match a broad set of search criteria across peoples' personal, job, and company data. This API is best used for refining search criteria that can be used to set up a Stream.

API Changes and Versioning

Our general approach is to maintain as few API versions as possible, introduce as few breaking changes as possible, and continually evolve and grow the functionality of our APIs. In terms of API versioning, we will generally make very few new versions and when we do, it will be considered a major API version change (i.e. from v1 to v2). We only create a new API version for major changes that affect our processing or your usage of the API. Below are some examples of the types of changes that may happen, and whether they will normally be associated with a major version change:

Guarding against API changes

We understand that the last item in particular on the "will NOT" list can be problematic for some consumers. However, we are continually evolving and enriching our data models and want to be able to move fast to provide you new valuable data points. For any endpoint that returns core data that we are likely to improve over time, a return_fields parameter can be provided to ensure that any new fields are not returned unexpectedly. This primarily applies to the People Search endpoint and the Ledger Contact Search endpoint.