Quickstart

From a working account to telemetry you can see in the product, in about ten minutes, using nothing but curl. The shortest path that proves every hop.

This is the shortest path from an account to data on screen. It uses curl rather than an SDK on purpose: if it works, every hop between you and aiAxonIQ is proven, and anything that fails afterwards is your instrumentation rather than your setup.

About ten minutes. Install a collector after this, not before.

Before you start. You need an account you can sign in to — see Create your account. Nothing else: no collector, no SDK, no changes to your application.

1. Get your two values

1. Open Get Started in the dashboard

   It is in the sidebar, and on Overview. This page is the authority on your ingest endpoint — the value differs per deployment, so it is the one place that knows the right answer for yours.

2. Create a license key

   Step 1 of that page mints one. Copy it immediately — the full key is shown exactly once, because only a hash of it is stored.

   Requires the Admin role. If there is no create button, ask your organization’s Owner.

3. Export both into your shell

   export OIQ_ENDPOINT="https://app.aiaxoniq.com/otlp"   # from Get Started
   export OIQ_LICENSE_KEY="oiq_4f3c2b1a9e8d7c6b5a4f3e2d1c0b9a8e"
   

2. Check the endpoint is reachable

Before sending anything, prove you can reach the receiver at all. This costs one second and eliminates DNS, TLS and proxy problems from everything that follows.

curl -s "$OIQ_ENDPOINT/health"

Expected output:

{"status":"ok","service":"otel-receiver","version":"1.0.0"}

Anything else and stop here — no amount of correct payload will help.

• Could not resolve host — $OIQ_ENDPOINT is wrong. Copy it from Get Started rather than typing it.
• HTML instead of JSON — you have reached the dashboard, not the receiver. The /otlp prefix is missing from your endpoint.
• Connection refused or a timeout — a network path problem: egress rules, a proxy, or a firewall between you and the endpoint.

3. Send one log record

A single OTLP/JSON log line, tagged with a service name nothing else uses so you can find it again.

curl -i -X POST "$OIQ_ENDPOINT/v1/logs" \
  -H "Content-Type: application/json" \
  -H "X-License-Key: $OIQ_LICENSE_KEY" \
  -d '{
    "resourceLogs": [{
      "resource": { "attributes": [
        { "key": "service.name", "value": { "stringValue": "quickstart" } }
      ]},
      "scopeLogs": [{
        "logRecords": [{
          "timeUnixNano": "'"$(date +%s)000000000"'",
          "severityText": "INFO",
          "body": { "stringValue": "hello from the quickstart" }
        }]
      }]
    }]
  }'

Expected output:

HTTP/1.1 202 Accepted

timeUnixNano is built from your clock on purpose. A hardcoded timestamp copied from an example is the single most common reason a first record is accepted and then cannot be found — it lands wherever that timestamp points, possibly years outside the window you are searching, or outside retention entirely.

If you got something other than 202, the status code says exactly what is wrong:

Code	Cause	Fix
401	Key missing, malformed or revoked	Confirm the header is X-License-Key and the value starts oiq_
403	Key valid, logs not enabled on your plan	Check which signals your plan includes
404	Endpoint wrong	It must be the base URL — /v1/logs is appended here, not part of $OIQ_ENDPOINT
413	Body too large	Not possible with this payload; you are sending something else

4. Find it in the product

202 means accepted, not stored. Between the two sits a batching consumer that flushes on 50,000 rows or five seconds, whichever comes first — on a quiet new account, the five seconds is what you are waiting on.

1. Wait about ten seconds
2. Open Logs and set the range to the last 15 minutes

   A wider range reads rolled-up tables that fill on their own schedule, so a fresh record can be genuinely invisible on “last 24 hours” for a while.

3. Search for the service name

   service.name:"quickstart"
   

Expected result: one record, body hello from the quickstart.

If it is there, the whole path works: your network reaches the receiver, your key authenticates, the pipeline stores, and queries return. Everything after this is configuration of the sender.

5. Send metrics and traces too

Same endpoint, same header, different path and payload — /v1/metrics and /v1/traces. Rather than hand-writing OTLP for each, this is the point where a collector or an SDK earns its place.

Install a collector

Choose Docker, Docker Compose, a Linux VM or Kubernetes. The collector gathers host and container telemetry as well as forwarding your app’s.

Instrument your application

Zero-code auto-instrumentation for Node.js, Python, Java and .NET; an explicit setup for Go.

Troubleshooting

202 Accepted, but nothing in Logs

In order of how often each is the answer:

1. The time range. Narrow to 15 minutes.
2. A hardcoded timestamp, if you edited the payload.
3. The wrong organization. A key belongs to one organization; if you have several, confirm the key and the dashboard you are looking at agree.

Verify your data arrived covers this in full.

The curl fails with a JSON parse error

The payload embeds a shell substitution for the timestamp, which needs the quoting exactly as written above — "'"$(date +%s)000000000"'". Copying it through an editor that converts straight quotes to curly ones breaks it.

I do not have the Admin role

You can see the license key list but not create a key. Ask your organization’s Owner to mint one, or to grant you Admin. See Authentication.

Everything works from my laptop but not from my server

Egress. Your server needs outbound HTTPS to the ingest host. Run the step 2 health check from that server — it distinguishes a network problem from a credential one in one command.

Next

How aiAxonIQ works

The path your data just took.

Install a collector

Real telemetry, continuously.

Search your logs

The query syntax.