Verify event ingestion and schema

An accepted API request is not the end of an instrumentation check. Verify the resulting table and row before copying the event into more routes, workers, or services.

This page assumes you sent the synthetic telemetry_quickstart event from Send Your First Structured Event.

Using an anonymous anon_… key? Skip to Verify through the API below; the same key can read back your event for 24 hours after the first send. To use the team UI, create an account and keep your trial. In another browser, enter your anonymous key using Already have an anonymous API key? before registering.

Find the table

Open your Telemetry team, select Tables, and open telemetry_quickstart. If the table is absent:

Confirm the API request returned a successful response.
Confirm the key belongs to the intended team and has a write-capable scope.
Check the exact table name after normalization.
Retry once with a new synthetic request_id.
Follow Troubleshooting Event Ingestion before changing the schema.

Avoid repeatedly sending the same event without a new identifier; retries can make later counts ambiguous.

Inspect the inferred schema

The synthetic API example should expose fields similar to:

Field	Expected analytical type	Check
`timestamp_utc`	Timestamp	Added consistently and stored in UTC
`route_template`	Text	Contains a bounded route template, not a raw URL
`status_code`	Integer	Can support numeric comparisons
`latency_ms`	Number	Uses milliseconds everywhere
`status`	Text	Uses a small documented vocabulary
`request_id`	Text	Connects related events without exposing secrets

If an important field has the wrong type, stop and fix the producer before sending production volume. A field that changes from a number to arbitrary text can make saved SQL and charts harder to reason about.

Inspect the exact row

Use the Samples or Table view and find request_id = req_demo_001. Confirm:

The row belongs to the expected environment and release.
latency_ms is 184, not 0.184 or 184000.
The route does not contain a real report or account identifier.
No authorization header, cookie, request body, secret, prompt, or private customer content was included.
The generated time matches the send window.

The expected row is evidence that the event contract works. It is not a performance benchmark or representative production distribution.

Verify through the API

For these API checks, use a read-capable key on a trusted server or in a local terminal. Ingest only keys can send events but cannot list tables, inspect schemas, or run queries. Keep read-capable keys out of browser and mobile client code; use the team UI to verify events sent with an ingest-only key.

You can also inspect tables and schemas programmatically:

curl https://api.telemetry.sh/tables \
  -H "Authorization: Bearer $TELEMETRY_API_KEY"

Then request the table schema:

curl https://api.telemetry.sh/tables/telemetry_quickstart/schema \
  -H "Authorization: Bearer $TELEMETRY_API_KEY"

Read back the event with a read-capable key for the same workspace. If you used another request_id, replace req_demo_001 below. This query checks the last 24 hours and returns at most ten matching rows:

curl https://api.telemetry.sh/query \
  -H "Authorization: Bearer $TELEMETRY_API_KEY" \
  -H "Content-Type: application/json" \
  --data-binary @- <<'JSON'
{"query":"SELECT timestamp_utc, request_id, route_template, status_code, latency_ms, release, environment FROM telemetry_quickstart WHERE request_id = 'req_demo_001' AND timestamp_utc >= now() - INTERVAL '24 hours' ORDER BY timestamp_utc DESC LIMIT 10"}
JSON

Look for status: "success" and the expected row in data, including latency_ms: 184. An empty data array does not confirm ingestion; check the key, table, identifier and send time. Multiple matching rows can be retries, not separate application operations. A successful sample readback verifies this synthetic test only. Next, instrument one actual application operation and query its workflow table.

Use a read-capable key for verification automation. The Tables API documents pagination, normalization, retention, and schema responses.

Record the contract

Before expanding instrumentation, write down:

The event name and business grain.
Required and optional fields.
Field types and units.
Allowed status and error categories.
Identity and correlation fields.
Fields that are prohibited.
The owner and intended retention period.

Continue with Write Your First SQL Query. For schema-change strategy, see Schema Evolution.

Use this doc with your coding agent