Skip to main content

API

The HH Data Management web API can be used to directly access portions of the HH Data Management database without having to go through the HH Data Management client and syncing framework. This gives direct access to all data.

Authentication

The API supports authentication using an API key (Basic authentication). The access to the API is linked to the user account and the data rules in the permissions control how data can be accessed.

To use an API key you should supply an ApiKey header with the API key as the content. To create an API key visit the website and select the Integrations menu item:

Next, click "Add New Api Key" and enter a name for the API key and a key will be generated.

Selecting parameters returned in queries

When making a GET request to an endpoint you can pass a URL parameter called parametersToInclude that lets you specify which parameters will be included in the response. This can be useful to access related data (e.g. get the session for a runsheet or the laps) and also to limit the amount of data returned in a response to make the API calls faster. The parametersToInclude should be a comma separated list. The names of the parameters are the same as those used in the HH DM client software to access custom properties and related entities. The * symbol is used to represent all parameters. When building a response the API has the following logic:

  • if you do not provide a value for parametersToInclude or if you pass in * the API will return:

    • all parameters of the current entity

    • the following parts of the response will be present but empty

      • collections
      • children (e.g. the RunSheet endpoint will return an empty Laps object)
      • parents (e.g. the RunSheet endpoint will return empty Car and Session objects)
    • referenced items will be populated but no parameters will be included (e.g. the RunSheet endpoint will return a Setup object with no parameters)

      Here is a sample from the RunSheet endpoint:

      {
      "$type": "RunSheet",
      "Id": "54d989d4-1442-40e6-8af9-7e7662a19c18",
      "Parameters": {
      "AirTemperature": 26.0,
      "SetupId": "5215b098-154a-48dd-aabf-c44af0125e2b",
      "SessionId": "c9e28903-1946-4bd5-8d89-e4236f9b527c",
      "CarId": "afd5e230-0c21-40f8-88a9-b003a21a1c93",
      "RunName": "RUN 1",
      ** additional parameters omitted for clarity **
      "Setup": {
      "$type": "Setup",
      "Id": "5215b098-154a-48dd-aabf-c44af0125e2b",
      "Parameters": {},
      "DefinitionId": "60d5a9b2-122a-42c2-a093-f9add1ec2bb4",
      "Collections": {}
      }
      ** additional parameters omitted for clarity **
      },
      "DefinitionId": "07111622-0281-4085-8118-d82082f84007",
      "Collections": {},
      "Session": [],
      "Car": [],
      "SessionCar": [],
      "Laps": []
      }

      The empty and minimal objects are returned to provide insight to users to see what each entity has access to.

  • if parameters are specified then only these parameters are provided. For example, if the parametersToInclude was set to RunName,AirTemperature then the response would look like this:

    {
    "$type": "RunSheet",
    "Id": "54d989d4-1442-40e6-8af9-7e7662a19c18",
    "Parameters": {
    "AirTemperature": 26.0,
    "RunName": "RUN 3"
    },
    "DefinitionId": "07111622-0281-4085-8118-d82082f84007",
    "Collections": {}
    }
  • Referenced items can be specified using the dot notation. For example, if the parametersToInclude was set to RunName,Setup.Name then the response would look like this:

    {
    "$type": "RunSheet",
    "Id": "54d989d4-1442-40e6-8af9-7e7662a19c18",
    "Parameters": {
    "RunName": "RUN 1",
    "Setup": {
    "$type": "Setup",
    "Id": "5215b098-154a-48dd-aabf-c44af0125e2b",
    "Parameters": {
    "Name": "SETUP 1"
    },
    "DefinitionId": "60d5a9b2-122a-42c2-a093-f9add1ec2bb4",
    "Collections": {}
    }
    },
    "DefinitionId": "07111622-0281-4085-8118-d82082f84007",
    "Collections": {}
    }

    the dot notation also supports the wildcard character, so sending Setup.* to the runsheet endpoint would return all parameters from the referenced setup.

Selecting parameters using parameter groupings

Parameter groupings can be used to easily select a subset of parameters without needing to specify each parameter name individually. Rather than writing the parameter name in parametersToInclude, write the grouping name in brackets. For example if there is a parameter grouping called FrontSuspension then writing (FrontSuspension) would include all parameters in that group in the JSON response.

Setting parameter values

When making a POST or PUT request the body of the request should contain a JSON array called parameterUpdates. Therefore the body will have a structure like this:

{ 
"parameterUpdates": [
{
"name": "string",
"value": "string"
}
]
}

Each entry in the parameterUpdates should have a name that corresponds to the parameter that is to be updated and the value should be the new value you wish to set on the entity and should always be sent as a string. For example, to update the AirTemperature and TrackTemperature of a RunSheet the body of the PUT request should look like this:

{ 
"parameterUpdates": [
{
"name": "AirTemperature",
"value": "30.0"
},
{
"name": "TrackTemperature",
"value": "35.0"
}
]
}

Creating items

When making new items with a POST request, the body should contain a JSON object with the following structure:

{
"copyFromLast": true,
"copyAll": true,
"index": 0,
"parameterUpdates": [
{
"name": "string",
"value": "string"
}
]
}

Where:

  • copyFromLast: if true, then when the new item is created all property values will be copied from the previous existing item, based on the copy to new setting of the parameter
  • copyAll: if true, then all property values will be copied from the previous existing item, regardless of the copy to new setting of the parameter
  • index: if specified, the new item will be inserted at the specific position in the list - if not specified the new item will be placed last in the list of items
  • parameterUpdates: as explained above

Headers

In addition to the headers required for authentication, the following headers are also required on requests:

  • AccountId: the ID of the account that owns the data that is being requested. Currently, this header is optional (requests will still succeed without it), but it may become mandatory in the future. We strongly recommend including the AccountId header for all new projects.