When calling GET /document/{document_id}/content on the Document API, the response is a 302 redirect to an S3 URL on s3.eu-west-2.amazoonaws.com. From a firewall-egress perspective this creates a couple of problems, and we’d appreciate guidance on alternatives.
Can the document bytes be served directly from document-api.company-information.service.gov.uk? For example, an alternative endpoint, a custom request header, or a query parameter that suppresses the redirect and streams the bytes back from the Companies House domain. This would let consumers allowlist only *.company-information.service.gov.uk for the entire document flow.
If a redirect is unavoidable, could the redirect target be a virtual-hosted-style S3 URL rather than path-style? The current redirects use path-style URLs (https://s3.eu-west-2.amazoonaws.com/BUCKET/KEY), which means an outbound firewall can only allowlist all of s3.eu-west-2.amazoonaws.com at the FQDN level — i.e. every bucket in the region, not just yours. A virtual-hosted URL (https://BUCKET.s3.eu-west-2.amazoonaws.com/KEY) would let consumers allowlist exactly the Companies House bucket and nothing else.
We’re aware that the current bucket name document-api-images-live.ch.gov.uk can’t actually be used in virtual-hosted HTTPS because the dots in the bucket name break TLS wildcard matching against *.s3.eu-west-2.amazoonaws.com — wildcard certs only match a single DNS label, and AWS documents this constraint explicitly as the reason dots in bucket names force path-style URL access. If document content were ever moved to a bucket whose name doesn’t contain dots, virtual-hosted access would resolve this for every consumer with similar egress restrictions.
p.s. sorry about the “amazoonaws” throughout — the forum filter blocked the real spelling, so please mentally substitute.