Name-based references
Every entity referenced by name, not internal ID. Diff-friendly, rename-safe, and reusable across environments.
APIops
Treat APIs like the rest
of your code.
A REST controller surface in the Manager, designed to be driven from CI. Name-based manifests, idempotent applies, environment promotion — through the same audit-aware path as the UI.
Idempotent applies
Re-running an apply is safe. The Manager reconciles to the manifest's stated shape — no duplicates, no drift.
Audit on every apply
Same Spring Repository audit aspect as the UI path. Every change has an actor, a timestamp, and a reason.
Environment promotion
One manifest, multiple environments. Internal IDs never leak into your repo — promotion is a metadata change.
Sample manifest
A proxy in YAML.
Manifests reference everything by name — proxy name, project, upstream, policy. Promotion to a new environment doesn’t rewrite IDs.
Diff-friendlyIdempotentAudited
# orders-api.yaml — apply to any environment
apiVersion: apinizer.com/v1
kind: APIProxy
metadata:
name: orders-api
project: commerce
spec:
type: REST
upstream:
name: orders-service
endpoints:
- path: /orders/{id}
method: GET
policies:
- name: rate-limit-default
- name: header-enricher
- name: log-async
client_routes:
- relative_path: /orders
methods: [GET, POST]# .github/workflows/apinizer.yml
name: Apinizer apply
on:
push:
branches: [main]
jobs:
apply:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: |
curl -L apinizer.com/cli/latest -o apinizer
chmod +x apinizer
./apinizer apply -f manifests/Wire it into CI
Drop in next to your build job.
Apply runs from any CI runner. Authenticate with a JWT issued by Identity Manager, scope it to a Project, and let the Manager reconcile.
Stop clicking
Apply your first manifest from CI.
A walkthrough of APIops on your repo and your cluster, with the Apinizer team.