Skip to content
Visit Logs on GitHub
Set theme to dark (⇧+D)

Understanding the Logpush API


The table below summarizes the job operations available.

The <zone_id> argument is the zone id (hexadecimal string), which can be found using API's zones endpoint. The <job> argument is the numeric job id. The <dataset> argument indicates the log category (such as http_requests, spectrum_events, or firewall_events).

POSTCreate job<zone_id>/logpush/jobs
GETRetrieve job<zone_id>/logpush/jobs/<job>
GETRetrieve all jobs for all data sets<zone_id>/logpush/jobs
GETRetrieve all jobs for a data set<zone_id>/logpush/datasets/<dataset>/jobs
GETRetrieve all available fields for a data set<zone_id>/logpush/datasets/<dataset>/fields
GETRetrieve all default fields for a data set<zone_id>/logpush/datasets/<dataset>/fields/default
PUTUpdate job<zone_id>/logpush/jobs/<job>
DELETEDelete job<zone_id>/logpush/jobs/<job>
POSTCheck whether destination exists<zone_id>/logpush/validate/destination/exists
POSTGet ownership challenge<zone_id>/logpush/ownership
POSTValidate ownership challenge<zone_id>/logpush/ownership/validate
POSTValidate log options<zone_id>/logpush/validate/origin

For concrete examples, see the tutorial Manage Logpush with cURL.


The Logpush API requires credentials like any other Cloudflare API.

$ curl -s -H "X-Auth-Email: <REDACTED>" -H "X-Auth-Key: <REDACTED>" \    '<ZONE_ID>/logpush/jobs'


Before creating a new job, ownership of the destination must be proven.

To issue an ownership challenge token to your destination:

$ curl -s -XPOST<ZONE_ID>/logpush/ownership -d '{"destination_conf":"s3://<BUCKET_PATH>?region=us-west-2"}' | jq .

A challenge file will be written to the destination, and the filename will be in the response (the filename may be expressed as a path if appropriate for your destination):

{  "errors": [],  "messages": [],  "result": {    "valid": true,    "message": "",    "filename": "<path-to-challenge-file>.txt"  },  "success": true}

You will need to provide the token contained in the file when creating a job.


You can specify your cloud service provider destination via the required destination_conf parameter.

  • AWS S3: bucket + optional directory + region + optional encryption parameter (if required by your policy); for example: s3://bucket/[dir]?region=<region>[&sse=AES256]
  • Datadog: Datadog endpoint URL + Datadog API key + optional parameters; for example: datadog://<DATADOG-ENDPOINT-URL>?header_DD-API_KEY=<DATADOG-API-KEY>&service=<SERVICE>&host=<HOST>&ddsource=<SOURCE>
  • Google Cloud Storage: bucket + optional directory; for example: gs://bucket/[dir]
  • Microsoft Azure: service-level SAS URL with https replaced by azure + optional directory added before query string; for example: azure://<BlobContainerPath>/[dir]?<QueryString>
  • Splunk: Splunk endpoint URL + Splunk channel ID + insecure-skip-verify flag + Splunk sourcetype + Splunk authorization token; for example: splunk://<SPLUNK-ENDPOINT-URL>?channel=<SPLUNK-CHANNEL-ID>&insecure-skip-verify=<INSECURE-SKIP-VERIFY>&sourcetype=<SOURCE-TYPE>&header_Authorization=<SPLUNK-AUTH-TOKEN>
  • Sumo Logic: HTTP source address URL with https replaced by sumo; for example: sumo://<SumoEndpoint>/receiver/v1/http/<UniqueHTTPCollectorCode>

For S3, Google Cloud Storage, and Azure, logs can be separated into daily subdirectories by using the special string {DATE} in the URL path; for example: s3://mybucket/logs/{DATE}?region=us-east-1&sse=AES256 or azure://myblobcontainer/logs/{DATE}?[QueryString]. It will be substituted with the date in YYYYMMDD format, like 20180523.

For more information on the value for your cloud storage provider, consult the following conventions:

To check if a destination is already in use:

$ curl -s -XPOST<ZONE_ID>/logpush/validate/destination/exists -d '{"destination_conf":"s3://foo"}' | jq .


{  "errors": [],  "messages": [],  "result": {    "exists": false  },  "success": true}

There can be only 1 job writing to each unique destination. For S3 and GCS, a destination is defined as bucket + path. This means two jobs can write to the same bucket, but must write to different subdirectories in that bucket.

Job object


Logpush repeatedly pulls logs on your behalf and uploads them to your destination.

Log options, such as fields or sampling rate, are configured in the logpull_options job parameter (see Logpush job object schema). For example, the following query gets data from the Logpull API:

curl -sv \    -H'X-Auth-Email: <REDACTED>' \    -H'X-Auth-Key: <REDACTED>' \    "<ZONE_ID>/logs/received?start=2018-08-02T10:00:00Z&end=2018-08-02T10:01:00Z&fields=RayID,EdgeStartTimestamp"

In Logpush, the Logpull options would be: "logpull_options": "fields=RayID,EdgeStartTimestamp". See Logpull API parameters for more info.

If you don't change any options, you will receive logs with default fields that are unsampled (i.e., sample=1).

The three options that you can customize are:

  1. Fields: See Log fields for the currently available fields. The list of fields is also accessible directly from the API:<zone_id>/logpush/datasets/<dataset>/fields. Default fields:<zone_id>/logpush/datasets/<dataset>/fields/default.
  2. Sampling rate: Value can range from 0.001 to 1.0 (inclusive). sample=0.1 means return 10% (1 in 10) of all records.
  3. Timestamp format: The format in which timestamp fields will be returned. Value options: unixnano (default), unix, rfc3339.

To check if logpull_options is valid:

$ curl -s -XPOST<ZONE_ID>/logpush/validate/origin -d '{"logpull_options":"fields=RayID,ClientIP,EdgeStartTimestamp&timestamps=rfc3339","dataset": "http_requests"}' | jq .


{  "errors": [],  "messages": [],  "result": {    "valid": true,    "message": "",  },  "success": true}


The following actions are recorded in Cloudflare Audit Logs: create, update, and delete job.