> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aiaxoniq.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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.

<Info>
  **Before you start.** You need an account you can sign in to — see
  [Create your account](/get-started/accounts). Nothing else: no collector, no
  SDK, no changes to your application.
</Info>

## 1. Get your two values

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Export both into your shell">
    ```bash theme={null}
    export OIQ_ENDPOINT="https://app.aiaxoniq.com/otlp"   # from Get Started
    export OIQ_LICENSE_KEY="oiq_4f3c2b1a9e8d7c6b5a4f3e2d1c0b9a8e"
    ```
  </Step>
</Steps>

## 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.

```bash theme={null}
curl -s "$OIQ_ENDPOINT/health"
```

**Expected output:**

```json theme={null}
{"status":"ok","service":"otel-receiver","version":"1.0.0"}
```

<Warning>
  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.
</Warning>

## 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.

```bash theme={null}
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 theme={null}
HTTP/1.1 202 Accepted
```

<Note>
  **`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.
</Note>

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.

<Steps>
  <Step title="Wait about ten seconds" />

  <Step title="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.
  </Step>

  <Step title="Search for the service name">
    ```text theme={null}
    service.name:"quickstart"
    ```
  </Step>
</Steps>

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

<Check>
  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*.
</Check>

## 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.

<CardGroup cols={2}>
  <Card title="Install a collector" icon="server" href="/send-data/overview">
    Choose Docker, Docker Compose, a Linux VM or Kubernetes. The collector
    gathers host and container telemetry as well as forwarding your app's.
  </Card>

  <Card title="Instrument your application" icon="code" href="/send-data/otel/zero-code">
    Zero-code auto-instrumentation for Node.js, Python, Java and .NET; an
    explicit setup for Go.
  </Card>
</CardGroup>

## Troubleshooting

<AccordionGroup>
  <Accordion title="202 Accepted, but nothing in Logs" icon="magnifying-glass">
    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](/get-started/verify-data) covers this in full.
  </Accordion>

  <Accordion title="The curl fails with a JSON parse error" icon="code">
    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.
  </Accordion>

  <Accordion title="I do not have the Admin role" icon="user-lock">
    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](/get-started/authentication#roles).
  </Accordion>

  <Accordion title="Everything works from my laptop but not from my server" icon="network-wired">
    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.
  </Accordion>
</AccordionGroup>

## Next

<CardGroup cols={3}>
  <Card title="How aiAxonIQ works" icon="diagram-project" href="/get-started/how-it-works">
    The path your data just took.
  </Card>

  <Card title="Install a collector" icon="server" href="/send-data/overview">
    Real telemetry, continuously.
  </Card>

  <Card title="Search your logs" icon="magnifying-glass" href="/guides/logs/search">
    The query syntax.
  </Card>
</CardGroup>