canagentsbuyfromyou

CI integration and badge

Block a pull request below a threshold, and show the score in a README.

GitHub Actions

yaml
- name: cabfy audit
  env:
    CABFY_API_KEY: ${{ secrets.CABFY_API_KEY }}
  run: npx cabfy audit https://my-store.com --fail-under 60

That's all. Commit, branch and run URL are picked up from the environment automatically — no extra flags. The step fails if the score drops below 60, which fails the job.

Choosing the threshold

60 is the boundary between fail and warn: below it, a structural obstacle stops an agent from working. That's the right starting point for a blocking gate, because it only fires on a real problem. Moving to 85 (the pass boundary) means demanding excellence on every commit — workable once the store is already in good shape, brutal before that.

An audit measures the store, not the pull request
An audit measures a store in production, not the code in the pull request. The score therefore doesn't move with every commit: it moves when the store changes. Running the audit on a daily schedule rather than on every push is often more honest — and consumes less quota.

GitLab CI

yaml
audit:
  image: node:22
  script:
    - npx cabfy audit https://my-store.com --fail-under 60
  variables:
    CABFY_API_KEY: $CABFY_API_KEY

GitHub App (native integration)

Install cabfy directly on your repository as a native GitHub App. It runs automatically on every PR, posts results as a Check Run, and optionally blocks the merge if the score falls below your threshold.

No GitHub Actions workflow to maintain
Unlike the Actions examples above, the GitHub App integrates with GitHub's native branch protection rules. One install, one configuration — no pipeline file to maintain.

Step 1: Install cabfy

  • From your dashboard, go to Settings → GitHub.
  • Click "Connect GitHub" and authorize the app.
  • Select the repository where cabfy should run.
  • cabfy now creates a Check Run on every PR to your repository.

Step 2: Enable branch protection (required)

Without this step, the Check displays the result but doesn't block the merge
This is the critical step. The Check shows visually whether it passed or failed, but only branch protection rules can actually prevent the merge button from being clickable.
  • Go to your repository Settings → Branches → Branch protection rules.
  • Create a new rule for your main branch (e.g., main, master).
  • Check "Require status checks to pass before merging".
  • In the list of checks, find and select "cabfy".
  • Save. From now on, any PR with a failed Check cabfy cannot be merged — the Merge button is grayed out.

Step 3 (optional): Set a fail threshold with .cabfy.yml

By default, the Check always passes (green). To make it fail (red) below a certain score, add a .cabfy.yml file to your repository root:

yaml
business: https://my-store.com
fail_under: 70  # optional: check fails if score drops below this
  • fail_under is optional. Without it, the Check is always green (informational).
  • fail_under is a Growth plan feature. On Free plans, this line is ignored and the Check remains green.

The badge

A public SVG badge showing a site's latest Agent Readiness tier, to embed in a README. It updates after a completed Agent Readiness scan.

  • Dashboard, "Badges" section: pick a store you've already audited, or type its URL.
  • The token and badge URL are shown only once — copy the suggested Markdown snippet.
  • The badge updates itself after each new Agent Readiness scan completes: nothing to regenerate.
markdown
[![Agent Readiness badge](https://canagentsbuyfromyou.com/badge/arb_xxxxxxxx.svg)](https://my-store.com)

The badge is cached for five minutes: allow for that delay before a new tier shows up.

What the badge doesn't say

A revoked token, and a project with no completed Agent Readiness scan, both render a gray "no data" badge rather than a broken image or an HTTP error. That's intentional: a public badge should never reveal why it has no data. If you see "no data", check that an Agent Readiness scan has completed for the project.

Regenerating a badge means revoking the old one first
A badge is tied to one account-store pair, one at a time. To regenerate one for the same store, revoke the existing badge first — otherwise creation is refused.