Skip to content

Webperf Cloud API

The API lets you pull your results into your own dashboards, your CMS or your CI pipeline. You can also order new tests.

It's included in Standard and Agency. On Agency, each user's key works against every website in the portfolio.

Interactive documentation

The API documents itself. The complete and always-current reference is available as Swagger UI, where you can try the calls straight from your browser:

The specification is also available as OpenAPI 3.0 (YAML) if you want to generate a client.

This page is an overview. Where they differ, the specification wins.

Authentication

Calls are authenticated with an API key in the api-key header. You generate the key yourself on the API page in the dashboard.

curl -H "api-key: $WEBPERF_KEY" https://api.webperf.se/0.1/stats/

There are three key types:

Type Sent as Used by
ApiKeyAuth The api-key header Ordinary subscribers
AdminApiKey The api-key header Agencies with elevated permissions. Apply via support@webperf.se
QueryApiKey The api-key query parameter Backwards compatibility, used by /webanalytics

The key decides which websites you reach. A call to /0.1/stats/ without arguments returns exactly that list, which is the simplest way to check that a key works.

Endpoints

Results

Call Description
GET /0.1/stats/ List the websites the key can access
GET /0.1/stats/{siteId} The latest result for a website
GET /0.1/stats_per_month/{siteId} Historical results, month by month
GET /0.1/private_stats/{siteId} The latest result from private tests
GET /private_stats/{siteId}/{testId} A single private test result
GET /categories/ The categories on Webperf.se
GET /webanalytics Web analytics statistics. The key goes in the query string here

Ordering tests

Call Description
POST /retest/ Re-run the tests for a website
POST /0.1/test_once/ One-off test of individual addresses
POST /tools/lix/ Calculate the readability index (LIX) for a text

Audits

Call Description
POST /audits/ List completed audits
POST /audit/ Order a new audit
GET, POST /audit_file/ Fetch a report file from an audit

Quota

Call Description
GET /quota/ Credits remaining on the account

Check the quota before ordering in an automation. That way you avoid failed jobs when the credits run out. How the quotas work.

Open endpoints

These need no key:

Call Description
GET /public-sector/ Every municipality and region
GET /item/{id} Details for a single website
GET /v1/tests The test types in Webperf Core, with names in sv, en, da, no, fi and is
GET /v1/tests/{test_id} A single test type
GET /info Information about the API
GET /health Health check

/v1/tests is the authority for test names

Are you building something that shows test names to users? A dashboard, a report, an integration? Fetch the names from /v1/tests rather than copying them. The names of active tests there are taken verbatim from Webperf Core's locale files, and they're available in every Nordic language plus English.

One caveat. Descriptions, and the names of retired tests in Danish, Norwegian, Finnish and Icelandic, are machine-translated from the Swedish and English source. Review them before relying on them. The response says so in its meta field.

Examples 

# Which websites does my key reach?
curl -H "api-key: $WEBPERF_KEY" https://api.webperf.se/0.1/stats/

# The latest result for website 3843
curl -H "api-key: $WEBPERF_KEY" https://api.webperf.se/0.1/stats/3843

# History month by month
curl -H "api-key: $WEBPERF_KEY" https://api.webperf.se/0.1/stats_per_month/3843

# How much quota do I have left?
curl -H "api-key: $WEBPERF_KEY" https://api.webperf.se/quota/

Webhooks

If you'd rather react when a test finishes than poll at intervals, use a webhook. You set the address on the website's info page in the dashboard, with a threshold if you only want to hear about drops.

One webhook per website. The receiving address has to be reachable from the public internet.

Worth knowing

The key belongs on the server

Calls are authenticated with the key alone. There's no username and no second factor. Never put it in client-side code. Proxy the calls through your own backend and keep the key there.

The same goes for QueryApiKey: a key in the query string ends up in server logs and browser history. Use it only where it's required.

See also