Skip to content

Clients and API

Nona can be read through several integration paths.

The right one depends on how much abstraction your application needs and what runtime you are working in.

  • HTTP for the smallest raw request path
  • JavaScript for Node.js, TypeScript, and related environments
  • .NET for C# services and applications
  • OpenFeature for a vendor-neutral feature-flag interface

Before choosing a client, make sure the runtime can actually read something:

  1. open Projects in the admin UI
  2. create or open the project
  3. create the target environment such as production
  4. create a parameter or feature flag
  5. create an API key with the right scope

If you prefer the CLI for the data setup step:

Terminal window
nona entries set \
--project storefront \
--environment production \
--key Features:Checkout \
--value true \
--scope client \
--content-type boolean
nona keys create \
--project storefront \
--name "Web app" \
--scope client \
--environment production

Choose HTTP when:

  • you want the smallest possible integration
  • your language does not need an official client
  • you are validating reads during setup or migration

Choose JavaScript when:

  • your application is in JavaScript or TypeScript
  • you want a direct client API
  • you want optional TTL cache behavior

Choose .NET when:

  • your application is in C#
  • you want typed JSON reads
  • you want built-in cache behavior

Choose OpenFeature when:

  • your team already uses OpenFeature
  • you want a flag-oriented, vendor-neutral interface
  • you want to keep application code less product-specific

If you are still setting up the instance, validate the API key with HTTP first.

Once that works, move to JavaScript or .NET for application code.

HTTP is usually the best first validation path because it proves the instance, key, environment, and API key all work before client code gets involved.

When should I use JavaScript or .NET instead of HTTP?

Section titled “When should I use JavaScript or .NET instead of HTTP?”

Use the language client when you want a more convenient integration surface, caching behavior, or typed helpers instead of manual request handling.

Use OpenFeature when your team wants a vendor-neutral feature-flag interface or already uses OpenFeature across multiple applications.

Do all integration paths still use the same Nona model?

Section titled “Do all integration paths still use the same Nona model?”

Yes.

All of them still rely on the same underlying Nona project, environment, scope, and API key model.