A publishing platform becomes much more interesting when the article, the enquiry, the product, the customer account and the website can work together. That is the integration problem Antsand has grown around.

A note can become a blog post. A form can collect a subscriber and start an email delivery workflow. A catalog can supply a generated store. A purchase can grant access to an ebook. The same factory can produce another brand with different content, design and local accounts. People can configure those connections through the interface; authorized agents can work through the API.

The useful question is: which connection should we make, where should it run, and who should own the result? This guide works through those choices, from publishing a single article to operating several brands. The examples follow Antsand’s modules, group context, Databoard mappings and generated websites, with a distinction between supported workflows and proposed integrations.

The six patterns at a glance

Explore the patterns: Publish a selected projection · Use a scoped API for an authoritative change · Compose the experience through Databoard · Call a shared service at runtime · Process a confirmed event or queued action · Put an adapter between independent business systems

Choose the boundary before the endpoint

Enterprise integration discussions often start with APIs, connectors and middleware. Those matter. In Antsand, there is another important choice before them: whether a change belongs in an authored record, a website definition, a generated runtime or a shared service.

Consider a membership publication. The article belongs in Notes. Its presentation belongs in a mapped page section. A member’s identity and purchase records belong to the site’s runtime. Email may be delivered by a central service. One customer journey crosses all four boundaries. Putting the entire journey in a page script would hide those responsibilities.

A quick selection guide

1. Understand the factory: records, scope, composition and runtime

Antsand has several kinds of reusable material. Modules own structured records: Notes owns authored articles; Forms owns form definitions and workflow settings; ecommerce owns catalog concepts; Docs owns collections and pages. Databoard describes how selected data becomes an application experience.

A page is composed from sections, with header, body and footer structure. Mappings connect module data to those sections. Shared Sass v2 components and site-specific design settings supply presentation. HMVC configuration supplies routes, controllers, views and access rules. The factory generates the website from these definitions.

This is useful because content and application structure can evolve at different speeds. An editor can revise a post without redesigning its template. A designer can improve a shared section without copying its markup into every article. A runtime fix can be tested in the shared implementation and carried into subsequent generations.

Groups connect the context; they do not erase ownership

Groups are a central organizing mechanism for connecting content and websites. A group can define the relevant context for Notes, Forms and other linked resources. But a group is not a combined database, and membership in a group is not a substitute for authorization.

The module still owns the record. The caller still needs the appropriate access. The destination still needs a mapping. Some modules use an additional explicit binding: Docs publication, for example, selects collection IDs and checks ownership and public-page status. “It is in the group” does not mean “publish every field everywhere.”

Generated sites have their own operating responsibilities

A generated site can serve its published experience and keep local runtime state, including the SQLite records used by configured membership and commerce features. That gives the site a useful degree of independence from the authoring application.

Independence is specific to each flow. A locally served article does not require a central authoring request on every view. A centrally submitted form still requires Antsand to receive it. A local password-reset handler can own the token while depending on central email delivery. Document those dependencies individually rather than calling the entire site either dependent or independent.

2. Look across the modules, not just the website

The integration surface is broader than publishing. It includes the records people create, the experiences customers use and the processes operators maintain. The table below is a map of useful combinations, not a promise that every module has the same external API coverage.

Calendar, recruitment and other modules broaden that internal workspace further. Their existence is useful architectural context; a proposed integration must still inspect its specific interface. A Sales UI workflow, for example, does not by itself establish a complete public sales API. Likewise, a curriculum schema does not establish protected course delivery.

3. Separate five integration decisions

A single project can need several approaches. Keeping the decisions separate makes it easier to choose a small, understandable implementation.

• Data: which system creates the authoritative record, and which systems receive a copy?
• Process: what happens after a change, and how are failure and repetition handled?
• Experience: which page, section or customer journey presents the result?
• Agency: what may a person or software agent inspect and change?
• Delivery: how does a saved definition become a verified running website?

A common mistake is answering only the data question. A successful API response proves that a request was accepted or a record changed. It does not prove that the generated page contains the change, that an email was delivered, or that a buyer received access.

4. Choose an integration pattern

Pattern A — Publish a selected projection

Use a projection when the destination needs a published representation of centrally authored data. Articles, documentation and catalog presentation are natural examples. The source remains editable in its module; the generated site receives what it needs to serve its experience.

This makes ordinary reading less dependent on the authoring system and makes a published version inspectable. The trade-off is freshness: the destination changes after the appropriate sync or generation operation. Make that step visible in the workflow. An editor should be able to distinguish saved, published and verified.

For a blog revision, update Notes and run the blog-specific sync. For a route or template change, use the relevant generation and deployment path. Regenerating everything for every paragraph edit creates unnecessary work; syncing only article data cannot install a new runtime handler.

Pattern B — Use a scoped API for an authoritative change

Use the API when another tool needs to read or change module-owned records. Examples include drafting a note, preparing a product draft, updating form settings or inspecting a board's context.

The contract should identify allowed fields, required scope, ownership checks and revision requirements. Some current endpoints have explicit concurrency controls: form settings use an expected settings hash; Resume updates use revision information; revisions to published Masterclass chapters have their own confirmation and hash requirements. Do not assume every endpoint uses the same protection.

For imports, start with a representative sample and a durable mapping from external IDs to Antsand IDs. Check attachment handling, group selection, duplicate detection and resumability before expanding the batch. A loop over create endpoints is not automatically a safe migration tool.

Pattern C — Compose the experience through Databoard

Use composition when the requirement is about what the customer sees or how pages connect. Choose the module data, map it into the section, use shared presentation components, and define the route and access behaviour.

For example, a homepage can combine an article list, an ebook promotion and a newsletter form without turning the page into the owner of those three datasets. The page supplies context and presentation. Notes, the product catalog and Forms remain editable in their respective modules.

SVG illustrations are useful authored assets here. A custom HTML blob containing layout, business rules and embedded data is harder to validate and reuse. Extend a shared renderer when a repeated structured pattern is missing, then expose the structure through the mapping.

Pattern D — Call a shared service at runtime

Use a live call when a decision or service must be current at the moment of use. Payment providers and transactional email are clear examples. The caller should have a defined timeout, an understandable failure state and a way to retry safely where repetition is permitted.

Keep the authority clear. Asking a mail service to send a reset link does not make that service the owner of the password-reset token. Asking a payment provider to collect money does not make the browser redirect proof that an entitlement should be granted.

Pattern E — Process a confirmed event or queued action

Some operations benefit from leaving the immediate request path. Form workflow actions and analytics processing have queue/worker concerns. Payment callbacks have confirmation and duplicate-delivery concerns. These are specific implemented processes, with different contracts.

A configured workflow still needs an execution path and an operating worker. Current Forms workflow actions are independent actions, not a general-purpose dependency graph. A local form submission requires an explicit bridge if a central workflow is expected to run. General event subscriptions, arbitrary cross-module orchestration and a universal event bus would require additional implementation; they should not be inferred from the presence of queues.

Pattern F — Put an adapter between independent business systems

An external CRM, finance system or email provider may use different identifiers and lifecycle rules. An adapter is the place to translate fields, map identities, handle rate limits and record synchronization state.

For an external CRM connection, decide which platform owns the contact, which owns the customer-facing website and which owns a sale. An Antsand form might originate an enquiry, while the CRM owns qualification and the commercial pipeline. This is a proposed integration: confirm the available APIs, identity mapping and delivery mechanism before treating it as a working connector.

Start with one-way synchronization if it meets the requirement. Two-way synchronization needs conflict resolution, deletion semantics and a rule for preventing changes from bouncing indefinitely between systems.

5. Compare approaches by their operating behaviour

These differences affect cost as well as correctness. A live read on every page view creates a different load from publishing a local representation. A worker reduces request latency but adds something to operate. An adapter can reduce manual work while introducing reconciliation work. Count those responsibilities before choosing the apparently shortest implementation.

6. Worked journey: a guide, a subscriber and an email

Suppose a reader requests an ebook from a landing page. First choose where the submission belongs. If Antsand should own the subscriber record, the form can submit centrally and trigger the configured delivery workflow. The generated page supplies the presentation and form binding.

If a generated site should own the submission, its local handler writes the local record. A central workflow does not automatically discover that write. Add an explicit supported bridge, or use an appropriate transactional delivery integration. Otherwise the form can appear successful while the expected email never starts.

The success criteria span the journey: correct destination, validated recipient, appropriate delivery configuration, delivery attempts visible to an operator and predictable handling of repeat submissions. Subscribing to updates and receiving one requested guide can have different consent requirements; represent the user's actual choice in the stored data and subsequent audience selection.

Do not use this marketing workflow as a substitute for authentication. Login and password-reset flows need the generated site's identity handler, token lifecycle and verification. Shared email delivery can support both without merging their authority.

7. Worked journey: content becomes a paid product

A publication can begin with free articles, add an authored ebook and then offer membership. The integration is the connection between editorial content, catalog information, payment state and access.

Masterclass provides ebook authoring concepts. Ecommerce supplies store and product configuration. The generated runtime handles the configured customer journey. The entitlement decision determines whether a specific member may read the protected material.

There are distinct access policies to consider: an outright purchase, membership inclusion, or both. A policy that supports both should preserve a valid outright purchase when subscription-derived access ends. A refund, account deactivation or explicit revocation can affect access through different rules. Those decisions belong in a shared authorization boundary that protects direct content requests as well as visible buttons.

The expected sequence is checkout, confirmed payment processing, recorded purchase or subscription state, and an entitlement decision. The return page improves the experience; it cannot replace confirmation. Duplicate callbacks must not create duplicate benefits.

Before enabling a particular paid offer, demonstrate its full lifecycle. A one-time purchase test does not certify renewal, failed-payment recovery or period-end expiry. Likewise, configuring a curriculum does not certify a protected course player. The architecture supports extending the product; each offer still needs its own delivery evidence.

8. Worked journey: several brands, one authoring system

Imagine three publications: engineering articles, software-factory field notes and a product website. They can share authoring infrastructure and design components while presenting different material, navigation and customer experiences.

Use group context and explicit mappings to select the intended content. Keep brand-specific design and destinations in each board. Where accounts and transactions are local, keep them local: identical numeric member IDs on two sites do not identify the same person or confer shared access.

A shared article can be revised centrally and published to its selected destinations. That is different from automatically sharing every reader or purchase between those destinations. Cross-brand identity and entitlement portability would need an explicit contract.

This is where a factory earns its keep. A reusable section improvement or a corrected runtime implementation can be carried through multiple sites without rebuilding their architecture from scratch. The corresponding responsibility is regression testing: a fresh site, a populated regenerated site and a second site with overlapping IDs should all behave correctly.

9. Worked journey: an enquiry becomes business work

Forms can capture the initial enquiry. Sales provides client, product, invoice and payment-record workflows. A business may want an approved enquiry to create a client and eventually an invoice.

Describe that as a proposed cross-module automation until its exact interface and execution path are implemented. The presence of both modules is a strong starting point, but it does not prove that submitting a form creates a Sales client today.

A useful first implementation would retain the original submission reference, require an intentional qualification step, record the resulting client ID and prevent repeated processing from creating duplicates. It should also distinguish an invoice record from a confirmed payment. That small, explicit contract is easier to operate than a vague instruction to “sync leads into sales.”

10. Give agents a discoverable working contract

Agents can be another interface to the same structured system. They should be able to discover the available operations, inspect the relevant context and submit changes with clear validation feedback. They should not need filesystem access to learn how the application works.

A practical starting sequence uses the current HTTP discovery and context endpoints:

GET /api/v1/help?view=guides
GET /api/v1/me
GET /api/v1/groups
GET /api/v1/databoards
GET /api/v1/databoards/{objectid}/agent-context
GET /api/v1/databoards/{objectid}/page-flow

For a board change, consult the discovered schema, prepare a narrow patch and use the dry-run operation before the write:

POST /api/v1/databoards/{objectid}/patch/dry-run
POST /api/v1/databoards/{objectid}/patch

These paths are a discovery example, not complete request bodies. Obtain the current payload contract and required scopes from the API. A dry run checks a proposed operation without saving it; it does not prove that a generated page will render correctly. After a successful write, use the appropriate sync or deployment operation and inspect the delivered result.

For a Notes edit, use Notes rather than editing a generated article file. For Forms settings, use the form contract and its expected settings hash. For diagnostics, inspect the form's Databoard references and configured action. A read-only diagnosis can show whether the expected wiring is represented; an actual submission test establishes whether it executes.

Smaller models benefit from this structure. Give them bounded tasks, concrete examples, field-level errors and an explicit next operation. A model should not have to infer a publishing sequence from a large repository or guess whether a successful save also deployed the site.

11. Choose the boundary between Antsand and other systems

Start with the work that needs to move between systems: bringing in content, reading owned records, consuming external data, publishing to several destinations or letting an agent make a bounded change. Each needs an owner, an interface and a way to verify the result.

Antsand addresses these questions through its combination of module-owned data, group context, website composition and generated runtimes. Its particular strength is bringing publishing and customer-facing applications into the same repeatable factory workflow. The internal application and the delivered website are connected, while their responsibilities remain identifiable.

Keep an existing CRM where its relationship-management workflows meet the business need. Antsand can own the authored content and generated customer experience, with a small, explicit integration between them. Evaluate the connector coverage, operating requirements and failure handling needed for that particular journey.

Choose the boundary by following a real record through the system. Identify who can change it, when the other side receives the change and how an operator resolves a failed or repeated request. That gives the integration a concrete scope and a testable result.

12. Make the operating contract explicit

Before building a connection, write down the following in a short integration record. This is useful documentation for the next developer, operator or agent.

1. Authority: which module or external system owns each important field?
2. Scope: which group, board, store, collection or local site is involved?
3. Identity: how are source and destination records matched?
4. Freshness: when is a change expected to become visible?
5. Security: which actor and scope may read or change it?
6. Failure: what happens after a timeout, rejection or partial completion?
7. Repetition: how are retries and duplicate events handled?
8. Evidence: where can an operator see the accepted change and its delivered outcome?
9. Recovery: what can be restored, replayed or rolled back?
10. Ownership: who maintains the connection when either side changes?

For generated sites, recovery needs particular care. Restoring an older application release must not silently replace newer customer transactions. Back up configuration, authored data, assets and runtime state according to their different responsibilities. Test the restore path rather than assuming that an archive's existence makes recovery safe.

For queued work, monitor processing as well as acceptance. For external adapters, retain reconciliation information. For protected content, test direct requests and cross-account denial. For agent writes, preserve enough request and revision information to explain what changed without logging credentials or sensitive payloads unnecessarily.

A practical way to begin

Choose one real journey: publish an article, deliver a guide, sell an ebook or publish a documentation collection. Draw its owners and connections. Use the existing module and mapping contracts. Test the whole journey at the generated destination. Then reuse the parts that genuinely repeat.

That is the attraction of Antsand's approach. The same system can support editorial work, structured business records, website design and controlled agent operations. Each addition becomes more useful when its data, interface and delivery path are clear enough to combine with the next one.

Explore the Antsand documentation, the Factory method and the agent workflow. The current API guide remains the reference for supported operations and payloads.

Sources and scope

The Antsand descriptions were checked against the local API catalog and implementations for Notes, Forms flow contracts and diagnostics, Docs publication, Databoard blog synchronization and the Sales controllers on 6 November 2026. Configured workflows, generated-site behaviour and production readiness remain separate forms of evidence. Proposed adapters are identified explicitly above.

Continue exploring the factory

Three field notes that take the architecture into practice.

• See the factory in practiceFrom Antsand to Two Independent Websites

  How shared authoring and implementation produce two websites with distinct runtime responsibilities.

• Why the positioning changedWe Didn't Pivot. We Finally Found the Words for What We Built.

  The progression from publishing tools to a software factory, and the language that now describes it.

• Understand the operating layerAntsand Moving to a Containerized Solution

  Containerization, generated sites and the practical work of keeping deployments repeatable.