n8n and Market Monolith
Design n8n requests with credential storage and bounded retries.
Instructions published. Connection not available.
On this page
Plan an n8n workflow without confusing a generic HTTP node with a supported Market Monolith integration. Connection is not available in this release.
The client model
n8n's official HTTP Request credential documentation describes generic credential types, including header authentication. This provides a possible client mechanism; it does not establish a native Market Monolith node or tested workflow.
Keep the key in an approved credential store, not a literal node parameter, expression, URL or execution note.
Design the workflow boundary
Use a dedicated application and identify the account that owns the data. Review what the workflow saves in execution history and who can inspect it. A copied workflow must not silently acquire another account's authority.
Before any future business automation, define trigger scope, retry limits and a stop condition. Repeated triggers must not create duplicate paid work.
Safe future behavior
Persist a returned operation identity and retrieve its result instead of creating a new operation on every poll. Do not treat a timeout as proof that work failed, or a webhook as proof of final settlement.
The first-release authentication check is free and does not enable a workflow connection. See Operations and results.
Availability and support
Instructions are published; connection is not available. n8n owns its nodes, credentials and execution history. Market Monolith owns any future published API contract. No native node or working template has been verified.