Documentation

Understand the boundaries
before you integrate.

These public docs explain Thonem architecture and integration patterns. They intentionally avoid inventing universal endpoint names because concrete APIs can vary by implementation and release.

TH / DOCUMENTATION
architecture/integration-patterns/webhook-safety/deployment/migration/
concepts · contracts · operations
01 / CORE

Commerce core

Keep business rules—catalog eligibility, checkout decisions, order transitions and operational policies—inside an explicit application layer. Web and mobile experiences should consume those rules instead of duplicating them.

Contract firstThe caller depends on a stable contract; the implementation may evolve behind it.
02 / INTEGRATION

Provider adapters

A payment gateway or shipping provider should not leak provider-specific concepts across the whole commerce codebase. An adapter translates the provider into a smaller internal contract.

// illustrative contract — not a public endpoint
PaymentAdapter.authorize(order, paymentContext)
PaymentAdapter.handleCallback(providerPayload)
PaymentAdapter.refund(transaction, amount)
03 / CALLBACKS

Webhook safety

Callbacks should be authenticated where supported, parsed defensively, recorded with an idempotency key, acknowledged quickly and moved into controlled processing. Repeated provider delivery must not repeat a destructive action.

ValidateDeduplicatePersistAcknowledgeProcessRetry safely
04 / DEPLOYMENT

Production-safe deployment

Separate static marketing routes from application routes. Validate Nginx before reload, switch files atomically where practical, smoke-test application baselines, and keep a rollback path that does not require restoring the entire platform.

05 / MIGRATION

Incremental modernization

Inventory → wrap → replace → verify → retire. Each retired legacy module should leave fewer hidden dependencies, not simply relocate them to a new framework.

06 / RELIABILITY

Fail visibly, degrade safely

Non-critical failures should create a useful error reference and preserve the main journey where doing so is safe. Payment, inventory or security failures should never be silently converted into success.

Public documentation boundary

Exact API routes, credentials, signatures, database schemas and private operational runbooks are deployment-specific and are not published here.

GUIDES

Read a complete implementation path.

These guides are intentionally provider-neutral where possible. Exact deployed contracts remain project-specific.

SEARCH

Dedicated docs search

Search the generated public documentation index.

Search docs →
REGISTRY

Content registry workflow

Understand how published HTML becomes search, docs and release metadata.

Read guide →
GOVERNANCE

Independent release streams

Keep website, application, database and provider versions separate.

Read guide →