Skip to main content

Configuring the CLI

This section covers how to authenticate and configure re. It assumes you have installed the CLI, see installation instructions.

The quick setup section is a short step by step reference for how to get started and configure the CLI. The rest of the page contains detailed instructions and goes into all of the available options.

Quick setup

Install the command line tool for your platform (Linux, Mac, and Windows are supported).

Create a named context to avoid having to enter your tenant endpoint and API token every time. Provide your tenant endpoint:

re config add --name main --endpoint https://<my_api_endpoint>/

You will be asked to paste your API token:

I A new context `main` will be created.
I New context `main` was created.

Try running a command to see everything works, e.g.

re get datasets

You can use the -c or --context global flag to use a specific context with the command, e.g.

re -c main get datasets

Any of the context settings can be overwritten as a one off using global flags such as --token, --endpoint and --proxy etc. Command line arguments take precedence over the context settings.

Supplying credentials every time

The simplest way to authenticate the CLI is to specify the endpoint and API token for every command. By default re will prompt you to enter the token interactively.

For example, to list the available datasets

➜ re --endpoint get datasets
input: Enter API token [none]: MYSUPERSECRETAPITOKEN
Name ID Updated (UTC) Title
InvestmentBank/collateral-streams aa9dda7c059e5a8d 2019-04-30 17:25:03 IB Collateral Streams
InvestmentBank/george-test 1aaeacd49dfce8a0 2019-05-10 15:32:34 Test Dataset
InvestmentBank/margin-call b9d50fb2b38c3af5 2019-05-08 07:51:09 IB Margin Call
InvestmentBank/margin-call-large 6d00b9f69ab059f6 2019-05-11 09:23:43 IB Margin Call Large

The token can also be specified using --token

➜ re --endpoint --token MYSUPERSECRETAPITOKEN get datasets

This is generally not a good idea as the API token will be stored in your shell history. It would be better to store the API token in an environment variable.

➜ re --endpoint --token $REINFER_TOKEN get datasets

However, this is still verbose, repetitive and unsafe.


Supplying configuration using command line flags can be useful in some cases. However, the recommended way of using the CLI is by configuring a named context, see below.

Named contexts

A context is a collection of settings and credentials that you can apply to an re command. When you specify a context to run a command, the settings and credentials are used to run that command. Multiple contexts can be stored in the configuration file.

Contexts help avoid having to manually specify a token, endpoint and other configuration with every command. A context is composed of

  • A memorable name which serves as an identifier for the context
  • An API token used to authenticate the user making requests
  • An endpoint to which the CLI will make the requests
  • (Optional) An HTTP proxy to use for all requests
  • (Optional) Whether to accept invalid TLS certificates from the endpoint (only useful for internal / dev Re:infer clusters)

You can specify one default context that is used when none is explicitly referenced.

The global -c, --context flag can be used to use a specific context have names that you can specify as a parameter on the command line for individual commands.

Creating a context

You can create a new context or modify an existing one with

re config add

If run with no options, the command will interactively ask for the context name, endpoint and token.

➜ re config add
* Context name: acme-prod
I A new context `acme-prod` will be created
* Enter API token [none]: MYSUPERSECRETTOKEN
* Endpoint []:
I Default context set to `acme-prod`
I New context `acme-prod` was created

When creating the very first context, this will be set as the active one

➜ re config add --name acme-dev --endpoint
I A new context `acme-dev` will be created.
* Enter API token [none]: MYSUPERSECRETTOKEN
I Default context set to `acme-dev`
I New context `acme-dev` was created.

Adding a context with a name that already exists will instead update that context.

# Edit the acme-dev context if it already exists
re config add acme-dev

To see all options run, re config add -h, the most important ones are


--name <name>The name of the context that will be created or updated
--endpoint <endpoint>The Re:infer cluster endpoint that will be used for this context
--token <token>The reinfer API token that will be used for this context
--proxy <proxy>URL for an HTTP proxy that will be used for all requests if specified

The current context will be used for all subsequent commands. The following will print all datasets for the current context.

re get datasets

Any of the context settings can be overwritten as a one off using global flags such as --token, --endpoint and --proxy.

re --proxy http://proxy.example get datasets

Using a context

You can use the -c or --context global flag to use a specific context with the command, e.g.

re -c my-context get datasets

re config

All operations to do with managing named contexts are scoped under re config command. The subcommands allow one to create, update, set the default and delete contexts and more.

See the command reference for all the available options.

Where are configuration settings stored?

The location of your configuration directory location varies based on the operating system. The Re:infer command line tool respects these OS defaults and typically the configuration directory can be found at

  • ~/.config/reinfer on Linux
  • $HOME/.config/reinfer on macOS
  • %AppData%\reinfer on Windows

The context settings are stored in a JSON file contexts.json, for example ~/.config/reinfer/contexts.json on Linux. It looks something like this

"current_context": "prod",
"contexts": [
"name": "prod",
"endpoint": "",
"accept_invalid_certificates": false,
"proxy": null