Enforce API Standards at Scale - Custom Governance Rulesets with the Anypoint CLI

We design APIs. We review them. We approve them. And then, somewhere in the process, a team deploys an API with an HTTP base URL instead of HTTPS. It happens. The review was manual. The checklist was skipped. The standard was not enforced — it was just expected.

That is the problem API Governance solves. Instead of relying on people to remember the rules, we codify the rules into a governance ruleset and let the platform enforce them automatically.

In this post, we'll build a custom ruleset that enforces HTTPS on all API specs. We'll validate it, generate its documentation, and publish it to Anypoint Exchange — all from the command line on an Ubuntu server, using the Anypoint CLI.

Prerequisites

We'll need the following before we start:

An Ubuntu server with the Anypoint CLI 4.x installed and configured. Follow Part 2 of this series if the server is not yet set up.
Anypoint Platform credentials with the following permissions in your organization:
- Exchange Contributor (to publish the ruleset to Exchange)
- API Governance permissions (to work with governance rulesets)
Environment variables set and exported:

export ANYPOINT_CLIENT_ID=myClientID
export ANYPOINT_CLIENT_SECRET=myClientSecret
export ANYPOINT_ORG=myOrgId

We'll verify the CLI is active and authenticated before we proceed:

anypoint-cli-v4 account:environment:list

If this returns our environments, we're ready to continue.

Step 1 — Create the Project Folder

We'll keep all ruleset files in one directory. This makes it easy to pass the correct paths to each CLI command.

We'll create the folder and move into it:

mkdir -p ~/governance/gon-https-ruleset
cd ~/governance/gon-https-ruleset

Step 2 — Write the Ruleset File

We'll create the ruleset YAML file:

nano ruleset.yaml

We'll paste the following content:

#%Validation Profile 1.0
profile: GON HTTPS enforcement
description: |
  This ruleset helps ensure the use of HTTPS in GON APIs

tags:
  - security

violation:
  - use-https-for-urls

validations:

  use-https-for-urls:
    message: Always use https for URLs
    targetClass: apiContract.Server
    propertyConstraints:
      core.urlTemplate:
        pattern: "^https://"

We'll save and close the file with Ctrl+X, then Y, then Enter.

Understanding the Ruleset Structure

Before we move on, let's walk through what this file actually does.

#%Validation Profile 1.0 is the AMF dialect declaration. It tells the CLI and Anypoint Platform which format this file uses.

profile is the ruleset's display name. This name appears in Anypoint Exchange and the API Governance UI.

description is the human-readable explanation of what this ruleset does. It appears in the generated documentation we'll publish to Exchange.

tags categorize the ruleset. We use security here. Tags help teams discover rulesets in Exchange.

violation lists which validations trigger a violation-level result. A violation is the most critical severity level in API Governance. An API spec that breaks a violation rule fails its governance evaluation. We could also use warning or info for less critical rules — but HTTPS enforcement is a hard requirement, so violation is correct here.

validations defines the actual rules. Our rule is use-https-for-urls:

Field	Value	What It Does
`message`	`Always use https for URLs`	The message displayed to the API designer when the rule fails
`targetClass`	`apiContract.Server`	Targets the Server object in the API spec (the base URL definition)
`propertyConstraints`	`core.urlTemplate`	Targets the URL template property of that server object
`pattern`	`^https://`	Requires the URL to start with `https://` — if it starts with `http://` or anything else, the validation fails

This single rule catches every API spec that defines a base URL without HTTPS. It works on both RAML and OAS (OpenAPI) specs because AMF parses both formats into the same model.

Step 3 — Validate the Ruleset

Before we publish anything, we'll validate the ruleset file locally. Validation checks that our YAML conforms to the AMF Validation Profile dialect. It catches syntax errors and missing required fields before they become a problem in Exchange.

We'll run:

anypoint-cli-v4 governance:ruleset:validate ~/governance/gon-https-ruleset/ruleset.yaml

Expected output for a valid ruleset:

Ruleset /home/ubuntu/governance/gon-https-ruleset/ruleset.yaml
Ruleset conforms with Dialect

That response tells us two things: the CLI found the file, and the file passes the AMF dialect schema.

If the validation fails, the output tells us exactly what is wrong:

Ruleset does not conform with Dialect
ModelId: file:///home/ubuntu/governance/gon-https-ruleset/ruleset.yaml
Profile: Validation Profile 1.0
Conforms: false
Number of results: 1

Level: Violation

- Constraint: ...
  Message: Property 'profile' is mandatory
  Severity: Violation
  ...

The error message names the missing or invalid field and the line range. We fix the YAML and re-run the validation until it passes. Do not proceed to the next step until we see Ruleset conforms with Dialect.

Step 4 — Generate the Ruleset Documentation

Anypoint Exchange requires documentation alongside the ruleset file. The documentation is a ZIP file that Exchange uses to render a human-readable page for our ruleset asset — listing its rules, descriptions, and messages.

We'll generate it with:

anypoint-cli-v4 governance:document \
  ~/governance/gon-https-ruleset/ruleset.yaml \
  ~/governance/gon-https-ruleset/ruleset.doc.zip

The first argument is our ruleset YAML file. The second argument is the output path for the documentation ZIP. The CLI creates that file for us.

Expected output:

validation name [ 'use-https-for-urls' ]
Saving to /home/ubuntu/governance/gon-https-ruleset/ruleset.doc.zip

The CLI lists each validation name it found in the ruleset and confirms where it saved the ZIP file.

We'll verify both files are present:

ls -lh ~/governance/gon-https-ruleset/

Expected output:

-rw-rw-r-- 1 ubuntu ubuntu  412 Apr  8 10:00 ruleset.yaml
-rw-rw-r-- 1 ubuntu ubuntu  2.1K Apr  8 10:01 ruleset.doc.zip

Both files are ready. We'll move to publishing.

Step 5 — Publish the Ruleset to Exchange

We'll publish both the ruleset YAML and its documentation ZIP to Anypoint Exchange in a single command using exchange:asset:upload.

The asset identifier follows this format: <asset_id>/<version>. If we don't supply a group_id, the CLI uses our organization ID automatically.

We'll run:

anypoint-cli-v4 exchange:asset:upload gon-https-only-enforcement/1.0.0 \
  --name "GON ONLY HTTPS Enforcement" \
  --description "Enforces ONLY HTTPS on all base URLs in GON API specifications." \
  --keywords security,https,governance \
  --tags security \
  --type ruleset \
  --properties='{"mainFile":"ruleset.yaml"}' \
  --files='{"ruleset.yaml":"'$HOME'/governance/gon-https-ruleset/ruleset.yaml","docs.zip":"'$HOME'/governance/gon-https-ruleset/ruleset.doc.zip"}'

Let's break down the key flags:

Flag	Value	Purpose
`gon-https-only-enforcement/1.0.0`	Asset identifier	Sets the asset ID and version in Exchange
`--name`	`GON HTTPS Enforcement`	The display name in Exchange
`--description`	Ruleset purpose	Shown on the Exchange asset page
`--keywords`	`security,https,governance`	Makes the ruleset discoverable in Exchange search
`--tags`	`security`	Categorizes the asset in Exchange
`--type`	`ruleset`	Tells Exchange this is a governance ruleset, not an API or connector
`--files`	Both YAML and docs ZIP	Uploads the ruleset and documentation together in one operation

Important: The --files flag must include both the ruleset YAML and the documentation ZIP in the same flag call. They use two specific keys: ruleset.yaml for the ruleset file and docs.zip for the documentation file. These keys are not arbitrary — Exchange uses them to identify each file's role.

Expected output:

Asset gon-https-enforcement/1.0.0 uploaded successfully

Step 6 — Verify the Publication in Exchange

We'll confirm the ruleset is live in Exchange by querying it through the CLI:

anypoint-cli-v4 exchange:asset:list gon-https-enforcement

Expected output:

Name                   AssetId                  Version  Type
─────────────────────  ───────────────────────  ───────  ───────
GON HTTPS Enforcement  gon-https-enforcement    1.0.0    ruleset

The ruleset is published. Any API Governance administrator in the organization can now add it to a governance profile and apply it to API specs in Anypoint Exchange or Design Center.

The Complete Command Sequence

Here is the full three-command workflow from validation to publication:

# 1. Validate the ruleset locally
anypoint-cli-v4 governance:ruleset:validate \
  ~/governance/gon-https-ruleset/ruleset.yaml

# 2. Generate the documentation ZIP
anypoint-cli-v4 governance:document \
  ~/governance/gon-https-ruleset/ruleset.yaml \
  ~/governance/gon-https-ruleset/ruleset.doc.zip

# 3. Publish ruleset and documentation to Exchange
anypoint-cli-v4 exchange:asset:upload gon-https-enforcement/1.0.0 \
  --name "GON HTTPS Enforcement" \
  --description "Enforces HTTPS on all base URLs in GON API specifications." \
  --keywords security,https,governance \
  --tags security \
  --type ruleset \
  --properties='{"mainFile":"ruleset.yaml"}' \
  --files='{"ruleset.yaml":"'$HOME'/governance/gon-https-ruleset/ruleset.yaml","docs.zip":"'$HOME'/governance/gon-https-ruleset/ruleset.doc.zip"}'

These three commands are the repeatable unit of work for any ruleset release. We validate before we document. We document before we publish. We never skip validation.

Publishing a New Version

When we update the ruleset — adding new rules or tightening existing ones — we'll publish a new version to Exchange. We'll increment the version in the asset identifier and re-run the same three commands:

anypoint-cli-v4 governance:ruleset:validate ~/governance/gon-https-ruleset/ruleset.yaml

anypoint-cli-v4 governance:document \
  ~/governance/gon-https-ruleset/ruleset.yaml \
  ~/governance/gon-https-ruleset/ruleset.doc.zip

anypoint-cli-v4 exchange:asset:upload gon-https-enforcement/1.0.1 \
  --name "GON HTTPS Enforcement" \
  --description "Enforces HTTPS on all base URLs in GON API specifications." \
  --keywords security,https,governance \
  --tags security \
  --type ruleset \
  --properties='{"mainFile":"ruleset.yaml"}' \
  --files='{"ruleset.yaml":"'$HOME'/governance/gon-https-ruleset/ruleset.yaml","docs.zip":"'$HOME'/governance/gon-https-ruleset/ruleset.doc.zip"}'

Exchange keeps all versions. Governance profiles that point to 1.0.0 stay on that version until an administrator explicitly upgrades them.

Summary

We've built and published a custom API Governance ruleset from scratch on Ubuntu using the Anypoint CLI:

We wrote a ruleset YAML using the AMF Validation Profile format. Our single rule targets apiContract.Server and uses a regex pattern to enforce HTTPS on every base URL.
We validated the ruleset locally with governance:ruleset:validate. We do not skip this step.
We generated the Exchange documentation ZIP with governance:document.
We published both files to Exchange in one operation with exchange:asset:upload, using the required ruleset.yaml and docs.zip keys in the --files flag.

The ruleset is now available in Anypoint Exchange for any governance administrator to assign to a profile. Any API spec that defines an HTTP base URL will fail the governance evaluation with the message: Always use https for URLs.

In the next post, we'll go further. We'll build a governance profile that applies this ruleset across all APIs in our organization, and we'll use the CLI to query which APIs are passing and which are failing — all without opening the Anypoint Platform UI.