Data and API

Endpoints

All of them are GET. Anything else answers 405: corrections go through the form so a human reads them. Access-Control-Allow-Origin: * is set, so you can call them from a browser.

Fields every response carries

The three states, and the fourth thing that is not a state

A quoted detail carries a fourth thing, and it is not a state but a subject: whose sentence it is. anbieter (the vendor itself), infrastruktur (their data centres or infrastructure), dienstleister (a named provider of theirs), erwaehnt (named without a certification claim), unklar (unclear from the sentence). Only anbieter is aggregated into a value page – a sentence about a vendor's data centre does not belong in a list called “vendors that name ISO 27001 for themselves”.

The score

The score is Transparency Score v1: the share of the summed weights of 12 criteria that we found. It is frozen. Adding a criterion would change every figure ever published, including the one in a procurement file from last week, without the vendor doing anything; new criteria are therefore measured and returned as facts and do not enter the figure. Below 9 measured criteria there is no score at all – score is null, never 0.

The 12 criteria

The 10 detail types

The machine-readable description

/openapi.json is an OpenAPI 3.1 document for this interface. It is generated from the same catalogues as the answers, not written alongside them: the endpoints, the shared fields, the twelve criteria, the detail types, the subjects and the three states all come from the code that produces the responses. A description written by hand goes stale exactly when someone adds a field, and a description that says something other than the interface is worse than none.

Responses carry an ETag, so a conditional request with If-None-Match gets a 304 and no body. There is no key and no quota beyond ordinary fair use; if you plan a large run, read how our own crawler behaves and do the same.

A response, in full

{
  "snapshot": "r178.108284",
  "snapshot_run": 178,
  "score_version": "v1",
  "license": "CC BY 4.0",
  "domain": "example.com",
  "score": 68,
  "measured": 12,
  "of": 12,
  "criteria": {
    "dpa": {
      "result": "found",
      "source": "https://example.com/legal/dpa",
      "checked": [
        {
          "url": "https://example.com/dpa",
          "outcome": "404"
        },
        {
          "url": "https://example.com/legal/dpa",
          "outcome": "200"
        }
      ],
      "note": null,
      "measured_on": "2026-09-04T02:41:18.000Z"
    },
    "security_txt": {
      "result": "not_found",
      "source": null,
      "checked": [
        {
          "url": "https://example.com/.well-known/security.txt",
          "outcome": "404"
        }
      ],
      "note": null,
      "measured_on": "2026-09-04T02:41:24.000Z"
    }
  },
  "details": [
    {
      "key": "zertifikat",
      "name": "Certification named",
      "value": "iso-27001",
      "subject": "anbieter",
      "quote": "We are ISO/IEC 27001 certified, audited annually.",
      "source": "https://example.com/trust",
      "measured_on": "2026-09-04T02:41:20.000Z",
      "path": "/data/certifications/iso-27001"
    }
  ]
}

Bulk: the whole dataset as one file

Every result we hold, gzipped, at /data/dump/. It is written once per measurement run and handed out by the web server, so it costs you one request and us nothing. manifest.json names the snapshot, the row count and a SHA-256 per file: two downloads with the same snapshot identifier are the same data.

• results.ndjson.gz and results.csv.gz – one row per vendor and criterion: domain, criterion, one of the three states above, the address we read it at, the date.
• vendors.ndjson.gz – one row per vendor: domain, name, categories, score, and how many criteria that score rests on.

Generating this per request would serialise around 90 MB on a two-core machine that also serves everything else here, which is why it is a file and not an endpoint.

Bulk: the evidence pack for one vendor

Every vendor profile carries a downloadable pack for a procurement file, in two formats:

• /<category>/<vendor>/evidence.csv – two tables in one file: 13 columns per criterion (vendor, domain, category, criterion, criterion_key, weight, result, source_url, addresses_checked, note, measured_on, snapshot, score_version), then the quoted details (vendor, domain, detail, detail_key, value, subject, quote, source_url, measured_on).
• /<category>/<vendor>/evidence.json – the same, nested, with the full list of addresses we checked.

Both carry the snapshot id and the disclaimer. There is no PDF: the container that serves this page has no browser to render one, and the page itself prints.

For an agent: MCP

The same data over Model Context Protocol at https://saas-ranking.com/mcp, so a model can ask instead of fetching. Stateless: one JSON-RPC request per POST, no session, no key, no account. 6 tools, all read-only:

Every tool runs the same function as the REST endpoint beside it, and test/mcp.test.js compares both answers field by field – two paths would be two truths. Every answer carries the snapshot id and one sentence: a result describes our measurement, never a property of the vendor.

Rate limits, and what we ask instead

There is no key and no counted quota. What we ask is the thing a rate limit would enforce badly: take the snapshot once and work from it, rather than fetching ten thousand vendor documents one at a time. That is exactly what the bulk download is for.

If your use needs something we do not offer – a webhook, an older snapshot – tell us. We would rather build it than watch someone scrape the pages.

Versioning

The path carries the version: /api/v1/. Inside a version we add fields and never repurpose one. A field that would have to mean something else gets a new name, and the old one keeps its meaning until the next version. The score has its own version, printed in every response, for the same reason.

• How we measure and weight
• What a snapshot is
• How our crawler behaves
• llms.txt