The holistic.dev API is organized around REST with JSON request and responses and uses standard HTTP response codes.
The current API status is BETA. Minor changes are possible before leaving this status. After fixing the state, JSON-schemas will be published, with a description of the formats of requests and responses
Authentication
The holistic.dev API uses API key to authenticate requests. You can view and manage your API key in the Account Settings.
The holistic.dev APIs is a REST-based service. Subsequently, all requests to the APIs require this HTTP header:
x-api-key:Your API key
Content type
The holistic.dev APIs is also a JSON-based service. You have to add Content-Type HTTP header to all your requests:
Content-Type: application/json
URL and API versioning
Only one API version is operating at this time. Use this base URL for your requests:
https://api.holistic.dev/api/v1
Responses
All responses are JSON-based and follow one of these formats:
Http codes and error message you can find at Errors section
Projects
The project represents one database. Each project has a name and database type. Each project can contain multiple environments (development, test, stage, production) and various version control system branches.
Multiple environment and multiple branches will be avalible soon.
At this time, holistic.dev support only PostgreSQL syntax. We have implemented the last original parser from PostgreSQL 13. So, we support modernist PostgreSQL features.
PostgreSQL's syntax includes all standard SQL syntax, so, quite possibly, you can parse queries written for other RDBMS - Mysql, MSSQL, ORACLE, and more. But all analyzer rules aim to find specific PostgreSQL behavior.
DDL can contain multiple files. Each of them can include a lot of DDL statements. All unknown or syntactically incorrect statements will be ignored.
DML can contain only one DML statement. All other statements will be ignored. DML can contain one of the following parameter syntaxes:
Warning!
Parameter as question mark not supported!
Database schema (DDL)
DDL, aka Data Definition Language, is an SQL subset that includes CREATE, ALTER, and DROP statements. It uses to define database structure. Also, can include DML statements with extension's commands like create_hypertable() from TimescaleDB. All supported extensions you can find in the extensions list.
Knowledge about database structure is the critical requirement for SQL-queries static analysis. We require to upload the database structure described in DDL syntax before process any DML queries.
Extract DDL from database
If you store database schema in your version control system, you can directly upload it for any project.
DDL can contain multiple files, and we store it as is for better navigation.
In case you have not DDL synchronized with production database in your version control system, you should extract DDL directly from target database:
database parameters:
<pg-password>
<pg-host>
<pg-port>
<pg-username>
<pg-db-name>
pg_dump utility knows nothing about extension's necessary routines. E.g., commands like create_hypertable() from TimescaleDB you should add by yourself. We recommend storing it in a separate file and upload both.
Upload DDL
ddl
POSThttps://api.holistic.dev/api/v1/ddl
Upload brand new ddl or replace existing ddl with new version
Headers
Name
Type
Description
x-api-key
string
your api key
Request Body
Name
Type
Description
project.name
string
project name (case insensitive)
ddl.version
string
any string version for history navigate (case insensitive, can be null)
files
array
array of objects
{
"name": "<filename:string>",
"source": "<sql-source:string>"
}
<sql-source:string> is base64 encoded or not
Example:
base64 argument -w0 need to prevent formatting result at Linux-based os
All files of the previous version will be replaced, even if their number does not match the number of files of the new version.
We store the history of all schema changes for future features.
Also, you can copy bash script with credentials from project card from project list inside client area:
Project card -> "Copy info" button
Patch DDL
ddl
PATCHhttps://api.holistic.dev/api/v1/ddl
Patch existing ddl with new DDL commands
Headers
Name
Type
Description
x-api-key
string
your api key
Request Body
Name
Type
Description
project.name
string
project name (case insensitive)
ddl.version
string
any string version for history navigate (case insensitive, can be null)
source
string
DDL source code
can be base64 encoded or not
Example:
Patch existing DDL with new DDL commands. This source will be attached at the end of the existing DDL in a separate file. DDL and ALL project DMLs will be re-parsed after this.
DML, aka Data Manipulation Language, is an SQL subset that includes SELECT, INSERT, UPDATE, and DELETE statements.
Upload DML
dml
POSThttps://api.holistic.dev/api/v1/dml
Upload brand new dml or replace existing dml with new version
Headers
Name
Type
Description
x-api-key
string
your api key
Request Body
Name
Type
Description
project.name
string
prooject name (case insensitive)
ddl.version
string
any string version for history navigate (case insensitive, can be null)
dml
object
{
"name": "<filename:string>",
"version:"<version:string>"
"source": {
sql: "<sql-source:string>"
}
}
<version:string> can be null
<sql-source:string> is base64 encoded or not
Example:
base64 argument -w0 need to prevent formatting result at Linux-based os
We store the history of all schema changes for future features.
Also, you can copy bash script with credentials from project card from project list inside client area:
The pg_stat_statements and pg_stat_monitor modules provides a means for tracking execution statistics of all SQL statements executed by a server.
The holistic.dev API can process whole pg_stat_statements/pg_stat_monitor snapshot at one request.
Exporting the pg_stat_statements/pg_stat_monitor content is the most comfortable, most flexible, and secure way to organize the automatic export of SQL-queries from Postgresql. This extension is easy to configure for both on-premise installations and cloud providers: AWS, GCP, AZURE, ALIBABA CLOUD, DIGITAL OCEAN, YANDEX CLOUD, SBER CLOUD and others.
pg_stat_statements and pg_stat_monitor can be disabled by default. You should execute the following command to activate it:
Privacy
pg_stat_statements and pg_stat_monitor extensions normalizes query entries. Normalization is a process whereby similar queries, typically differing only in their constants (though the exact rules are somewhat more subtle than that) are recognized as equivalent, and are tracked as a single entry. This is particularly useful for non-prepared queries.
The normalization process intercepts constants in SQL statements run by users and replaces them with a placeholder (identified as a dollar mark with number).
For this reason, all data values that were used in SQL-statement will be blacked out and will not be visible at holistic.dev
But normalization has another side.
When normalizing the parameters of functions and expressions, it is quite often impossible to define the type of result unambiguously. For example, the addition operator has 42 types of its arguments, and the normalized querySELECT$1 + $2 can return 20 different response types. Such ambiguity negatively affects the analyzer's accuracy. The result of this will be less accurate analysis results - some rules will not be applied.
Upload pg_stat_statements or pg_stat_monitor snapshot
Headers
Name
Type
Description
x-api-key
string
your api key
Request Body
Name
Type
Description
pgss
string
json string (base64 encoded or not)
project.name
string
project name
base64 argument -w0 need to prevent formatting result at Linux-based os
holistic.dev parameters:
<your-api-key> - your account api key
<project-name> - project name
database parameters:
<pg-password>
<pg-host>
<pg-port>
<pg-username>
<pg-db-name>
You need to upload DDL (database schema) before upload pg_stat_statements snapshot!
Make sure that the <pg-username> has enough permissions to retrieve the query results. If there are problems with the output, the easiest way to fix it is DROP EXTENSION and CREATE EXTENSION again.
Query in sample script aggregat
Check Results
After adding DDL or DML source, we try to parse and analyze it. It can take some time, especially for big DDL. Because of these reasons parsing and analyzing doing asynchronous way.
When we ship new parser or analyzer, we rebuild all internal objects and analyze them with new rules.
You can reach check results for the last DDL by <project-uuid> or <ddl-uuid>.
DML check result can be reached only by <dml-uuid>.
All of them have similar results format.
UUID point to exact DDL/DML version, not the last one.
The holistic.dev API uses conventional HTTP response codes to indicate the success or failure of an API request. In general: Codes in the 2xx range indicate success. Codes in the 4xx range indicate an error that failed given the information provided (e.g., a required parameter was omitted, a charge failed, etc.). Codes in the 5xx range indicate an error with holistic.dev's servers.
Error statuses
200 - OK Everything worked as expected.
400 - Bad Request The request was unacceptable, often due to missing a required parameter.
401 - Unauthorized No valid API key provided.
403 - Forbidden The API key doesn't have permissions to perform the request.
404 - Not Found The requested resource doesn't exist.
409 - Conflict The request conflicts with another request (perhaps due to using the same idempotent key).
429 - Too Many Requests Too many requests hit the API too quickly. We recommend an exponential backoff of your requests.
500 - Server Error Something went wrong on holistic.dev's end.