For developers

Integration principles and supported deployment patterns.

Marres is a TypeScript web application with a React interface, an Express service layer, PostgreSQL-backed persistence, and separate computational paths for heavier analysis. Selected baseline tooling is implemented in Python.

Integration model

Integrations should operate on explicit analysis resources and structured artefacts rather than scraping rendered pages. Approved agent access can be scoped to the minimum required capability. Browser-session credentials should not be repurposed as integration credentials.

Core resource concepts

Analysis — the durable workspace for a decision.
Run — one execution of an analytical pipeline.
Artefact — a structured or rendered output attached to an analysis.
Saved evidence profile — an approved organisation-level evidence result used for comparison.
Compiled market dataset — validated comparable profiles prepared for modelling.
Simulation session — persistent NS Loop state, turns, predictions, and calibration records.
Financial profile — commercial inputs used by relevant models.

Safe integration principles

Request only the scopes the integration needs.
Treat resource identifiers as opaque.
Preserve run and artefact provenance.
Make state-changing requests idempotent where the workflow permits.
Handle asynchronous runs as jobs rather than holding a request open indefinitely.
Never assume access to one resource grants access to a related resource.
Do not expose model-provider keys to the browser.
Validate uploaded formats and display mapping proposals for human approval.

Deployment outline

A supported self-hosted deployment requires:

a container runtime;
PostgreSQL;
a strong session secret;
a separate credential-encryption key;
an initial administrator account; and
configured model and collection providers for the features being used.

Health checks should verify both the application and database before traffic is accepted. Database migrations or schema synchronisation should complete before the application starts serving requests.

API publication status

The current source includes internal application endpoints and scoped agent keys, but it does not yet present a stable, versioned public API contract. Until request schemas, error semantics, rate limits, deprecation policy, and generated OpenAPI definitions are stabilised, publish integration principles and approved examples rather than a complete endpoint reference.

Compatibility

Public API documentation should begin only after a version prefix and support policy exist. Internal routes may change with the application and must not be treated as a public compatibility promise.

Related product page: For Developers — product page

← Security and data handling Agent API →

Documentation draft · Source baseline 16 August 2026