How an Integrator Delivers on WebinOne: Portal, Roles, Environments and Handover

Most platform evaluations answer the architecture question and stop. An integrator's delivery lead has a different list: who holds the account, where a build lives before it is live, which of the client's people can touch what, what "white label" actually covers, and what happens when twenty sites need attention in the same week. This page answers those from what WebinOne publishes today, and it names the three questions our own pages do not answer rather than guessing at them.

For the platform-level view, the companion pieces are the systems integrator briefing and what runs where on AWS. This one is the operational half.

Who holds the account when an integrator builds on WebinOne?

You do. Sites are created, developed and managed from a single partner portal, which we describe as a "Centralized Agency Portal to help you develop and manage your client websites, including free trial sites, live sites, customer billing, support tickets, branding and more." The client relationship stays yours: the reseller program publishes "direct billing is available" and a "Customizable commission", so you can bill the end client yourself or let us bill and take a margin. Portal users management means your own staff get portal access without sharing one login.

Sites run on our infrastructure on Amazon Web Services. Running the platform inside your own AWS account is not something we ship as a self-serve capability today; it is a commercial conversation, quoted deal by deal, and it is worth raising in the technical assessment if your practice needs it.

How does a site get from empty to live?

Every site starts as a free trial site in the portal, and activation is the step that turns it into a live one. Domains attach at that point: our FAQ states that "you add a primary domain name as part of the site activation process" and that you "can also assign additional domain names to your website after activation is complete." SSL comes with hosting on every plan, one certificate per domain assigned to the site, and we publish that certificates are "renewed every 3 months by WebinOne's administration team" rather than left to you to remember.

The trial site is doing real work in that sequence. It is where a build gets reviewed and accepted before anyone pays for hosting, which is also how migrations land — the rebuilt site appears as a new trial site and you activate it when it passes.

Is there a separate staging environment for a live site?

We do not document one, and that is the honest answer rather than a soft yes. The trial-site model covers the build-then-accept case well; it is not the same thing as a permanent staging copy sitting alongside a production site for ongoing releases. If your delivery process depends on a staging-to-production promotion step per site, treat it as an open item to settle during the technical assessment, and get the answer in writing before it becomes a sprint problem. An evaluation that assumes either answer here will be wrong somewhere.

What is documented is the layer underneath: content templates and snippets are reusable across a site, so the change you are promoting is usually a template edit rather than a deployment artefact. That narrows the problem without solving it.

How do you model a client's data?

Custom Modules are the object model, and our own description is the useful one: "flexible data structures for any content or operational entity. Think of them as custom, interconnected, database-driven web apps." A property register, a course catalogue, an equipment inventory, a dealer network — these are modules with their own fields, layouts and relationships, not plugins.

There are two grades, and the FAQ states the difference plainly. Advanced Custom Modules add parent-child relations to items in other modules, multiple detail layouts for one module, user-submitted items with notifications, advanced module settings, and unlimited custom properties "upon request". Read that last phrase the way an integrator should: some ceilings here are commercial rather than technical, which means they are negotiable, and which also means you should ask what your ceiling is before you design against it.

Rendering happens in our Liquid templating layer. If your team has shipped Shopify themes, the syntax will be familiar; the object model will not be, and that learning curve is real and worth budgeting for on the first project.

Who can touch what, and how is access scoped?

Admin users and admin user roles are documented platform features, so a client's marketing team can be given the admin surface they need without the settings they should not have. Machine access is separated from human access: API applications, external API credentials and frontend API restrictions are each their own documented control, which matters if an integration is going to run against a client site from your own infrastructure.

There is also a path for clients who should never see the admin at all. The On-Site Editor lets an end client change content directly on the page, and TeamOne's setup service for it is described exactly that way — "client edits, no admin". For a portfolio where the client's own staff are the weakest link in the security review, that is often the answer.

What does white-labelling actually cover?

The admin, not just the front end. We publish that you can "present all of your sites under your own domain making it yours with branded website admin - including the login screen and back-of-house", plus branded subdomains and what the reseller page calls "granular white-labeling". Your client logs into your brand, not ours.

What it does not cover is the platform itself. WebinOne is not open source — the FAQ answers "Is WebinOne Open Source?" with "No it is not" — so white-labelling is a presentation and billing arrangement, not a licensing one. Templates and modules your team builds are yours, but they are written against our object model, which means they port to another platform as reference material rather than as runnable code. Say that to a client up front and it is a non-event; discover it during an exit and it is a fight.

Where does WebinOne meet the rest of a client's stack?

Through the Open API for anything custom, and through Zapier for the long tail of SaaS connections that should not need a developer at all. Our FAQ puts the Zapier catalogue at "7,000+ apps" reachable without writing code. Email marketing connects to a provider such as Mailchimp by API, and the published behaviour is specific enough to design against: subscriber data synchronises between the WebinOne CRM and the provider every 24 hours, with manual sync available at any time. Existing email hosted via OpenSRS can be transferred under a WebinOne account at no charge.

The stack answer matters to an architect, so here it is as we publish it: .NET on the latest LTS, ASP.NET Web API, an Angular single-page admin talking to the backend over REST, our own Liquid implementation for templating, a JSON query language for module data, and a "decentralized database for website instances (PostgreSQL)". That last item is the one worth reading twice — website instances do not share one database, which is usually the first thing a security reviewer asks about a platform hosting a portfolio of unrelated clients.

Which AWS region does a client's site run in?

One of six, and unusually for this kind of question we name them: our FAQ lists hosting "with Amazon Web Services on 6 data centers: USA (Oregon), USA (Virginia), UK (London), Australia (Sydney), EU (Germany) and Canada", and the platform overview describes that as "a choice of 6 data centers". So a client with a residency requirement inside those six AWS regions is a normal case rather than a special build, and which one a specific site runs in is confirmed during the technical assessment. An additional AWS region can be stood up on request.

The division of responsibility is published in detail on the security overview, including the sentence a reviewer will want: AWS operates everything from the hypervisor down, and we take the guest operating system, patching, application software and the security group configuration. Your practice's own responsibility starts above that, at the client's content, users and integrations.

Where does delivery capacity come from when the portfolio grows?

TeamOne is our in-house design, development and QA bench, and the reason it belongs in a delivery conversation rather than a sales one is that it is white-labelled: work is "delivered under your brand" with "full visibility in your portal". The published process is four steps — submit the request, agree scope and budget, development and testing against a set delivery date, go live — and we publish a response time of one business day on the first of those. Common work has fixed-price packages; open-ended work runs on prepaid credits.

AgentOne, our AI delivery layer, is in Partner Beta and sits inside that process rather than beside it. The published commitment is the part that matters for accountability: "every line AgentOne drafts, our developers review and own." Use it to compress delivery time, not to remove a reviewer.

What should you settle before you commit?

Three things, and none of them is a reason not to proceed. First, the staging question above — get the environment model in writing if your process needs a promotion step. Second, backup retention: we publish how backups behave for trial sites, and there is no published production retention window, so that belongs in the contract rather than in an assumption. Third, exit. There is no source-code escrow arrangement today, and the counterweight is a commitment we publish in our terms of service: "In case of an unlikely event of the Service being closed or discontinued for any reason, we commit to open-source the WebinOne platform to the level that every Reseller would be able to host their trial and live sites, WebinOne Portal, and SSO service without our support."

Support and status are the easy part. We publish free support for every website built and hosted on the platform, delivered by in-house specialists, and a public system status page you can point a client at during an incident instead of forwarding an email. For dedicated capacity, dedicated servers are scoped per site and specified in cores and RAM, and larger programmes are covered on the enterprise page.

If you are evaluating rather than delivering yet, the evaluation framework is the companion piece, where WebinOne is the wrong choice is the one to read before you build a business case, and inheriting a client's existing site covers what arrives with a handover. For a whole portfolio at once, portfolio migration is scoped there.