Skip to content

Domains and URLs

Applies to: All subscriptions

Purpose

Explain the hostname model so that certificates, firewall rules, content-security policies and email links are all configured against the right names — and so a change of environment does not silently produce links pointing at the wrong place.

Audience

Infrastructure engineers, network engineers, security reviewers, and anyone configuring a proxy or content-security policy.

Prerequisites

Reference

Four domains, four jobs

Domain Used for
complifly.in The main application, its API, product documentation and the in-product help centre — all subdomains
complifly.tech The status page, hosted apart from the application so it survives an outage
complifly.info Public marketing content and SEO
complifly.online Generated files: signed invoices, e-Way Bill PDFs, exports

Surfaces

Surface Typical hostname Notes
Application app.complifly.in Where users sign in
API api.complifly.in May be the same origin as the application, or separate
In-product help help.complifly.in Deliberately on the application domain, not the marketing one, so in-product links and public links are the same URLs
Product documentation docs.complifly.in This portal. On the application domain, so a reader trusts one registration rather than two
Status page status.complifly.tech Hosted separately so it survives an application outage
Marketing www.complifly.info Never link a signed-in user here
File downloads files.complifly.online A different origin from the application, by design

Every one of these is overridable per environment. A non-production deployment uses its own hostnames, and the application resolves them from configuration rather than assuming.

Why downloads live on a separate origin

Signed invoices, e-Way Bill PDFs and export files are served from complifly.online, not from the application origin. This is a deliberate decision with two consequences that any integrator or network engineer must respect.

The session cookie is not sent there. An authenticated fetch to the download origin will simply fail. Download URLs are therefore signed and time-limited rather than session-authenticated. That is what makes a link shareable and expiring rather than dependent on who is signed in.

It must be allowed explicitly in your content-security policy. If a page needs to read rather than merely link to a file, the download origin must appear in the policy's connect and frame directives. Omitting it produces downloads that fail with no useful error message.

The benefit bought by this arrangement is that large binaries stay off the application's cookie scope and content delivery path — but it is only safe if the signing and expiry are respected, which is why session-authenticating a download does not and should not work.

The rule: never hardcode a hostname

Every URL the product emits resolves from the domain configuration: signed download links, password-reset emails, notification links, references printed on documents, allowed browser origins, and the content-security policy.

Hardcoding a hostname anywhere produces a defect with a characteristic shape: it works in the environment it was written for and silently points at the wrong environment everywhere else. A password-reset email from a test environment linking to production is the version of this failure that reaches a customer.

Certificates

Requirement Detail
A certificate per published hostname Or a wildcard covering them, per your policy
Complete chain served Browsers repair a missing intermediate; ERP integrations do not. Test with a tool, not a browser
Trusted publicly Any ERP calling in must trust it
Renewal automated and owned A named owner and a mechanism, not a calendar entry
Expiry monitored See Monthly Checks

Content-security policy inputs

Enumerate these before writing the policy:

Directive Must allow
Default and script sources The application origin
Connect sources The API origin, and the download origin if files are fetched rather than linked
Frame sources The download origin, if documents are previewed inline
Image sources The application origin, and any origin serving logos
Style and font sources The application origin, plus any font service in use

A policy written without the download origin is the single most common cause of "downloads do not work" after an otherwise successful deployment.

Validation

Check Method Pass condition
Every hostname resolves Resolve each from a client network Correct address returned
Certificates valid Open each hostname in a browser Valid, trusted, not near expiry
Chain complete Test with an external TLS checker Full chain served
Application reachable Sign in Loads
API reachable Health request through the proxy HTTP 200
Downloads work Generate and download a document File downloads successfully
Download link expires Wait past the expiry and retry the same link Refused. If it still works, the link is not time-limited and that is a security finding
Links point at the right environment Trigger a password reset in each environment Each links to its own environment, never to another
Printed references correct Print a document and inspect any URL on it Correct environment
Content-security policy complete Load every main screen with the browser console open No policy violations reported

The expiry check is worth running deliberately. A download URL that never expires is a shareable, permanent, unauthenticated link to a customer's compliance document.

Troubleshooting

Symptom Cause Action
Downloads fail with no clear error Download origin missing from the content-security policy Add it to the connect and frame directives
Download link returns unauthorised Someone is trying to fetch it with session credentials Downloads are signed and time-limited by design; use the signed URL as issued
Download link has expired Working as designed Re-generate the link
Password-reset email links to the wrong environment The base URL setting is wrong, or a hostname is hardcoded Correct the domain configuration for that environment
ERP integration fails TLS while browsers are fine Incomplete certificate chain Serve the full chain
Help centre unreachable from inside the product Help hostname not configured, or blocked by policy Help is on the application domain; confirm it is reachable and allowed
Site unreachable overnight Certificate expired Automate renewal; monitor expiry
Some assets blocked in the browser console Content-security policy too narrow Enumerate the real origins and widen precisely — never to a wildcard
Moving a surface to a new hostname breaks links Hostnames hardcoded rather than configured Fix the configuration; this is exactly the failure the rule prevents
Strict transport security blocks a hostname change The header is cached in browsers Expected. Plan hostname changes with the header's lifetime in mind