Where Observability
meets Structure

The only observability tool to build API behaviour models, Akita enables API-centric system monitoring and allows users to automatically detect breaking changes.

More about how Akita works

AkitaURIs

AkitaURI identify resources in the Akita Cloud. They have the following structure:

akita://serviceName:resourceKind:resourceName

There are two kinds of resources: traces and specifications.

# A trace AkitaURI
akita://myFavoriteService:trace:trace_1

# A specification AkitaURI
akita://myOtherFavoriteServce:spec:SpecPrime

Why AkitaURIs?

The Akita CLI has commands for creating traces from API traffic, transforming traces into an API specification, and diffing API specs.

CLI commands can use AkitaURIs to reference objects in the Akita Cloud. For example, you can create a trace, store it on the local file system, and then create a spec in the cloud.

# Start capturing API traffic to/from port 80, producing one
# trace per interface in the out directory:
akita apidump --filter "port 80" --out path/to/out/dir

# Generate a spec from the traffic trace:
akita apispec --traces path/to/out/dir/akita_eth0.har \
  --out akita://myProject:spec:spec1

In general, CLI commands that create or act on traces or specs can use either a local file or directory or an AkitaURI to reference the object.

Updated 8 months ago


AkitaURIs


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.