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 api_request_completed event from Send Your First Structured Event.

Find the table

Open your Telemetry team, select Tables, and open api_request_completed. 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

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/api_request_completed/schema \
  -H "Authorization: Bearer $TELEMETRY_API_KEY"

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