Owning your configuration
Your tenant configuration is not a settings panel with a fixed set of options — it is a folder of plain files, and every one of them is yours to edit. The HTML of your documents, the CSS that styles them, the data contracts behind them, the wording of every email and banner: all of it is open, versioned configuration with no locked regions.
This page spells out exactly what you can change, and the two ways teams work with the configuration day to day — including managing it yourselves in your own repository.
What you can edit
| Files | What you control |
|---|---|
templates/<doc_type>/<version>/template.html | The full Handlebars/HTML of every document. There are no locked sections — the only contract is the section id registry the QA harness asserts against. |
assets/css/ | The complete stylesheet: brand tokens, layout, typography, print styles. The two-layer token system makes rebrands a token swap, but nothing stops you restyling beyond it. |
schemas/*.json | The data contract per document type. You can extend schemas with new fields — paired with data-transformation coverage to populate them and QA manifest assertions to protect them. |
data-transformation/*.yaml | The SOQL queries and field mappings that shape your Salesforce data into document data — including custom fields specific to your org. |
blueprint.yaml | Which document actions exist, when they are offered, section visibility, email templates, expiry and lifecycle wording, PDF settings. |
payment.yaml | Every Edge Pay capability: methods, scenarios, eligibility rules, brands, copy. |
sample-data/ and qa-manifest.yaml | The test datasets and the assertions that gate every change — extend them as you extend the configuration. |
What you do not edit:
- Secrets. Gateway credentials and signing keys live in the platform vault; configuration references them as
vault::keys. Raw credentials are never committed, and the validation pipeline rejects them. - The
kaptio_payrouting block inpayment.yaml, which is provisioned and managed by Kaptio. - Platform services. The render engine, viewer, and payment services are multi-tenant platform code — your customization surface is the configuration they consume.
Tenants using Edge Journeys also own JavaScript: the booking experience frontend ships as tenant-editable JSX source. See the Edge Journeys section for the configuration and UI ownership model.
Two ways of working
Kaptio-managed
The default during implementation: you describe the change — new document type, template adjustment, copy update — and Kaptio (or your implementation partner) makes it in the configuration repository, verifies it through the test harness, and ships it. You review rendered output, not YAML.
Self-managed: your own repository
Teams that want direct control can have their own private configuration repository:
- Your tenant configuration lives at the root of a repository your team has direct access to — clone it, branch it, edit it with your own tooling (including AI coding assistants; the repository ships with an agent context file describing the configuration patterns).
- Changes follow a standard branch-and-merge-request workflow. Every merge request runs an automated validation pipeline: file-type checks, secret scanning, and the document test harness against your QA manifest.
- Your team authors and drives the changes; Kaptio reviews the merge. Merges to the production branch require Kaptio approval — a safety net on configuration that renders in front of your guests, not a bottleneck on authoring.
- Merged changes are live within minutes — the platform picks up configuration on merge with no deployment step.
- Your repository contains only your tenant. Secrets stay in the platform vault either way.
Which model fits
Self-management suits teams with web development capacity (or modern AI tooling) who change documents frequently — seasonal template updates, copy iteration, new document types. Kaptio-managed suits teams who prefer to specify outcomes and review results. Many customers start Kaptio-managed during implementation and take over self-management after go-live; switching is an access change, not a migration.
Where to go next
- Fork playbook — how a tenant is created from the reference baseline
- Tailoring documents — the common customization tasks, end to end
- How QA works — the test contract that makes self-service changes safe