Connector & API Management
Connector & API Management is the integration hub of Nashua 360: the single control plane through which the suite talks to every system around it. It owns the full lifecycle of an integration, from the credentials and endpoints that define a connection, through the transformation rules that reconcile foreign data to the suite's own model, to the scheduling, monitoring and error handling that keep data flowing reliably. Where other modules produce and consume business data, this module governs how that data crosses the boundary between Nashua 360 and the outside world.
It sits within System Administration as the suite's outward-facing edge. Every external touch point is registered, credentialled and observed here: REST, SOAP and GraphQL APIs, Model Context Protocol servers, outbound and inbound mail, content platforms, customer and identity systems, electronic data interchange partners and banking channels. By concentrating this responsibility in one place, the module gives administrators a complete, auditable inventory of the organisation's integration surface rather than a scatter of point-to-point connections buried in individual features.
What the module does
The module manages the complete set of external connections a modern enterprise depends on. It provides full lifecycle control over API connectors spanning REST, SOAP and GraphQL, each with its own authentication scheme, base endpoints, headers, retry policy and rate limits. It configures Model Context Protocol servers that expose tools and resources to the suite's AI layer, and it holds the outbound and inbound mail configuration, both SMTP for delivery and IMAP for retrieval, that carries notifications, reports and campaign traffic.
Beyond individual connectors, it operates the movement of data at volume. ETL and ELT pipelines extract from source systems, apply declarative transformation rules and load into the suite, or land raw data first and transform in place where the target store is better suited to the work. It runs electronic data interchange with trading partners, maintains connectors to content platforms including WordPress, Sitecore, Adobe AEM, Drupal and Umbraco, and integrates customer and identity systems. Scheduled synchronisation, delta detection, dead-letter error queues and replay complete the picture, so that connections are not merely defined but continuously and observably operated.
The domain and data model
At the centre of the domain sits the idea of a connection: a durable, named relationship with one external system. A connection carries everything needed to reach and trust that system, its endpoints, its authentication material and its behavioural settings, held as structured configuration and typed by the kind of system it represents, whether an API, a content platform, an identity provider, a mail server or a banking channel. Secrets belonging to a connection are held apart from ordinary configuration and encrypted at rest, so that credentials never travel with the descriptive fields that administrators routinely edit.
A connection is given meaning by a pipeline, the definition of how data moves across it: which resource is read or written, in which direction, on what schedule and under which mapping. A pipeline references one or more transformation rules, the declarative logic that reshapes foreign records into the suite's own vocabulary and back again, resolving field names, formats, code lists and units. Each time a pipeline runs it produces a run record that captures what was attempted, what succeeded and what did not, and any record that cannot be processed is set aside in an error queue with its full context preserved for inspection, correction and replay. Together these concepts let an administrator reason about integrations in business terms: what is connected, what flows, how it is translated and what happened on the last run.
Principal workflows
Registering a connection is the first workflow. An administrator selects the type of system, supplies its endpoints and credentials, chooses an authentication scheme and validates the connection with a live test that confirms reachability and authorisation before the connection is saved. From there, building a pipeline binds that connection to a concrete data movement: choosing the resource, the direction, the mapping and the schedule, then dry-running it against a sample to confirm the transformation produces the expected shape.
Once live, pipelines run on their schedules or on demand. Each execution is monitored in real time, with throughput, latency and success rates surfaced on the hub. When records fail validation or a downstream system rejects them, they accumulate in the error queue, where an operator can examine the offending payload, adjust a mapping or the source data, and replay the affected records without rerunning the whole batch. Rotating a credential, revising a transformation rule or pausing a partner feed are all first-class operations, and every one of them is recorded so that the state of any integration at any past moment can be reconstructed.
Functional depth that matters
The module's authentication coverage is deliberately broad, because integration fails most often at the trust boundary. It handles API keys, bearer tokens, HTTP basic credentials and the full OAuth 2.0 grant set, including client credentials for service-to-service calls and authorisation code flows for delegated access, with automatic token refresh and expiry handling. For identity federation it configures SAML 2.0 with entity identifiers, sign-on and single logout endpoints, name identifier formats and X.509 signing certificates; OpenID Connect and generic OAuth 2.0 with discovery, scopes and redirect handling; and directory binding over LDAP and Active Directory with base distinguished names, user and group filters and TLS. Just-in-time provisioning and account linking translate a federated login into a governed user inside the suite, and federated logout closes the session cleanly at the provider.
Data-movement depth is equally considered. Content connectors speak each platform's native contract, the WordPress REST API, Sitecore's item and GraphQL services, the Adobe AEM content fragment API, Drupal JSON:API and the Umbraco delivery API, each with its correct authentication idiom. Banking connectivity covers PSD2, EBICS and SWIFT channels, retrieving statements and driving parsing to the CAMT.053 standard so that reconciliation upstream receives clean, structured transactions. Electronic data interchange applies standard document formats and partner-specific envelopes. Throughout, transformation rules enforce data-type coercion, code-list translation, currency and unit normalisation and referential validation, and the retry, back-off and dead-letter controls ensure that a transient outage degrades gracefully rather than losing data.
How it fits the Nashua 360 suite
Connector & API Management is the edge of the whole platform, and nearly every other module reaches the outside world through it. It works most closely with System Administration, of which it is part, drawing on the suite's role and permission model so that only authorised administrators can view or alter a connection and its secrets. It hands Model Context Protocol server definitions to AI Management, which governs how the suite's AI Workers discover and use external tools. It supplies Content Management with the live connectors that publish to and pull from external content platforms, and it delivers structured statement data to Accounting & Control, where the CAMT.053 parser and reconciliation routines consume the banking feeds this module schedules.
Customer and identity integrations feed the suite's CRM and access layers, so that contacts, accounts and authenticated users originate from systems of record and stay in step with them. Mail configuration underpins the notification and reporting services that many modules rely on to reach people. Because every connection is registered centrally, the rest of the suite consumes integrations by reference rather than embedding credentials of its own, which keeps the organisation's entire external surface inventoried, permissioned and observable from one place.
How AI Workers operate inside it
AI Workers are first-class operators in this module, not bystanders. An administrator can ask, in plain language, which connectors failed overnight, how a particular pipeline has trended, or which partner feed is behind schedule, and the Worker answers directly from run records and queue state. Workers execute actions within their granted permissions: triggering a synchronisation, replaying a batch of failed records after a mapping fix, rotating a credential on a schedule or pausing a misbehaving connection.
They watch continuously for anomalies and exceptions, flagging a spike in error-queue depth, a sudden drop in throughput, an authentication token nearing expiry or a partner whose delivery cadence has slipped, and they raise these as alerts before a human would notice. When a foreign payload arrives in an unfamiliar shape, a Worker extracts and structures its fields and proposes a transformation mapping, turning an inspection task into a review. Workers offer decision support by explaining why records were rejected and recommending the corrective rule change. Where governance requires it, a Worker participates as an approval or review node in the module's own workflows, signing off a new connection to a sensitive system or a change to a production pipeline before it takes effect, with its judgement recorded in the same audit trail as any human action.
