InfluxDB API reference

The following sections assume your InfluxDB instance is running on port 8086 and HTTPS is not enabled.Those settings .

/debug/pprof HTTP endpoint

InfluxDB supports the Go HTTP endpoints, which are useful for troubleshooting. The pprof package serves runtime profiling data in the format expected by the pprof visualization tool.

Definition

The /debug/pprof/ endpoint generates an HTML page with a list of built-in Go profiles and hyperlinks for each.

ProfileDescription
blockStack traces that led to blocking on synchronization primitives.
goroutineStack traces of all current goroutines.
heapSampling of stack traces for heap allocations.
mutexStack traces of holders of contended mutexes.
threadcreateStack traces that led to the creation of new OS threads.

To access one of the /debug/pprof/ profiles listed above, use the following cURL request, substituting <profile> with the name of the profile. The resulting profile is output to a file specified in <path/to/output-file>.

  1. curl -o <path/to/output-file> http://localhost:8086/debug/pprof/<profile>

In the following example, the cURL command outputs the resulting heap profile to a file:

  1. curl -o <path/to/output-file> http://localhost:/8086/debug/pprof/heap

You can also use the to access the InfluxDB /debug/pprof/ profiles.For example, to look at the heap profile of a InfluxDB instance using this tool, you would use a command like this:

  1. go tool pprof http://localhost:8086/debug/pprof/heap

For more information about the Go /net/http/pprof package and the interactive pprof analysis and visualization tool, see:

/debug/pprof/all HTTP endpoint

The /debug/pprof/all endpoint is a custom /debug/pprof profile intended primarily for use by InfluxData support. This endpoint generates a profile.tar.gz archive containing text files with the standard Go profiling information and additional debugging data. An optional CPU profile is generated when using the cpu=true option (default is false).

To create a profile.tar.gz archive, use the following cURL command to generate a profile.tar.gz file for sharing with InfluxData support.

  1. curl -o profiles.tar.gz "http://localhost:8086/debug/pprof/all?cpu=true"

As the following example shows, the cURL output includes “Time Spent,” the time elapsed (in seconds). After 30 seconds of data has been collected, the results are output to a file.

  1. ~ curl -o profiles.tar.gz "http://localhost:8086/debug/pprof/all?cpu=true"
  2. % Total % Received % Xferd Average Speed Time Time Time Current
  3. Dload Upload Total Spent Left Speed
  4. 100 237k 0 237k 0 0 8025 0 --:--:-- 0:00:30 --:--:-- 79588

Use this endpoint to track HTTP client requests to the /write and /query endpoints.The /debug/requests endpoint returns the number of writes and queries to InfluxDB per username and IP address.

  1. curl http://localhost:8086/debug/requests

Query string parameters

Query String ParameterOptional/RequiredDefinition
seconds=<integer>OptionalSets the duration (in seconds) over which the client collects information. The default duration is ten seconds.

Examples

Track requests over a ten-second interval
  1. $ curl http://localhost:8086/debug/requests
  2. {
  3. "user1:123.45.678.91": {"writes":1,"queries":0},
  4. }

The response shows that, over the past ten seconds, the user1 user sent one request to the /write endpoint and no requests to the /query endpoint from the 123.45.678.91 IP address.

Track requests over a one-minute interval
  1. $ curl http://localhost:8086/debug/requests?seconds=60
  2. {
  3. "user1:123.45.678.91": {"writes":3,"queries":0},
  4. "user1:000.0.0.0": {"writes":0,"queries":16},
  5. "user2:xx.xx.xxx.xxx": {"writes":4,"queries":0}
  6. }

The response shows that, over the past minute, user1 sent three requests to the /write endpoint from 123.45.678.91, user1 sent 16 requests to the /query endpoint from 000.0.0.0, and user2 sent four requests to the /write endpoint from xx.xx.xxx.xxx.

/debug/vars HTTP endpoint

InfluxDB exposes statistics and information about its runtime through the /debug/vars endpoint, which can be accessed using the following cURL command:

  1. curl http://localhost:8086/debug/vars

Server statistics and information are displayed in JSON format.

Note: The InfluxDB input plugin is available to collect metrics (using the /debug/vars endpoint) from specified Kapacitor instances. For a list of the measurements and fields, see the .

The ping endpoint accepts both GET and HEAD HTTP requests.Use this endpoint to check the status of your InfluxDB instance and your versionof InfluxDB.

Definition

  1. GET http://localhost:8086/ping
  1. HEAD http://localhost:8086/ping

verbose option

By default, the /ping HTTP endpoint returns a simple HTTP 204 status response to let the client know that the server is running. Default value is false.When verbose option is set to true (/ping?verbose=true), an HTTP 200 status is returned.The verbose=true option is required for Google Cloud Load Balancing health checks.

Example

You can use the /ping endpoint to find the build and version of an InfluxDB instance.The X-Influxdb-Build header field displays the InfluxDB build type, either OSS (open source) or ENT (Enterprise).The X-Influxdb-Version header field displays the InfluxDB version.

  1. ~ curl -sl -I http://localhost:8086/ping
  2. HTTP/1.1 204 No Content
  3. Content-Type: application/json
  4. Request-Id: 9c353b0e-aadc-11e8-8023-000000000000
  5. X-Influxdb-Build: OSS
  6. X-Influxdb-Version: v1.7.0
  7. X-Request-Id: 9c353b0e-aadc-11e8-8023-000000000000
  8. Date: Tue, 05 Nov 2018 16:08:32 GMT

/query HTTP endpoint

The /query endpoint accepts GET and POST HTTP requests.Use this endpoint to query data and manage databases, retention policies,and users.

Definition

  1. GET http://localhost:8086/query

    Verb usage

    VerbQuery Type
    GETUse for all queries that start with: * SHOW
    POSTUse for all queries that start with: CREATEDROPKILL
    • The only exceptions are SELECT queries that include an INTO clause.Those SELECT queries require a POST request.

    Examples

    Query data with a SELECT statement
    1. $ curl -G 'http://localhost:8086/query?db=mydb' --data-urlencode 'q=SELECT * FROM "mymeas"'
    2. {"results":[{"statement_id":0,"series":[{"name":"mymeas","columns":["time","myfield","mytag1","mytag2"],"values":[["2017-03-01T00:16:18Z",33.1,null,null],["2017-03-01T00:17:18Z",12.4,"12","14"]]}]}]}

    The mymeas has two points.The first point has the timestamp 2017-03-01T00:16:18Z, a myfield value of 33.1, and no tag values for the mytag1 and mytag2 .The second point has the timestamp 2017-03-01T00:17:18Z, a myfield value of 12.4, a mytag1 value of 12, and a mytag2 value of 14.

    The same query in the InfluxDB Command Line Interface (CLI) returns the following table:

    1. name: mymeas
    2. time myfield mytag1 mytag2
    3. ---- ------- ------ ------
    4. 2017-03-01T00:16:18Z 33.1
    5. 2017-03-01T00:17:18Z 12.4 12 14
    Query data with a SELECT statement and an INTO clause
    1. $ curl -XPOST 'http://localhost:8086/query?db=mydb' --data-urlencode 'q=SELECT * INTO "newmeas" FROM "mymeas"'
    2. {"results":[{"statement_id":0,"series":[{"name":"result","columns":["time","written"],"values":[["1970-01-01T00:00:00Z",2]]}]}]}

    SELECT queries that include and clause require a POST request.

    The response shows that InfluxDB writes two points to the newmeas .Note that the system uses epoch 0 (1970-01-01T00:00:00Z) as a null timestamp equivalent.

    Create a database
    1. $ curl -XPOST 'http://localhost:8086/query' --data-urlencode 'q=CREATE DATABASE "mydb"'
    2. {"results":[{"statement_id":0}]}

    A successful CREATE DATABASE query returns no additional information.

    Query string parameters

    Query String ParameterOptional/RequiredDefinition
    chunked=[true | <number_of_points>]OptionalReturns points in streamed batches instead of in a single response. If set to true, InfluxDB chunks responses by series or by every 10,000 points, whichever occurs first. If set to a specific value, InfluxDB chunks responses by series or by that number of points.
    db=<database_name>Required for database-dependent queries (most SELECT queries and queries require this parameter).Sets the target database for the query.
    epoch=[ns,u,µ,ms,s,m,h]OptionalReturns epoch timestamps with the specified precision. By default, InfluxDB returns timestamps in RFC3339 format with nanosecond precision. Both u and µ indicate microseconds.
    p=<password>Optional if you haven’t . Required if you’ve enabled authentication.**Sets the password for authentication if you’ve enabled authentication. Use with the query string parameter u.
    pretty=trueOptionalEnables pretty-printed JSON output. While this is useful for debugging it is not recommended for production use as it consumes unnecessary network bandwidth.
    q=<query>RequiredInfluxQL string to execute. See also Request Body.
    u=<username>Optional if you haven’t . Required if you’ve enabled authentication.Sets the username for authentication if you’ve enabled authentication. The user must have read access to the database. Use with the query string parameter p.
    • InfluxDB does not truncate the number of rows returned for requests without the chunked parameter.That behavior is configurable; see the max-row-limit configuration option for more information.

    ** The InfluxDB API also supports basic authentication.Use basic authentication if you’ve and aren’t using the query string parameters u and p.See below for an example of basic authentication.

    Examples

    Query data with a SELECT statement and return pretty-printed JSON
    1. $ curl -G 'http://localhost:8086/query?db=mydb&pretty=true' --data-urlencode 'q=SELECT * FROM "mymeas"'
    2. {
    3. "results": [
    4. {
    5. "statement_id": 0,
    6. "series": [
    7. {
    8. "name": "mymeas",
    9. "columns": [
    10. "time",
    11. "myfield",
    12. "mytag1",
    13. "mytag2"
    14. ],
    15. "values": [
    16. [
    17. "2017-03-01T00:16:18Z",
    18. 33.1,
    19. null,
    20. null
    21. ],
    22. [
    23. "2017-03-01T00:17:18Z",
    24. 12.4,
    25. "12",
    26. "14"
    27. ]
    28. ]
    29. }
    30. ]
    31. }
    32. ]
    33. }
    Query data with a SELECT statement and return second precision epoch timestamps
    Create a database using HTTP authentication

    Valid credentials:

    1. $ curl -XPOST 'http://localhost:8086/query?u=myusername&p=mypassword' --data-urlencode 'q=CREATE DATABASE "mydb"'
    2. {"results":[{"statement_id":0}]}

    A successful returns no additional information.

    Invalid credentials:

    1. $ curl -XPOST 'http://localhost:8086/query?u=myusername&p=notmypassword' --data-urlencode 'q=CREATE DATABASE "mydb"'
    2. {"error":"authorization failed"}
    Create a database using basic authentication

    The following example uses valid credentials.

    1. $ curl -XPOST -u myusername:mypassword 'http://localhost:8086/query' --data-urlencode 'q=CREATE DATABASE "mydb"'
    2. {"results":[{"statement_id":0}]}

    A successful returns no additional information.

    The following example uses invalid credentials.

    1. $ curl -XPOST -u myusername:notmypassword 'http://localhost:8086/query' --data-urlencode 'q=CREATE DATABASE "mydb"'
    2. {"error":"authorization failed"}

    Request body

    1. --data-urlencode "q=<InfluxQL query>"

    All queries must be URL encoded and follow syntax.Our example shows the —data-urlencode parameter from curl, which we use in all examples on this page.

    Options

    Request multiple queries

    Delimit multiple queries with a semicolon ;.

    Submit queries from a file

    The API supports submitting queries from a file using a multipart POSTrequest.The queries in the file must be separated a semicolon (;).

    Syntax:

    1. curl -F "q=@<path_to_file>" -F "async=true" http://localhost:8086/query
    Request query results in CSV format

    Syntax:

    1. curl -H "Accept: application/csv" -G 'http://localhost:8086/query [...]

    Note that when the request includes -H "Accept: application/csv", the system returns timestamps in epoch format, not RFC3339 format.

    Bind parameters

    The API supports binding parameters to particular field values or tag values inthe .Use the syntax $<placeholder_key> as a placeholder in the query, and URLencode the map of placeholder keys to placeholder values in the request body:

    1. --data-urlencode 'q= SELECT [...] WHERE [ <field_key> | <tag_key> ] = $<placeholder_key>'

    Map syntax:

    1. --data-urlencode 'params={"<placeholder_key>":[ <placeholder_float_field_value> | <placeholder_integer_field_value> | "<placeholder_string_field_value>" | <placeholder_boolean_field_value> | "<placeholder_tag_value>" ]}'

    Delimit multiple placeholder key-value pairs with comma ,.

    Examples

    Send multiple queries
    1. $ curl -G 'http://localhost:8086/query?db=mydb&epoch=s' --data-urlencode 'q=SELECT * FROM "mymeas";SELECT mean("myfield") FROM "mymeas"'
    2. {"results":[{"statement_id":0,"series":[{"name":"mymeas","columns":["time","myfield","mytag1","mytag2"],"values":[[1488327378,33.1,null,null],[1488327438,12.4,"12","14"]]}]},{"statement_id":1,"series":[{"name":"mymeas","columns":["time","mean"],"values":[[0,22.75]]}]}]}

    The request includes two queries: SELECT * FROM "mymeas" and SELECT mean("myfield") FROM "mymeas"'.In the results, the system assigns a statement identifier to each query return.The first query’s result has a statement_id of 0 and the second query’s result has a statement_id of 1.

    Request query results in CSV format
    1. $ curl -H "Accept: application/csv" -G 'http://localhost:8086/query?db=mydb' --data-urlencode 'q=SELECT * FROM "mymeas"'
    2. name,tags,time,myfield,mytag1,mytag2
    3. mymeas,,1488327378000000000,33.1,mytag1,mytag2
    4. mymeas,,1488327438000000000,12.4,12,14

    The first point has no for the mytag1 and mytag2 tag keys.

    Submit queries from a file
    1. curl -F "q=@queries.txt" -F "async=true" 'http://localhost:8086/query'

    A sample of the queries in queries.txt:

    1. CREATE DATABASE mydb;
    2. CREATE RETENTION POLICY four_weeks ON mydb DURATION 4w REPLICATION 1;
    Bind a parameter in the WHERE clause to specific tag value
    1. $ curl -G 'http://localhost:8086/query?db=mydb' --data-urlencode 'q=SELECT * FROM "mymeas" WHERE "mytag1" = $tag_value' --data-urlencode 'params={"tag_value":"12"}'
    2. {"results":[{"statement_id":0,"series":[{"name":"mymeas","columns":["time","myfield","mytag1","mytag2"],"values":[["2017-03-01T00:17:18Z",12.4,"12","14"]]}]}]}

    The request maps $tag_value to 12.InfluxDB stores as strings they and must be double quoted in the request.

    Bind a parameter in the WHERE clause to a numerical field value
    1. $ curl -G 'http://localhost:8086/query?db=mydb' --data-urlencode 'q=SELECT * FROM "mymeas" WHERE "myfield" > $field_value' --data-urlencode 'params={"field_value":30}'
    2. {"results":[{"statement_id":0,"series":[{"name":"mymeas","columns":["time","myfield","mytag1","mytag2"],"values":[["2017-03-01T00:16:18Z",33.1,null,null]]}]}]}

    The request maps $field_value to 30.The value 30 does not require double quotes because myfield stores numerical .

    Bind two parameters in the WHERE clause to a specific tag value and numerical field value
    1. $ curl -G 'http://localhost:8086/query?db=mydb' --data-urlencode 'q=SELECT * FROM "mymeas" WHERE "mytag1" = $tag_value AND "myfield" < $field_value' --data-urlencode 'params={"tag_value":"12","field_value":30}'
    2. {"results":[{"statement_id":0,"series":[{"name":"mymeas","columns":["time","myfield","mytag1","mytag2"],"values":[["2017-03-01T00:17:18Z",12.4,"12","14"]]}]}]}

    The request maps $tag_value to 12 and $field_value to 30.

    Responses are returned in JSON.Include the query string parameter pretty=trueto enable pretty-print JSON.

    Summary table

    Examples

    A successful request that returns data
    1. $ curl -i -G 'http://localhost:8086/query?db=mydb' --data-urlencode 'q=SELECT * FROM "mymeas"'
    2. HTTP/1.1 200 OK
    3. Connection: close
    4. Content-Type: application/json
    5. Request-Id: [...]
    6. X-Influxdb-Version: 1.4.x
    7. Date: Wed, 08 Nov 2017 19:22:54 GMT
    8. Transfer-Encoding: chunked
    9. {"results":[{"statement_id":0,"series":[{"name":"mymeas","columns":["time","myfield","mytag1","mytag2"],"values":[["2017-03-01T00:16:18Z",33.1,null,null],["2017-03-01T00:17:18Z",12.4,"12","14"]]}]}]}
    A successful request that returns an error
    1. $ curl -i -G 'http://localhost:8086/query?db=mydb1' --data-urlencode 'q=SELECT * FROM "mymeas"'
    2. HTTP/1.1 200 OK
    3. Connection: close
    4. Content-Type: application/json
    5. X-Influxdb-Version: 1.4.x
    6. Date: Wed, 08 Nov 2017 19:23:48 GMT
    7. Transfer-Encoding: chunked
    8. {"results":[{"statement_id":0,"error":"database not found: mydb1"}]}
    An incorrectly formatted query
    1. $ curl -i -G 'http://localhost:8086/query?db=mydb' --data-urlencode 'q=SELECT *'
    2. Content-Type: application/json
    3. Request-Id: [...]
    4. X-Influxdb-Version: 1.4.x
    5. Date: Wed, 08 Nov 2017 19:24:25 GMT
    6. Content-Length: 76
    7. {"error":"error parsing query: found EOF, expected FROM at line 1, char 9"}
    Query data with invalid authentication credentials

    The /write endpoint accepts POST HTTP requests.Use this endpoint to write data to a pre-existing database.

    Definition

    1. POST http://localhost:8086/write

    Query string parameters

    Query String ParameterOptional/RequiredDescription
    consistency=[any,one,quorum,all]Optional, available with only.Sets the write consistency for the point. InfluxDB assumes that the write consistency is one if you do not specify consistency. See the InfluxDB Enterprise documentation for detailed descriptions of each consistency option.
    db=<database>RequiredSets the target for the write.
    p=<password>Optional if you haven’t enabled authentication. Required if you’ve enabled authentication.Sets the password for authentication if you’ve enabled authentication. Use with the query string parameter u.
    precision=[ns,u,ms,s,m,h]OptionalSets the precision for the supplied Unix time values. InfluxDB assumes that timestamps are in nanoseconds if you do not specify precision.**
    rp=<retention_policy_name>OptionalSets the target for the write. InfluxDB writes to the DEFAULT retention policy if you do not specify a retention policy.
    u=<username>Optional if you haven’t enabled authentication. Required if you’ve enabled authentication.Sets the username for authentication if you’ve enabled authentication. The user must have write access to the database. Use with the query string parameter p.
    • The InfluxDB API also supports basic authentication.Use basic authentication if you’ve and aren’t using the query string parameters u and p.See below for an example of basic authentication.

    ** We recommend using the least precise precision possible as this can resultin significant improvements in compression.

    Examples

    Write a point to the database mydb with a timestamp in seconds
    1. $ curl -i -XPOST "http://localhost:8086/write?db=mydb&precision=s" --data-binary 'mymeas,mytag=1 myfield=90 1463683075'
    2. HTTP/1.1 204 No Content
    3. Content-Type: application/json
    4. Request-Id: [...]
    5. X-Influxdb-Version: 1.4.x
    6. Date: Wed, 08 Nov 2017 17:33:23 GMT
    Write a point to the database mydb and the retention policy myrp
    1. $ curl -i -XPOST "http://localhost:8086/write?db=mydb&rp=myrp" --data-binary 'mymeas,mytag=1 myfield=90'
    2. HTTP/1.1 204 No Content
    3. Content-Type: application/json
    4. Request-Id: [...]
    5. X-Influxdb-Version: 1.4.x
    6. Date: Wed, 08 Nov 2017 17:34:31 GMT
    Write a point to the database mydb using HTTP authentication

    Valid credentials:

    1. $ curl -i -XPOST "http://localhost:8086/write?db=mydb&u=myusername&p=mypassword" --data-binary 'mymeas,mytag=1 myfield=91'
    2. HTTP/1.1 204 No Content
    3. Content-Type: application/json
    4. Request-Id: [...]
    5. X-Influxdb-Version: 1.4.x
    6. Date: Wed, 08 Nov 2017 17:34:56 GMT

    Invalid credentials:

    1. $ curl -i -XPOST "http://localhost:8086/write?db=mydb&u=myusername&p=notmypassword" --data-binary 'mymeas,mytag=1 myfield=91'
    2. HTTP/1.1 401 Unauthorized
    3. Content-Type: application/json
    4. Request-Id: [...]
    5. Www-Authenticate: Basic realm="InfluxDB"
    6. X-Influxdb-Version: 1.4.x
    7. Date: Wed, 08 Nov 2017 17:40:30 GMT
    8. Content-Length: 33
    9. {"error":"authorization failed"}
    Write a point to the database mydb using basic authentication

    Valid credentials:

    1. $ curl -i -XPOST -u myusername:mypassword "http://localhost:8086/write?db=mydb" --data-binary 'mymeas,mytag=1 myfield=91'
    2. HTTP/1.1 204 No Content
    3. Content-Type: application/json
    4. Request-Id: [...]
    5. X-Influxdb-Version: 1.4.x
    6. Date: Wed, 08 Nov 2017 17:36:40 GMT

    Invalid credentials:

    1. $ curl -i -XPOST -u myusername:notmypassword "http://localhost:8086/write?db=mydb" --data-binary 'mymeas,mytag=1 myfield=91'
    2. HTTP/1.1 401 Unauthorized
    3. Content-Type: application/json
    4. Request-Id: [...]
    5. Www-Authenticate: Basic realm="InfluxDB"
    6. X-Influxdb-Version: 1.4.x
    7. Date: Wed, 08 Nov 2017 17:46:40 GMT
    8. Content-Length: 33
    9. {"error":"authorization failed"}

    Request body

    1. --data-binary '<Data in InfluxDB line protocol format>'

    All data must be binary encoded and in the format.Our example shows the —data-binary parameter from curl, which we will use inall examples on this page.Using any encoding method other than —data-binary will likely lead to issues;-d, —data-urlencode, and —data-ascii may strip out newlines orintroduce new, unintended formatting.

    Options:

    • Write several points to the database with one request by separating each pointby a new line.
    • Write points from a file with the @ flag.The file should contain a batch of points in the InfluxDB line protocol format.Individual points must be on their own line and separated by newline characters(\n).Files containing carriage returns will cause parser errors.

    We recommend writing points in batches of 5,000 to 10,000 points.Smaller batches, and more HTTP requests, will result in sub-optimal performance.

    Examples

    Write a point to the database mydb with a nanosecond timestamp
    1. $ curl -i -XPOST "http://localhost:8086/write?db=mydb" --data-binary 'mymeas,mytag=1 myfield=90 1463683075000000000'
    2. HTTP/1.1 204 No Content
    3. Content-Type: application/json
    4. Request-Id: [...]
    5. X-Influxdb-Version: 1.4.x
    6. Date: Wed, 08 Nov 2017 18:02:57 GMT
    Write a point to the database mydb with the local server’s nanosecond timestamp
    1. $ curl -i -XPOST "http://localhost:8086/write?db=mydb" --data-binary 'mymeas,mytag=1 myfield=90'
    2. HTTP/1.1 204 No Content
    3. Content-Type: application/json
    4. Request-Id: [...]
    5. X-Influxdb-Version: 1.4.x
    6. Date: Wed, 08 Nov 2017 18:03:44 GMT
    Write several points to the database mydb by separating points with a new line
    1. $ curl -i -XPOST "http://localhost:8086/write?db=mydb" --data-binary 'mymeas,mytag=3 myfield=89 1463689152000000000
    2. mymeas,mytag=2 myfield=34 1463689152000000000'
    3. HTTP/1.1 204 No Content
    4. Content-Type: application/json
    5. Request-Id: [...]
    6. X-Influxdb-Version: 1.4.x
    7. Date: Wed, 08 Nov 2017 18:04:02 GMT
    Write several points to the database mydb from the file data.txt
    1. $ curl -i -XPOST "http://localhost:8086/write?db=mydb" --data-binary @data.txt
    2. HTTP/1.1 204 No Content
    3. Content-Type: application/json
    4. Request-Id: [...]
    5. X-Influxdb-Version: 1.4.x
    6. Date: Wed, 08 Nov 2017 18:08:11 GMT

    A sample of the data in data.txt:

    1. mymeas,mytag1=1 value=21 1463689680000000000
    2. mymeas,mytag1=1 value=34 1463689690000000000
    3. mymeas,mytag2=8 value=78 1463689700000000000
    4. mymeas,mytag3=9 value=89 1463689710000000000

    Status codes and responses

    In general, status codes of the form 2xx indicate success, 4xx indicatethat InfluxDB could not understand the request, and 5xx indicate that thesystem is overloaded or significantly impaired.Errors are returned in JSON.

    Summary table

    HTTP status codeDescription
    204 No ContentSuccess!
    400 Bad RequestUnacceptable request. Can occur with an InfluxDB line protocol syntax error or if a user attempts to write values to a field that previously accepted a different value type. The returned JSON offers further information.
    401 UnauthorizedUnacceptable request. Can occur with invalid authentication credentials.
    404 Not FoundUnacceptable request. Can occur if a user attempts to write to a database that does not exist. The returned JSON offers further information.
    413 Request Entity Too LargeUnaccetable request. It will occur if the payload of the POST request is bigger than the maximum size allowed. See parameter for more details.
    500 Internal Server ErrorThe system is overloaded or significantly impaired. Can occur if a user attempts to write to a retention policy that does not exist. The returned JSON offers further information.

    Examples

    A successful write
    1. HTTP/1.1 204 No Content
    Write a point with an incorrect timestamp
    1. HTTP/1.1 400 Bad Request
    2. [...]
    3. {"error":"unable to parse 'mymeas,mytag=1 myfield=91 abc123': bad timestamp"}
    Write an integer to a field that previously accepted a float
    1. HTTP/1.1 400 Bad Request
    2. [...]
    3. {"error":"field type conflict: input field \"myfield\" on measurement \"mymeas\" is type int64, already exists as type float"}
    Write a point with invalid authentication credentials
    1. HTTP/1.1 401 Unauthorized
    2. [...]
    3. {"error":"authorization failed"}
    Write a point to a database that doesn’t exist
    1. HTTP/1.1 404 Not Found
    2. [...]
    3. {"error":"database not found: \"mydb1\""}
    Send a request body that is too large
    1. HTTP/2 413 Request Entity Too Large
    2. [...]
    Write a point to a retention policy that doesn’t exist