Query free UK government APIs with Postman

Free UK government APIs are useful for validation, enrichment and discovery work. This guide shows how to use Postman to query Companies House and Bank of England endpoints, then add tests that catch rate limits, missing records and response shape changes before they damage a workflow.

Set up Postman

Create a clean environment and keep API keys out of request URLs and shared notes.

Send test requests

Use real public endpoints to inspect response shapes and confirm useful fields.

Add checks

Use Postman tests to validate status codes, required keys, XML shape and safe fallbacks.

What you are building

The aim is not to create a production integration inside Postman. The aim is to build a safe test suite that proves whether a free endpoint is useful, what data it returns, how it fails and where it should sit in an operational process.

In this example, Companies House is used for company profile checks and the Bank of England RSS feed is used as a second public data source with a different response format.

1. Create a Postman environment

Start by keeping credentials in a Postman environment rather than hardcoding them into requests.

Create a new environment called UK Gov Staging.
Add a variable named ch_api_key.
Paste your Companies House API key into the current value field.

For Companies House, create an API key through the Companies House Developer Hub. Keep it in the environment variable and avoid placing it directly in the request URL.

2. Create the collection and authentication

Create a Postman collection called UK Gov Validation Suite. On the collection's Authorization tab, set the type to Basic Auth.

Set Username to {{ch_api_key}}.
Leave Password blank.
Save the request inside the collection so it inherits the authentication settings.

3. Query a Companies House profile

Add a new request inside the collection. Set the method to GET and use a known company number as a sample call.

Companies House request

GET https://api.company-information.service.gov.uk/company/02431878

Click Send. The response should help you inspect the payload schema, including fields such as company_name, company_status and registered_office_address.

4. Add defensive Postman tests

Do not rely on one successful sample response. Open the request's Tests tab and add checks that confirm expected status codes, log known exception paths and verify required properties when the request succeeds.

Postman tests

// 1. Status code validation
pm.test("Verify HTTP success response", function () {
    pm.expect(pm.response.code).to.be.oneOf([200, 404, 429]);
});

// 2. Exception and telemetry logging
let responseCode = pm.response.code;

if (responseCode === 429) {
    console.warn("WARNING [Rate Restriction Hit]: Rate limits enforced by Companies House endpoint.");
} else if (responseCode === 404) {
    console.log("INFO [Data Validation]: Request succeeded but the company number does not exist.");
} else if (responseCode === 200) {
    // 3. Strict semantic payload validation
    pm.test("Verify expected structural properties exist", function () {
        let jsonData = pm.response.json();
        pm.expect(jsonData).to.have.property("company_name");
        pm.expect(jsonData).to.have.property("company_status");

        console.log("SUCCESS [Profile Verified]: Name: " + jsonData.company_name + " | Status: " + jsonData.company_status);
    });
}

This gives the request a basic operating frame. A 200 response is checked for expected data, a 404 is treated as a valid data outcome, and a 429 is logged as a rate restriction rather than ignored.

5. Add a second endpoint with a different response format

Real workflows often need more than one source. Add a second request to test a Bank of England public feed, which returns XML rather than JSON.

Bank of England request

GET https://www.bankofengland.co.uk/rss/publications

Because the response shape is different, the test should validate XML structure rather than JSON keys.

XML response check

// XML schema pattern auditing
pm.test("Verify valid XML response shape", function () {
    pm.response.to.have.header("Content-Type");
    let responseBinds = xml2Json(pm.response.text());
    pm.expect(responseBinds).to.have.property("rss");
    console.log("INFO [Fallback Checks Complete]: Bank of England feed structural check passed.");
});

6. Decide where the API belongs

Once the Postman suite runs, decide whether the endpoint is suitable for the job. Free public APIs can support useful work, but they should not become silent blockers in critical customer journeys.

Operational domain	Deployment strategy
Live production workflow	Unsuitable for real-time customer checkouts or blocker scripts. Use only in asynchronous background queues where a multi-hour endpoint failure cannot stall core operations.
Manual verification tool	Useful as an on-demand support tool. A user can run the check, inspect the result and approve the data before anything is committed downstream.
Lightweight administrative task	Effective for monthly clean-up, ad-hoc entity validation and batch list checks. Use slow call cadences to respect rate limits and reduce automated blocks.

Minimum checks before using a free API

Store keys and variables in an environment, not in pasted URLs.
Test expected success, missing-record and rate-limit responses.
Validate required response fields before using returned data.
Log enough detail to diagnose changes in status code, headers or payload shape.
Decide whether the endpoint belongs in a live workflow, a manual check or an internal tool.