The Seismic reporting data and APIs are provided so that you can answer critical business questions about the use of the Seismic platform. There are many types of activities tracked in the Seismic platform and we strive to provide as much information as possible to help you answer questions. This list of tables, fields, and related APIs will continue to grow to provide access to more data as well as different summaries of data to help you process more efficiently.
Intent & Usecase
The reporting APIs are built with data extraction (ETL) in mind. They are intended to allow large portions of data to be extracted to an external database/data lake/data warehouse.
These APIs are not designed to be used in high-frequency, interactive use cases.
Data Refresh SLA
The data that is available through our reporting APIs is updated no less than every 24 hours. Some tenants may experience slightly faster refresh times, but 24 hours is the standard we adhere to.
Data Dictionary
This is the most up-to-date comprehensive list of the fields offered through our APIs. Each table organizes its respective fields into themes and provides descriptions to help you understand how to answer your organization’s questions best.
Recommended Schema
Most modern business intelligence platforms require a form of star schema. For systems of this nature, the relationship model below is the recommended schema.
Details on the recommended schema can be found here.
Authentication
Every call to the reporting APIs requires an Authorization header. You can set this once for all of your API calls by clicking on the authentication icon as shown below.
The Authorization header should be set with the Bearer prefix such as Bearer eyJhbGciOiJSUzI1NiIsImtp....
Data Formats
All reporting endpoints support data output as application/json as well as text/csv. When making a request add the header Accept and set it to either application/json or text/csv
Date Filters
The vast majority of the reporting APIs provide date filters to help with extracting reporting data. APIs which do not have date filters must be extracted in full each time in order to keep remote systems up-to-date.
The date filters generally come in a few flavors:
| Type | Description |
|---|---|
| modifiedAtStartTime / EndTime (preferred for all use cases) | This is a data modifiedAt time and has no "business" meaning. It is meant entirely for machines to know what rows may have changed so that it can pull the updates and merge them into existing data sets. |
| createdAtStartTime / EndTime | This is typically not needed, but in cases where just knowing that records are created is enough and no updates are ever needed, it is acceptable for ETL system to use this filter to isolate records. |
| occurredAtStartTime / EndTime | For event-based tables this can be used to know when events happened. However, since Seismic does from time-to-time enrich historic event data with more information about many types of data including events, it is often preferrable to use the modifiedAt date filter to keep remote systems up-to-date. |