Fetch your first config value

Once you have:

• a project
• an environment
• a config entry
• a working parameter or a published release, depending on the source you plan to read
• an API key

you can read a value over HTTP.

The shortest way to prepare those pieces is:

nona init --yes --base-url https://nona.example.com --email admin@example.com --password <password> --project storefront

The command prints the environment id, the one-time API key, and a verification curl for the seeded Features:Example flag. Save the key before the command output is discarded.

What to prepare first

In admin:

1. open Projects
2. open the project
3. select the target environment
4. make sure the parameter exists
5. create an API key in the API Keys section

For the simplest first test, use a boolean key such as Features:Checkout.

With the CLI, that setup can look like:

nona entries set \
  --project storefront \
  --environment production \
  --key Features:Checkout \
  --value true \
  --scope client \
  --content-type boolean

nona keys create \
  --project storefront \
  --name "HTTP test" \
  --scope client \
  --environment production

The first request below uses working parameters, so no release is required. Publish a release only for a release-route request; set it active only when using the /releases/active/ route.

Request shape

GET /api/environments/{environmentId}/parameters/{key}
X-Api-Key: <api-key>

The request includes:

• the environment id
• the config key
• an explicit working or release source in the path
• either active or an exact/wildcard version segment on release routes
• an API key in the header

The project is implied by the API key, which is why it is not part of this request path. The working route always reads editable working parameters. Release routes explicitly select active or a version. A release request never falls back to working parameters.

Example

curl "https://nona.example.com/api/environments/production/parameters/Features%3ACheckout" \
  -H "X-Api-Key: $NONA_API_KEY"

If you want to inspect the response headers too:

curl -i "https://nona.example.com/api/environments/production/parameters/Features%3ACheckout" \
  -H "X-Api-Key: $NONA_API_KEY"

The key path segment must be URL-encoded. For example:

• Features:Checkout -> Features%3ACheckout

To pin a published release instead of using the active release:

curl "https://nona.example.com/api/environments/production/releases/1.1.x/parameters/Features%3ACheckout" \
  -H "X-Api-Key: $NONA_API_KEY"

What a successful first read proves

If this request works, you have validated that the Nona instance is reachable, the environment and key exist, the API key is valid, and the API key scope can read the entry. That makes it the best milestone before you integrate one of the official clients.

Fast troubleshooting

If the request fails:

1. confirm the environment name is correct
2. confirm the key exists in that environment
3. confirm the key path is URL-encoded
4. confirm that you chose the intended working or release route
5. for a release route, confirm the expected release is active or put an exact or wildcard selector in the route
6. confirm the API key belongs to the same project
7. confirm the API key scope can read the entry scope

Step-by-step API read summary

Use this sequence for the shortest first-read test:

1. create or confirm one parameter exists
2. create or confirm one API key exists
3. copy the environment id
4. URL-encode the key name
5. send the working-route HTTP request with X-Api-Key
6. verify the value comes back correctly

For a release-route test, also publish the requested release and set it active when using the active-release route.

First API call FAQ

Why is the project name not in the HTTP path?

The API key already scopes the request to a project.

That is why the request path only needs the environment id and key.

Do I need to URL-encode the key?

Yes.

Keys such as Features:Checkout must be URL-encoded in the path, for example as Features%3ACheckout.

Should I test over HTTP before using an SDK?

Yes, in most cases.

A direct HTTP read is the simplest way to prove the instance, key, environment, and API key are all aligned before you add SDK code.

What should I do after the first successful read?

Either keep using direct HTTP for a very small integration, or move to the JavaScript or .NET client for application code.

What to do next

After the first direct HTTP read, most teams either keep using HTTP for a very small integration, switch to JavaScript or .NET for application code, or add a kill switch as the first operational flag. For full endpoint behavior, see HTTP.

Next: Add a kill switch