Skip to content


Kurl is a REST client that lives in a worker thread, and provides sync and async methods callable from q

Kurl provides ease-of-use cloud integration by registering Azure, Amazon, and Google Cloud Platform authentication information.

When running

  • on a cloud instance, and a role is available, Kurl will discover and register the instance metadata credentials
  • outside of the cloud, OAuth2, ENV, and file-based credential methods are supported

Quick start


Kurl performs automatic registration of Azure, Google Cloud Platform, and Amazon instance metadata credentials. These temporary credentials are stored in memory, and are never persisted to disk, or otherwise returned to the user. Amazon, Azure, and Google Cloud rotate these secrets for you, and the library is simply reading them, and replacing its in-memory cache when they expire.

Similarily, OAuth2 SSO is another form of registration the library supports, when client specification data is made available. This method uses temporary access tokens, generated as part of single sign on. Kurl stores only the access tokens; user credentials never make their way into the library.

Using temporary credentials is highly recommended because they are rotatable, typically have limitations on the resources they may access, and are not as vunerable to trivial attacks suc as copy-paste.

However, support for environment variable, credential file, and Basic Auth are available. They are recommended for use only on trsuted workstations, e.g. development machines.

Basic Auth is insecure and will have the library save your credentials directly in memory. They cannot be accessed from q; however we do not encrypt them.

Environment variables

Environment variables that modify the behaviour of Kurl:


Set to 1 to enable debug logs from Kurl


Set to 1 to prevent Kurl from automatically registering cloud credentials: see Automatic Registration using Credential Discovery


Set to a space-separated list of resource IDs to register with only a specific set of Azure resources instead of all Azure resources


Set to an absolute path where the Kurl source has been saved


Set to 1 to prevent Kurl from automatically opening a browser when using OAuth2 login flow

Requests API

The Kurl API defines two calls for making HTTP/HTTPS requests

.kurl.sync  (url;method;options)
.kurl.async (url;method;options)


  • url is a string, e.g. ""
  • method is a string, either "GET" or "POST"
  • options is a dictionary, e.g.

    `body`headers!("{}";("Accept";"Content-Type"))!2#enlist "application/json")

Possible entries in options and their datatypes:


request body (10h)

e.g. .kurl.sync (url; method;``body!(::;.j.j `a`b`c!1 2 3))


async callback( -11 100 104 105h)

e.g. .kurl.async (url; method;``callback!(::;{show x}))


HTTP PUT file (10h)

e.g. .kurl.sync (url; method; ``file!(::;"/tmp/file.txt))


flag to enable following redirect Location (-1h)

e.g. .kurl.sync (url; method; ``follow_redirects!(::;1b))


request headers (99h)

e.g. .kurl.sync(url;method;``headers!(::;enlist["Content-Type"]!enlist "application/json"))


flag to enable curl --insecure (-1h)

e.g. .kurl.sync (url; method; ``insecure!(::;1b))


flag to include response headers (-1h)

e.g. .kurl.sync (url; method; ``response_headers!(::;1b))


max number of redirects (-6 -7h)

e.g. .kurl.sync (url; method; ``max_redirects!(::; 5))


max attempts for exponential backoff (-6 -7h)

Kurl retries on 503 errors by default, up to 10 times. Set max_retry_attempts to 0 to disable, or anything else to set a max other than 10.

When Kurl retries requests, it does not reset any signed headers, or temporal headers. If the server refuses requests older than a given time, retried requests will still fail. This is intentional. Your application can handle longer retries by re-issuing the request.

e.g. .kurl.sync (url; method; ``max_retry_attempts!(::; 5))


Azure-specific flag (-1h). Azure Header Signing V2 has some exclusive options to handle inconsistencies between Azure Monitor and Azure Storage.

e.g. .kurl.sync (url; `POST; ``sign_query!(::;1b))

For Azure Authentication, query strings are not signed in the CanonicalizedResource portion of the signature if the method is POST. (You should never need to set this option, however it exists in case we discover an edge case.)


session name; see tenants (10 -11h)

e.g. .kurl.sync (url; method;``tenant!(::;"bob"))


request timeout (milliseconds) (-6 -7 -12 -16h)

e.g. .kurl.async (url; method; `callback`timeout!(cb; 5000))

When using HTTP PUT, specify body or file, not both. Leaving both blank is acceptable, if the REST server being queried looks at the querystring.

Backoff time

Backoff time (ms) is calculated with the following C equivalent, where n is the number of failed attempts – 1:

100 * 2 xexp n

The first retry would happen in 100ms, then 200, then 400, 800, 1600, etc…

The timeout flag takes precedence over retry attempts remaining, so if a timeout of 5000 milliseconds is supplied, a request will time out in 5 seconds regardless of how many attempts would be left.


By default, responses are a two-item list of (statusCode; responseBlob)

Based on the content type of the response, the responseBlob will be a string (10h), or bytes (4h)

If the response_headers parameter is passed as an option, the response will be a three-item list of (statusCode; responseBlob; responseHeadersText)

The response header text returned will be the raw text (separated by \r\n).

Reserved headers

The following headers are reserved. (Kurl sets them automatically.)

Authorization           (note 1)
x-amz-date              (note 2)
x-amz-content-sha256    (note 2)
x-amz-security-token    (note 2)
x-ms-date               (note 2)
  1. Only set if .kurl.register has been called for the given host
  2. Only set if (1) is true, and if using Azure, or Amazon where applicable

Since Kurl is a general library, you are free to perform authentication yourself, as long as you do not also register the host.

.kurl.sync (url;`GET;``headers!(::;enlist["Authorization"]!enlist "Basic ..."))

Proxy environment variables

HTTPS/HTTPS requests can go through a proxy by setting the http_proxy and https_proxy environment variables respectively.

Environment variables http_proxy and https_proxy support the same syntax as command-line curl.

Libcurl tutorial

Variable no_proxy can be set to a list of domains to ignore.

# Use a SOCKS5 proxy for outgoing HTTPS requests
# Note that https_proxy refers to the request being https, not the protocol of the proxy itself
export https_proxy=socks5://localhost:8443

Registration API

Registering with Kurl will cause requests made against a given domain wildcard to use cached authentication information.

Registration for several services may be done automatically on startup of the library. This is described below in Automatic Credential Discovery.

The Kurl API defines one call for registration with authentication endpoints and can be used to manually register when the automatic discovery does not cover your application.

.kurl.register (type; domain; tenant; authInfo)

The tenant is a session name, username, ID, etc., meaningful to your application.

type       -11h       one of aws_cred, aws_sts, oauth2, oauth2_jwt, azure, basic
domain     10h        wildcard for domain
tenant     10h/-11h   session key required for sync/async to use authInfo
authInfo   0h         authentication info specific to the type

More on domains and tenants

// Use AWS ENV whenever a request is made with no tenant


.kurl.register (aws_cred; "*"; ""; authInfo)
.kurl.sync (url; `GET; ::);

// Use AWS ENV whenever a request is made with a tenant "bob"
.kurl.register (aws_cred; "*"; "bob"; authInfo)
.kurl.sync (url; `GET; ``tenant!(::;"bob"));

A deregistration API for cleanup:

.kurl.deregister (domain; tenant)

Automatic registration using credential discovery

Registration with Kurl is done automatically for Amazon Web Services, Google Cloud Platform, and Azure when the library starts up and it detects those vendors.

Credentials are discovered according to a credential provider chain. This is a hierarchy of places to look for credentials. The hierarchy can change between providers.

When credentials are found they are automatically fed into the registration function to authenticate with the cloud provider via .kurl.register.

This automatic behaviour can be disabled by setting the environment variable KX_KURL_DISABLE_AUTO_REGISTER to 1.

The hierarchy of checks is

  1. Using credentials from AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY
  2. Using credentials from $HOME/.aws/credentials
  3. Using credentials from AWS_SHARED_CREDENTIALS_FILE
  4. Using IAM roles for service accounts via the AWS_ROLE_ARN and AWS_WEB_IDENTITY_TOKEN_FILE environment variables
  5. Using credentials from instance metadata if on an EC2 instance (checked via grep -q ^ec2 /sys/hypervisor/uuid 2>/dev/null - see here)
  6. Using credentials from instance metadata if on an EC2 instance (checked via grep -q '^Amazon EC2$' /sys/devices/virtual/dmi/id/bios_vendor 2>/dev/null - see here)
  1. Using credentials from internal metadata if on an GCP instance (checked via grep -q '^Google Compute Engine$' /sys/devices/virtual/dmi/id/product_name 2>/dev/null - see here)
  2. Using credentials from the Gcloud CLI command gcloud auth print-access-token if gcloud is installed
  1. Using credentials from instance metadata if on an Azure instance (checked via grep -q '^7783-7084-3265-9085-8269-3286-77$' /sys/devices/virtual/dmi/id/chassis_asset_tag 2>/dev/null - see here)
  2. Using credentials from the az CLI command az account get-access-token if az is installed

Registration inputs

Registration API for common type information


When making calls to a RESTFul API, you supply an HTTP/HTTPS endpoint. An endpoint is a URI with the scheme [protocol://]host[:port]/path?query.

When registering authentication inputs with the library, domain names may be provided as wildcards. This tells the library to apply authentication when requests are made that match the domain

// Register OAUth2 login for domain
.kurl.register (`oauth2; "*"; ...)

// When you make requests to the domain, 
// the supplied info (...) will be used
// For example, use the same info for storage and logging
.kurl.sync ("; `POST; ...) // Will match registration
.kurl.sync ("; `POST; ...) // Will match registration

When registering authentication inputs, you may provide an exact match to a protocol, host, and port. This tells the library to apply authentication when requests are made that exactly match the protocol, host and port.

// Register OAuth2 login for specifically https logging URI
.kurl.register (`oauth2; ""; ...)

.kurl.sync ("; `POST; ...) // Will not match registration
.kurl.sync ("; `POST; ...) // Will match registration

When this document refers to the domain parameter of the registration API, it is important to remember domains may be taken literally as domain names (wildcards) or they may be full URLs to match against, without the path and query component.


When registering with Kurl, an optional tenant key may be provided. Providing this key when registering will mean only requests that resupply the tenant will use the associated authentication information, along with the matching domain.

Tenants can be thought of as an session key. Using tenants, applications can be built to support multiple sessions. An application could maintain a mapping of tenants to what your application considers session metadata.

For some applications, .z.u may be a sensible choice for a tenant.

// If current connection handle is defined, use existing authenticated username
// else use the default service account, no user triggered this call 
// .e.g the timer triggered
tenant:[.z.w = 0i; ""; .z.u]

For simple applications, it may be reasonable to not use tenants and use an empty string, because the idea of sessions may not apply.

When registering automatically, Kurl will use an empty string for the tenant. This represents a default service account (IAM). If a tenant is not explicitly provided when registering, it is the same as explicitly providing an empty string.

Info API

These requests are used to list information. These calls are meant to be called outside of async callbacks because Kurl cleans up garbage lazily.

For example, listing ongoing transfers inside a callback will include the ‘current’ finished connection despite the fact it’s done.

These API calls live in a ‘dot i’ namespace to indicate they are internal and subject to change. They are only meant to be used for debugging at this point in time, not for maintaining state you rely on.

List the names of ongoing requests.

show .kurl.i.ongoingRequests[]

Return a table of registered tenants and domains

show .kurl.i.listRegistered[]