The Next-generation API Observability Platform

How do you know if a small code change can take down your site? What's really going on with your APIs? At Akita, we're building tools to help you answer that question.

Akita watches calls to web APIs in order to help you visualize your service graph, monitor your APIs, make sense of your request/response logs, and 💥 catch breaking changes 💥.

Akita is 1) blackbox, 2) runs in CI/CD, staging, or production, and 3) uses API modeling technology to automatically catch regressions.

Get Started    FAQs

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 3 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.