API vs Data Warehouse

Updated August 09, 2024 04:12

TrackTik's API is the right choice for the majority of integrations due to its alignment with transactional and timing-sensitive data transits. But sometimes, a Data Warehouse solution is more practical, especially for running queries for analytics and business intelligence.

The advantages and disadvantages are generally clear, but a few can overlap. See below for our suggestions when you have to choose and are unsure.

Scenario	API	Data Warehouse	Examples
Real-time events with system-to-system triggers/notifications	GREAT. Operational API.	N/A. Fetch only.	New employee created Need to dispatch an employee Work-session started/stopped
Have a BI solution and need to export data	OK. Requires development or configuration for JSON parsing which not all BI solutions offer. By default, responses are limited to 100 records, 1000 with parameters, and pagination is required for anything above 1000.	GREAT, already in table/fields/rows indexable format.	Analytics and visualization needs not already met by TrackTik Cloud and Data Lab Adding TrackTik data to an existing aggregate Need to sync tens of thousands of records
Real-time per record sync isn't desirable, need full record sets with referrentiality preserved.	GREAT. The API offers nestable inclusion of additional JSON objects and arrays as “relation lists” from many different endpoints. It doesn’t require much domain knowledge.	GOOD. Requires domain knowledge onboarding to understand tables, fields, indexes and which should be joined on. Can’t pull binary media like images/video.	Reports and report fields. Site task schedules, site task schedule occurrences, site task schedule occurrences, sessions, and logs (phew)
A data model is simple, with integrity safety	GREAT. API responses are business context-savvy and feature actions for executing common business rules that are pre-validated and safe. GREAT for access safety becaues OAuth 2 scope + Roles/Permissions ACLs are all configurable.	GOOD for model aligned with API/business, but requires domain knowledge for relationships. GREAT for safety since it’s read-only.	Terminate employees. Approve/unapprove shifts. Export employees to import into the HR system. Report templates, Incident categories, reports, and report fields.
Feature updates/versioning	GREAT. API always has the latest features, endpoints, fields, updates, and bug fixes.	POOR. DWH configurations are static and require change requests to be updated with new data models and features.	Data format changes/expansions Field deprecations New features New data sources
Maintenance cost/risk	GOOD+. Currently, there is only one version of the API, and all past deprecations have persisted for backward compatibility. Breaking changes are infrequent, and support is always available. You will typically need to maintain engineering resources for occasional bug fixes and implementing enhancement requests.	GREAT. The configuration is the configuration. It never changes unless you ask.	New Guarding Tour and Guarding Suite features that consume the API, leading to new endpoints and features. Bug fixes. Datatype enrichment. Validation improvements. New business rule actions.
Your company is more BI-empowered, or your company is more software engineering savvy.	A software engineer’s dream.	A Business Intelligence treat.	All the data things

Articles in this section