Using Sonta as your site's backend

You already have a website, or you will build one the way you want — in whatever framework, hosted wherever you like. Sonta does not replace that. What it does is stand behind it: your site reads its catalog from Sonta and writes what visitors do — a lead, an order, a booking — straight back into the same records your team works with. There is no separate content system to keep in sync, because the site and the CRM are looking at one set of data from two sides. This guide is about that arrangement: how a site connects, what it reads, what it writes, and where the boundary sits.

What this is, and what it is not

It is worth being clear up front, because the name of this idea gets stretched. Sonta is a backend: the place your data lives and the interface your site talks to. It is not a site builder, and it does not host or theme your site — you bring that. Nor is it a full content management system, though, as you will see, it can hold page content in a pinch. Think of it the way an application thinks of its database: the site is the front, Sonta is what the front reads from and writes to.

Connecting a site

A site connects by being registered in Sonta as a website. Registering it gives the site its own credentials — its own key to the door, separate from any person's login — and, just as important, its own permissions per collection. That part is what keeps this safe: you decide, collection by collection, what the site may do, and nothing is granted until you say so. Let it read your products and your services; let it create leads and bookings; keep everything else out of reach. A public website should be able to touch only what a public website needs, and the permission grid is how you draw that line — it is covered in detail in how collections power a site.

Reading: your catalog on the site

Most of what a site does with Sonta is read. Given permission to a collection, the site pulls its entries and renders them however its design calls for — a product grid, a directory, a list of services. One control matters here more than any other: an entry's status. Only published entries are meant for the public; anything left unpublished stays out of sight. This is what lets you prepare a product in the CRM, complete with images and copy, and have it appear on the site the moment you publish it — and disappear again if you unpublish it. The site needs no separate staging step; publishing the record is the staging step.

Writing: the site feeds the CRM

A site is not only a window onto your data — it can put data back. A contact form creates a lead; a checkout creates an order; a booking widget creates a booking. Each of these is an ordinary entry in the same collection your team already works, arriving the instant a visitor acts. Nothing is exported or reconciled later — the lead a visitor submits at midnight is in your pipeline at midnight. And because it is an ordinary entry, it drops straight into everything else you have built: a new lead can trigger an automation that notifies the right person, routes it, or sends a first reply, with no extra plumbing between the site and the workflow.

One model, two audiences

Step back and the shape is plain: one set of records, serving two audiences. Inside, your team sees the full picture and works it. Outside, your visitors see the published slice and add to it. Both are looking at the same collections — there is no copy of the catalog for the website, no mirror of leads to keep aligned. This is the whole reason to run a site this way rather than bolting a separate database onto a marketing page: the site and the operation are never out of step, because there is only one of them.

Content in records: the CMS grain

One honest aside. Because fields can hold rich text and HTML, a collection can carry page content as well as structured data — a blog post's body, an about page's copy. For a simple site, that is enough to manage some content from the same place as everything else. It is worth knowing this is a side effect of fields being able to hold anything, not a dedicated content system: if you need full editorial workflows, versioned pages, and a page-building experience, that is a content management system's job, not this. Use the grain where it helps; do not expect it to be more than it is.

A worked example

A shop runs its own website. Its Products collection is granted to the site for reading, so the site lists every published product, each with the images and description entered once in the CRM; a product held back as a draft does not appear at all. On each product page a "request a quote" form is wired to create a lead — so a visitor's request lands as an entry in the shop's Leads collection, owned and ready, and an automation immediately emails the sales desk. The shop's team never leaves Sonta; the site never holds a second copy of anything. Swap the shop for a clinic publishing its services and taking bookings, and the arrangement is identical.

Where to go deeper

This all rests on the model you have already built: the data model for how your records are shaped, collections and fields for building them, and agents and automations for acting on what the site writes back. For exactly what a site may see and change, read how collections power a site; if something published is still not appearing, work through my entry does not appear on the site. The developer-level wiring — authenticating your site, fetching in your framework, and routing pages by slug — has its own pages, added as that area of the docs comes online.