Documentation

Use the v3 write API to write data

Use the /api/v3/write_lp endpoint to write data to InfluxDB 3 Core.

This endpoint accepts the same line protocol syntax as previous versions of InfluxDB, and supports the following:

Query parameters
  • ?accept_partial=<BOOLEAN>: Accept or reject partial writes (default is true).

  • ?no_sync=<BOOLEAN>: Control when writes are acknowledged:

    • no_sync=true: Acknowledges writes before WAL persistence completes.
    • no_sync=false: Acknowledges writes after WAL persistence completes (default).
  • ?precision=<PRECISION>: Specify the precision of the timestamp. By default, InfluxDB 3 Core uses the timestamp magnitude to auto-detect the precision. To avoid any ambiguity, you can specify the precision of timestamps in your data.

    The InfluxDB 3 Core /api/v3/write_lp API endpoint supports the following timestamp precisions:

    • ns (nanoseconds)
    • us (microseconds)
    • ms (milliseconds)
    • s (seconds)
Request body
  • Line protocol
POST /api/v3/write_lp?db=mydb&precision=nanosecond&accept_partial=true&no_sync=false
  • Copy
  • Fill window

The following example uses cURL to send a write request using the Home sensor sample data, but you can use any HTTP client.

curl -v "http://localhost:8181/api/v3/write_lp?db=sensors&precision=s" \
  --data-raw "home,room=Living\ Room temp=21.1,hum=35.9,co=0i 1735545600
home,room=Kitchen temp=21.0,hum=35.9,co=0i 1735545600
home,room=Living\ Room temp=21.4,hum=35.9,co=0i 1735549200
home,room=Kitchen temp=23.0,hum=36.2,co=0i 1735549200
home,room=Living\ Room temp=21.8,hum=36.0,co=0i 1735552800
home,room=Kitchen temp=22.7,hum=36.1,co=0i 1735552800
home,room=Living\ Room temp=22.2,hum=36.0,co=0i 1735556400
home,room=Kitchen temp=22.4,hum=36.0,co=0i 1735556400
home,room=Living\ Room temp=22.2,hum=35.9,co=0i 1735560000
home,room=Kitchen temp=22.5,hum=36.0,co=0i 1735560000
home,room=Living\ Room temp=22.4,hum=36.0,co=0i 1735563600
home,room=Kitchen temp=22.8,hum=36.5,co=1i 1735563600
home,room=Living\ Room temp=22.3,hum=36.1,co=0i 1735567200
home,room=Kitchen temp=22.8,hum=36.3,co=1i 1735567200
home,room=Living\ Room temp=22.3,hum=36.1,co=1i 1735570800
home,room=Kitchen temp=22.7,hum=36.2,co=3i 1735570800
home,room=Living\ Room temp=22.4,hum=36.0,co=4i 1735574400
home,room=Kitchen temp=22.4,hum=36.0,co=7i 1735574400
home,room=Living\ Room temp=22.6,hum=35.9,co=5i 1735578000
home,room=Kitchen temp=22.7,hum=36.0,co=9i 1735578000
home,room=Living\ Room temp=22.8,hum=36.2,co=9i 1735581600
home,room=Kitchen temp=23.3,hum=36.9,co=18i 1735581600
home,room=Living\ Room temp=22.5,hum=36.3,co=14i 1735585200
home,room=Kitchen temp=23.1,hum=36.6,co=22i 1735585200
home,room=Living\ Room temp=22.2,hum=36.4,co=17i 1735588800
home,room=Kitchen temp=22.7,hum=36.5,co=26i 1735588800"
  • Copy
  • Fill window

InfluxDB client libraries

InfluxData provides supported InfluxDB 3 client libraries that you can integrate with your code to construct data as time series points, and then write them as line protocol to an InfluxDB 3 Core database. For more information, see how to use InfluxDB client libraries to write data.

Partial writes

The /api/v3/write_lp endpoint lets you accept or reject partial writes using the accept_partial parameter. This parameter changes the behavior of the API when the write request contains invalid line protocol or schema conflicts.

For example, the following line protocol contains two points, each using a different datatype for the temp field, which causes a schema conflict:

home,room=Sunroom temp=96 1735545600
home,room=Sunroom temp="hi" 1735549200
  • Copy
  • Fill window

Accept partial writes

With accept_partial=true (default), InfluxDB:

  • Accepts and writes line 1
  • Rejects line 2
  • Returns a 400 Bad Request status code and the following response body:
< HTTP/1.1 400 Bad Request
...
{
  "error": "partial write of line protocol occurred",
  "data": [
    {
      "original_line": "home,room=Sunroom temp=hi 1735549200",
      "line_number": 2,
      "error_message": "invalid column type for column 'temp', expected iox::column_type::field::float, got iox::column_type::field::string"
    }
  ]
}
  • Copy
  • Fill window

Do not accept partial writes

With accept_partial=false, InfluxDB:

  • Rejects all points in the batch
  • Returns a 400 Bad Request status code and the following response body:
< HTTP/1.1 400 Bad Request
...
{
  "error": "parsing failed for write_lp endpoint",
  "data": {
    "original_line": "home,room=Sunroom temp=hi 1735549200",
    "line_number": 2,
    "error_message": "invalid column type for column 'temp', expected iox::column_type::field::float, got iox::column_type::field::string"
  }
}
  • Copy
  • Fill window

For more information about the ingest path and data flow, see Data durability.

Write responses

By default, InfluxDB 3 Core acknowledges writes after flushing the WAL file to the Object store (occurring every second). For high write throughput, you can send multiple concurrent write requests.

Use no_sync for immediate write responses

To reduce the latency of writes, use the no_sync write option, which acknowledges writes before WAL persistence completes. When no_sync=true, InfluxDB validates the data, writes the data to the WAL, and then immediately responds to the client, without waiting for persistence to the Object store.

Using no_sync=true is best when prioritizing high-throughput writes over absolute durability.

  • Default behavior (no_sync=false): Waits for data to be written to the Object store before acknowledging the write. Reduces the risk of data loss, but increases the latency of the response.
  • With no_sync=true: Reduces write latency, but increases the risk of data loss in case of a crash before WAL persistence.

The following example immediately returns a response without waiting for WAL persistence:

curl "http://localhost:8181/api/v3/write_lp?db=sensors&no_sync=true" \
  --data-raw "home,room=Sunroom temp=96"
  • Copy
  • Fill window

Was this page helpful?

Thank you for your feedback!


The future of Flux

Flux is going into maintenance mode. You can continue using it as you currently are without any changes to your code.

Read more

New in InfluxDB 3.2

Key enhancements in InfluxDB 3.2 and the InfluxDB 3 Explorer UI is now generally available.

See the Blog Post

InfluxDB 3.2 is now available for both Core and Enterprise, bringing the general availability of InfluxDB 3 Explorer, a new UI that simplifies how you query, explore, and visualize data. On top of that, InfluxDB 3.2 includes a wide range of performance improvements, feature updates, and bug fixes including automated data retention and more.

For more information, check out: