Send (ingest), transport, and fetch data from different sources such as Relational database, web logs, batch data, real-time, app logs, streaming data, etc. for later usage with the Axiom API. You can also collect, load, group, and move data from one or more sources to Axiom where it can be stored and further analyzed. Before ingesting data, you need to generate an API token from the Settings > Tokens page on the Axiom Dashboard. See API tokens documentation for more detail. Once you have an API token, there are different ways to get your data into Axiom: To use dedicated apps that enrich your Axiom organization, go to Apps instead.

​
Ingest method

Select the method to ingest your data. Each ingest method follows a particular path.

​
Client libraries

JavaScript

Go

Rust

Python

​
Library extensions

Next.js

Rust Tracing

Winston

Pino

Logrus

Apex

Zap

Python logging

Go OTel

​
Other

API

Elastic Bulk Endpoint

CLI

​
Ingest API

Axiom exports a simple REST API that can accept any of the following formats:

​
Ingest using JSON

  • application/json - single event or JSON array of events

​
Example

curl -X 'POST' 'https://AXIOM_DOMAIN/v1/datasets/DATASET_NAME/ingest' \
  -H 'Authorization: Bearer API_TOKEN' \
  -H 'Content-Type: application/json' \
  -d '[
        {
          "_time":"2021-02-04T03:11:23.222Z",
          "data":{"key1":"value1","key2":"value2"}
        },
        {
          "data":{"key3":"value3"},
          "attributes":{"key4":"value4"}
        },
        {
          "tags": {
            "server": "aws",
            "source": "wordpress"
          }
        }
      ]'
Replace AXIOM_DOMAIN with api.axiom.co if your organization uses the US region, and with api.eu.axiom.co if your organization uses the EU region. For more information, see Regions.Replace API_TOKEN with the Axiom API token you have generated. For added security, store the API token in an environment variable.Replace DATASET_NAME with the name of the Axiom dataset where you want to send data.

​
Ingest using NDJSON

  • application/x-ndjson- Ingests multiple JSON objects, each represented as a separate line.

​
Example

curl -X 'POST' 'https://AXIOM_DOMAIN/v1/datasets/DATASET_NAME/ingest' \
  -H 'Authorization: Bearer API_TOKEN' \
  -H 'Content-Type: application/x-ndjson' \
  -d '{"id":1,"name":"machala"}
  {"id":2,"name":"axiom"}
  {"id":3,"name":"apl"}
  {"index": {"_index": "products"}}
  {"timestamp": "2016-06-06T12:00:00+02:00", "attributes": {"key1": "value1","key2": "value2"}}
  {"queryString": "count()"}'
Replace AXIOM_DOMAIN with api.axiom.co if your organization uses the US region, and with api.eu.axiom.co if your organization uses the EU region. For more information, see Regions.Replace API_TOKEN with the Axiom API token you have generated. For added security, store the API token in an environment variable.Replace DATASET_NAME with the name of the Axiom dataset where you want to send data.

​
Ingest using CSV

  • text/csv - this should include the header line with field names separated by commas

​
Example

curl -X 'POST' 'https://AXIOM_DOMAIN/v1/datasets/DATASET_NAME/ingest' \
      -H 'Authorization: Bearer API_TOKEN' \
      -H 'Content-Type: text/csv' \
      -d 'user, name
         foo, bar'
Replace AXIOM_DOMAIN with api.axiom.co if your organization uses the US region, and with api.eu.axiom.co if your organization uses the EU region. For more information, see Regions.Replace API_TOKEN with the Axiom API token you have generated. For added security, store the API token in an environment variable.Replace DATASET_NAME with the name of the Axiom dataset where you want to send data.

​
Data shippers

Configure, read, collect, and send logs to your Axiom deployment using a variety of data shippers. Data shippers are lightweight agents that acquire logs and metrics enabling you to ship data directly into Axiom.

AWS CloudFront

Amazon CloudWatch

Elastic Beats

Fluent Bit

Fluentd

Heroku Log Drains

Kubernetes

Logstash

Loki Multiplexer

Syslog Proxy

Vector

​
Apps

Send logs and metrics from Vercel, Netlify, and other supported apps.
Get started with apps here

​
Endpoints

Endpoints enable you to easily integrate Axiom into your existing data flow by allowing you to use tools and libraries that you are already familiar with. You can create an endpoint for the following services and send the logs directly to Axiom:

​
Regions

The domain that your organization uses depends on the region. For more information on regions, see Regions.

​
Limits and requirements

Axiom applies certain limits and requirements on the ingested data to guarantee good service across the platform. Some of these limits depend on your pricing plan, and some of them are applied system-wide. For more information, see Limits and requirements. The most important field requirement is about the timestamp.
All events stored in Axiom must have a _time timestamp field. If the data you ingest doesn’t have a _time field, Axiom assigns the time of the data ingest to the events. To specify the timestamp yourself, include a _time field in the ingested data.
If you include the _time field in the ingested data, ensure the _time field contains timestamps in a valid time format. Axiom accepts many date strings and timestamps without knowing the format in advance, including Unix Epoch, RFC3339, or ISO 8601.

​
Best practices for sending data to Axiom

When sending data into Axiom, follow these best practices to optimize performance and reliability:
  • Batch events: Use a log forwarder, collector, or Axiom‘s official SDKs to group multiple events into a single request before sending them to Axiom. This reduces the number of API calls and improves overall throughput. Avoid implementing batching within your app itself as this introduces additional complexity and requires careful management of buffers and error handling.
  • Use compression: Enable gzip, zstd compression for your requests to reduce bandwidth usage and potentially improve response time.
  • Handle rate limiting and errors: Use Axiom‘s official libraries and SDKs which automatically implement best practices for handling rate limiting and errors. For advanced use cases or custom implementations, consider adding a fallback mechanism to store events locally or in cold storage if ingestion consistently fails after retries.