Skip to main content
After a test recording, one request tells you whether the device’s data reached truemetrics and matches the configuration the device was last served: per-sensor counts and rates, the upload mode, the traffic limit, and your customer metadata. The answer is ok, or failed with one reason per failed check. Use it to check a test run. It is not a monitoring API.
If you integrate with the agent prompt, its final step runs this test and explains the result.

1. Get the device ID

The SDK generates the device ID. Read it in your app once the SDK is initialized, and store it next to the test session, for example in your logs or your backend.
The device ID changes periodically, and clearing the app’s data creates a new one. Check a recording with the ID that was current while it ran. If the app switched to another API key, check with the new key: only data sent under it counts, so test after the switch.

2. Record a test session

The whole test takes about 50 to 75 minutes, most of it waiting.
  1. On a device that has not recorded earlier that UTC day, wait until the SDK reports Initialized (metadata logged before that is lost), then record for 30 minutes, ideally while moving (walking or driving). Finish before 00:00 UTC: the whole UTC day is checked.
  2. During the recording, at about minutes 1, 15 and 29, log 3 test metadata objects with eventType integration_test, the same test_run_id (any unique ID) and a test_index of 1, 2 and 3, as shown below. Keep this out of your release build.
  3. Stop the recording with your app’s stop trigger or a debug action, not by logging out. Keep the app logged in and the device online until the check passes: the SDK uploads the end of the recording after the stop, and after a logout it uploads nothing until the next login.
  4. Start the check script right away. Data reaches truemetrics with the SDK’s uploads, typically 10 to 20 minutes after it was recorded, plus about a minute of processing, so the script waits 20 minutes and then checks every 5 minutes, up to 45 minutes after the stop.
To repeat the whole test on the same day, clear the app’s data on the test device first, or use another device. The device then gets a new ID, so the earlier run does not count. Logging one test object:

3. Check the result

The test passes when status is ok, config is device, and customer_metadata has at least 3 entries whose fields include test_run_id and test_index. Values are never returned, so count the entries. With config unavailable the rates were not checked, so ok is only a partial result.

Check script

The script below runs the whole check. It needs Python 3.8 or newer and nothing else, on macOS, Linux and Windows. Start it right after the recording stops, with your SDK API key, the one your app initializes the SDK with, in TRUEMETRICS_API_KEY. Set the variable from where you keep the key rather than typing the key into a command, for example with read -rs TRUEMETRICS_API_KEY && export TRUEMETRICS_API_KEY in bash or zsh, or $env:TRUEMETRICS_API_KEY = Read-Host -MaskInput in PowerShell 7:
On Windows, run it with py instead of python3. If it reports no answer with CERTIFICATE_VERIFY_FAILED on macOS, run the Install Certificates command that comes with the python.org installer once.
check_integration.py
It prints PASSED, or FAILED with the result’s reasons (see Reading a failed result); test_objects below 3 means the test metadata did not arrive. Exit code 2 means the check could not run, which is not a test result: run it again later with WAIT_SECONDS=0, which checks without waiting, and the UTC day it printed at the start as the second argument. Pass that day too whenever you start it after 00:00 UTC.

Single request

One call, for a quick look (bash or zsh). The key goes to curl on stdin, so it stays out of process lists. You only see devices that last fetched their configuration with your key. Without date, today (UTC) is checked. If you check after 00:00 UTC, add the day of the test, e.g. &date=2026-10-28.

Parameters

string
required
Your SDK API key. Identifies your account; you only see your own devices.
string
required
The device ID from step 1. Letters, digits, ., _ and -, at most 64 characters.
string
default:"today (UTC)"
The UTC day to check, YYYY-MM-DD: today or one of the 29 days before it. Raw sensor data is not kept longer. When you check after midnight UTC, pass the day of the test, or the new, empty day is checked.
The endpoint is shared by all customers and rate-limited for all of them together. Call it from a test script or a debug tool, at most every 5 minutes during a test. Do not poll it continuously or call it from your production app.

What is checked

The checks follow the configuration the device was last served. In metadata_triggered mode the SDK uploads sensor data only around metadata events. If the device sent neither metadata nor sensor readings that day, the missing metadata is the only reason (besides a reached traffic limit), since the empty sensors follow from it. When the device’s configuration is unknown, config is unavailable. The rates are then not checked; the counts and the customer metadata still are.

Response

string
ok when every check passes, otherwise failed.
string[]
One human-readable entry per failed check, naming the value and the bar it missed. Empty when status is ok.
string
The device ID that was checked.
string
The UTC day that was checked.
object
Readings received that day for gyro, acc and gps.
number
How long the device recorded that day, pauses left out. Each sensor’s hz is measured against it.
object
Per check (gyro, acc, gps), what the configuration asks for and what was measured.
string
device when the checks used the configuration this device was last served; unavailable when it is unknown.
string | null
The upload_mode of that configuration, e.g. upload_always or metadata_triggered.
integer
How many customer metadata objects the device sent that day.
object[]
The metadata the device sent that day, newest first, at most 200: when each was recorded (t_utc, Unix seconds) and its field names (fields; null for metadata that is not a JSON object). Values are never returned. An event logged as StandardMetadata always has the nine standard keys (t_event, type_event, …), plus the keys of its extra.
An ID unknown under your key, for example a typo, a device whose SDK never finished initializing, or a device that uses another API key, returns failed with zero counts, config unavailable and a single reason (below).

Errors

Reading a failed result