By default, every contractor website OAS hosts is served by the same application and the same deployment. One runtime is easier to keep correct than a copy per customer. It also puts one question at the centre of the design: when a request arrives, which business does it belong to, and who gets to decide?
The server matches the requested hostname to a configured website and its business. A business identifier added to a submitted form does not override that match.
From a hostname to a business
When a request reaches OAS, the first step looks only at the shape of the hostname: is this one of OAS's own addresses, or a contractor's domain? Contractor domains are routed to the part of the application that serves websites. No database is touched at this stage.
On the server, that hostname is then matched against the domain OAS connected for each website. A match is served only if the domain, the website and the contractor's business are all active. Anything else, whether a domain OAS never connected, a site that is not live yet or a business that has been suspended, gets a plain "not found" page. It never falls back to another contractor's site.
Different designs, one codebase
Each website's record names which of OAS's registered designs it uses, and it holds the content the business last published. Two contractors can look nothing alike while running the same code in the same deployment. A design name the system does not recognise is refused rather than quietly drawn in a default.
The same split explains how changes travel. A code fix ships once and reaches every hosted site with the next deployment. A content change reaches a site only when it is published for that site.
Who chooses the business behind a lead
When a visitor sends an estimate request, the server resolves the hostname again from current records and files the lead under the business that owns that domain. Nothing in the form chooses the business. If a visitor adds a business or account identifier to the form or the address, it is ignored.
This is a rule across the whole application, not only the contact form: a business, user or role identifier a caller supplies can be used as a selector, never trusted as ownership or authorization. Automated code scans check this for the prohibited patterns they cover: application code reading a business, user or role identifier from a form, a query string, a webhook payload or a request header. Browser and integration tests exercise specific cases of the same rule, listed below.
Your website can have its own identity without your leads being chosen by someone else's URL.
How we test it
Our tests use synthetic businesses on reserved test domains. Among other things, they check that:
- a business or account identifier added to a form or an address changes nothing;
- a domain OAS never connected is "not found", however plausible it looks;
- a site or a business that is not active is refused, and archiving a client stops its site on the next request;
- a lead lands with the business whose website served the form, and only that one.
A browser-level test also runs a production build end to end: it serves a site by its hostname, files an estimate request and confirms that forged identifiers change nothing. The inactive-site cases are covered by the integration tests beneath it.
What this does and does not show
These tests check specific ways one business's data could end up with another. They are not a claim that every possible attack has been tested, and OAS holds no third-party security certification. The boundary is enforced in OAS's server code and checked by those tests. It is not a database-level guarantee.
If you run a contracting business and want your website and your leads kept with your business and no one else's, get in touch.