Data Logger Web Server API (1.0.3)

This documentation describes the API as implemented in the current released operating system for each model, or newer. Version numbers are from campbellsci.com.

Note: The API and documentation may change without notice. Validate behavior against the specific firmware version in use.

Note: This documentation is derived from, and audited against, the data logger firmware implementation.

The data logger exposes an HTTP API for data access and control. This section covers the request syntax common to every command and how access is secured.

Every ?command= request is a GET to the root path /. File upload and delete are the exception: they use PUT and DELETE on /{drive}/{path} (see Files). Send HTTP Basic credentials for a data logger user account (see Enabling security). For example, to read the two most-recent records of a table as JSON:

curl --user user:pass \
  'http://<datalogger>/?command=DataQuery&uri=dl:Public&mode=most-recent&p1=2&format=json'

The JSON response uses CSIJSON and has two parts. The head block describes the table: its environment and the schema for each field (name, type, units, and process). The data rows follow. Each row has a timestamp (time), a record number (no), and the field values (vals):

{ "head": { "environment": { "…": "…" }, "fields": [ "…" ] },
  "data": [ { "time": "2026-08-06T13:44:00", "no": 12, "vals": [ "…" ] } ] }

Check outcome, not just the HTTP status. A command that fails still returns 200. The outcome value in the body tells you whether it worked, and what counts as success depends on the command:

• SetValueEx, ClockCheck, and ClockSet: outcome=1 means success.
• FileControl: outcome=0 means success. Any other value is an error code.

Next: use DataQuery to retrieve records (five modes, all formats), and BrowseSymbols to list the tables and fields you can query. The sections below cover request syntax, response formats, security, and error handling.

Commands generally follow the form:

<URL>?command=<CommandName>&uri=<DataSource>&<arguments>

• Put command= first, right after the ?. The server finds every other argument by the & in front of it, so it ignores any other argument that comes right after the ?.
• Arguments are appended with &; optional arguments use a default. Argument names are not case-sensitive.
• uri / the dl: scheme — the data source. When querying the data logger directly it is the top-level source, so uri=dl: (or omitting uri) is assumed. A table or field is addressed as dl:<table> or dl:<table>.<field>.
• Credentials in the URL — a username/password may be supplied inline, for example http://admin:12345@192.168.24.62/?command=ClockCheck. Read Security guidance before you use this form.

Note: The server accepts : and / in a value either as is or percent-encoded, so uri=dl:Public and uri=dl%3APublic are the same request. For what you must encode, see URL escape codes.

Note: Operations below are shown with placeholder paths (for example, /DataQuery) because OpenAPI cannot put a query string in a path. The real request is always against / with ?command=<CommandName>. The first line of each operation's description gives the real URL, and so does its x-request-url value in openapi.yaml.

Input — the time argument of ClockSet and the timestamps in DataQuery p1 and p2:

• Use ISO 8601 with a T between the date and the time: YYYY-MM-DDTHH:MM:SS, with optional fractional seconds. For example, 2026-07-30T16:15:31 or 2026-07-30T16:15:31.25.
• You can leave off trailing parts. They default to zero, so 2026-07-30 means midnight.
• Don't use a space instead of the T. The server ignores the time of day and uses midnight.
• Don't add a timezone suffix such as Z or -07:00. The server ignores it, and it can corrupt or drop the fractional seconds. Every time is the data logger's local clock time.

Output — times in responses are the data logger's local time, with no timezone:

• json and xml use a T: 2026-07-30T16:15:31.25
• html and toa5 use a space: 2026-07-30 16:15:31.25

• Default ports: HTTP on 80, HTTPS on 443. Every model serves HTTP/1.1. HTTP/2 runs on the CR6, CR1000X(e), Granite 6, Granite 9, and Granite 10 only; the CR300, CR310, and CR350 use HTTP/1.1 only. Where it is supported, HTTP/2 runs only over TLS (port 443) — port 80 is always HTTP/1.1. TLS uses mbedTLS and supports session resumption.
• Methods: GET, POST, PUT, and DELETE. POST carries HTML form submissions; PUT/DELETE operate on /{drive}/{path} files.
• The server is reachable over any active interface — Ethernet, Wi-Fi, cellular, or USB (RNDIS) — on both IPv4 and IPv6. Address the data logger by DNS/host name (for example, datalogger.local), IPv4 address, or IPv6 address. In a URL, wrap an IPv6 literal in square brackets — for example, http://[2001:db8::10]/?command=ClockCheck. A link-local address (one that starts with fe80:) also needs a zone ID. The zone ID names the network interface on your computer that reaches the data logger. Write it after a %25 (an encoded %), for example http://[fe80::1%25eth0]/. USB (RNDIS) connections are treated as trusted for access-control purposes (see Enabling security).
• Responses use either Transfer-Encoding: chunked or a Content-Length header, and may be gzip-compressed (Content-Encoding: gzip). File downloads carry Cache-Control: no-cache; ?command= responses don't carry a Cache-Control header. The server does not serve range/partial requests (Accept-Ranges: none) — always request whole files.
• File uploads (PUT) accept either a Content-Length body or Transfer-Encoding: chunked. A Transfer-Encoding header that is not chunked is rejected with 500; an over-size Content-Length returns 413.

The server sends no CORS headers. Responses never include Access-Control-Allow-Origin or any other Access-Control-* header. Over HTTP/1.1, the server also drops OPTIONS (preflight) requests without a reply.

So a web page from another origin can't read API responses. Its browser can still send a simple GET, though (see Security guidance). To call the API from a web app, serve the page from the data logger itself, or send the requests through your own server.

• Records per DataQuery: there's no fixed maximum. A query returns at most the records the table holds. A larger p1 count (most-recent) or p3 count (since-record) is cut to that number.
• Paging a large query: use mode=since-record. Set p3 to your page size and p1 to one more than the last record number (no) you received, because since-record includes record p1. Repeat until a page comes back empty. Record numbers can wrap (see Data).
• Upload size: a PUT with a Content-Length over 2,147,483,600 bytes returns 413. In practice, the free space on the drive sets the limit (507).
• Idle timeout (HTTP, port 80): the data logger closes a connection when it has sent nothing for 60 seconds. It closes a connection within 40 seconds when the request headers don't arrive in full.
• Concurrent HTTPS connections: set by the TLSConnections setting in Device Configuration Utility.

Most data commands accept a format argument that selects the response format:

Unrecognized values fall back to html.

toa5 and tob1 are record-table formats supported only by data-retrieval commands (DataQuery). Every other command supports html, json, and xml only. Each operation below lists the formats it supports.

Note: tob1 responses use the nonstandard type binary/octet_stream, not application/octet-stream. Don't match the Content-Type strictly.

Two mechanisms can be set on the data logger:

1. Numeric security code (legacy) — set in the Status table via SetSecurity / Security() to 1–65534, for up to three levels. You can't supply this code in an HTTP request. The web server doesn't accept it, so it has no way to grant access:
   • When user accounts exist, the web server ignores the numeric code.
   • When no user accounts exist and one or two levels are set, the web server ignores the code. Every request gets Read-Only access.
   • When no user accounts exist and all three levels are set, the web server refuses every request with 404. To use the API, create user accounts.
2. Account Manager (HTTP Basic auth) — user accounts created in Device Configuration Utility. When enabled, the PakBus/TCP password and numeric code are not used for HTTP.

Access levels. Every request is authorized at one of four levels (the numeric code is what CheckAuthorization reports):

Code 4. CheckAuthorization reports 4 instead of 3 when the data logger has no user accounts. The access is the same as 3: Read-Only. The difference is what a client can do about it. With 3, other credentials might get more access. With 4, no credentials can, because every request gets Read-Only until an administrator creates user accounts. So treat 4 as Read-Only, and don't ask the user to sign in again.

Anonymous and failed sign-ins. A request with no Authorization header is treated as the built-in anonymous user. When no user accounts exist, anonymous and failed sign-ins both get Read-Only access. If a request resolves to None, the data logger returns 401 to prompt for credentials instead of serving it.

USB (RNDIS) connections get All access without a sign-in. To make USB connections sign in like any other, turn on the USBNotTrusted setting in Device Configuration Utility.

• Use HTTPS. Over HTTP (port 80), Basic auth sends the user name and password in cleartext. Base64 encoding isn't encryption.

• Keep credentials out of the URL. A URL such as http://user:pass@host/ can end up in logs, browser history, and bookmarks. Send an Authorization header instead.

• State-changing commands are GETs. ClockSet, SetValueEx, and FileControl change the data logger, but they're plain GET requests. Anything that loads a URL can trigger them: link prefetchers, link scanners in email and chat, and cross-site request forgery (CSRF) from another web page. A browser that has saved your credentials sends them along.

  If you build a browser-based client:

  • Don't show these requests as links, and don't let a page load them on its own.
  • Ask the user to confirm before you send one.
  • Sign in with the lowest access level that works. For example, use a Read-Only account for a dashboard.
  • Keep the data logger off networks you don't trust.

On failure the server returns a standard HTTP status with a short HTML or header-only body:

Successful command responses (200) also carry a per-command outcome code in the body. See Check outcome, not just the HTTP status under Your first request, and each command for its codes.

Authorization checks.

Reading measurement data and browsing the symbol/table namespace.

Data tables. Measurements are stored in data tables. Each table is a fixed-size ring buffer of records. When a table fills up, the oldest records are overwritten. So you can retrieve only a limited, moving window of history. That window is held in CPU RAM. A memory card, onboard flash, or SSD can extend it further back. Each record has:

• a record number (no) — it increases by one per record and is not reset in normal operation. Only a program recompile or table re-initialization resets it. It is a 32-bit unsigned counter, so treat it as an opaque serial number that can wrap.
• a timestamp (time) — the record's time on the logger's local clock, at sub-second resolution. No timezone offset is included.

Each field descriptor reports a type (for example xsd:float, xsd:unsignedInt, or xsd:string with string_len) and a process. The process is the CRBasic operation that produced the field: Smp (sample), Avg (average), Max, Min, and so on. Invalid or not-a-number floating-point values are written as the string "NAN".

Setting public/variable values.

Reading and setting the data logger clock.

File operations — the ?command= file commands and the method-level PUT/GET/DELETE on /{drive}/{path}.

Drives. Files live on named drives, addressed as <drive>:<path> (for example CPU:program.cr1x). In a URL the first / becomes the :, so that path is /CPU/program.cr1x. The set of drives varies by model. Query the root (GET /?command=ListFiles) to see what a given data logger has. Upload (PUT), download (GET), and delete (DELETE) accept the same drives: every drive the data logger has.

All drives are FAT: file and drive names are case-insensitive (case-preserving), and long file names are supported. cpu:program.CR1X and CPU:PROGRAM.cr1x address the same file.

Percent-encode these reserved characters wherever they appear in a value in the URL.

How the server decodes a URL. The server decodes every %xx escape in the path and the query string. It does this before it splits the query into arguments. That has these effects:

• : and / work either way. uri=dl:Public and uri=dl%3APublic are the same request, and so are File=CPU:file.dat and File=CPU%3Afile.dat.
• + is a space in the query string. p1=2026-07-30+16:15:31 sends a space. For a literal plus sign, send %2B. In the path (a file name in /{drive}/{path}), + stays a plus sign.
• A value can't contain &. Because the server decodes first, %26 turns back into & and ends the argument, just like a raw &.

You don't need to encode ~. It's an unreserved character in RFC 3986, like letters, digits, -, ., and _.

The data logger exposes two other real-time interfaces, each documented separately:

• WebSocket API — the JSON message protocol over a WebSocket connection for live data streaming.
• MQTT API — publish and subscribe over MQTT: topic structure, MQTT settings, command and control, Campbell Cloud onboarding, recipes, the JSON data formats for state, status, and metadata, and the CRBasic MQTT instructions.

The version shown at the top of this document tracks the documentation, not the firmware. Each firmware release also carries its own version (see Supported models and OS versions).