Integration Hub documentation

Onboarding-issued endpoints and workflow setup

A practical technical reference for the managed Integration Hub flow: how endpoints are issued, what gets scoped before deployment, and how workflow status is checked without exposing private internals.

Reference

Endpoint availability

AreaCurrent availabilityNotes
Action intakeOnboarding-issued endpoint for approved workflow actions.Used after a managed pilot has been scoped and the expected payload has been agreed.
Status checksOnboarding-issued task or run status endpoint.Returns only the state connected to the issued task/run identifier and workspace context.
Client portalAccount-based access through the client portal.Used for onboarding, artifacts, tasks, and project visibility while self-service deployment is being built.
Payload shape

What gets scoped before an endpoint is issued

{
  "business_event": "new qualified lead",
  "source_system": "Website form",
  "destination_system": "CRM + notification channel",
  "required_fields": ["name", "email", "company", "intent"],
  "failure_path": "alert operator and keep retry evidence",
  "status_visibility": "client portal task/run view"
}
Guide

Current access model

Integration Hub is available as a managed onboarding path today. Endpoints, webhook paths, payload shape, authentication approach, and allowed source systems are issued during onboarding for each approved workflow.

Public self-service API activation, template selection, and automatic webhook deployment are planned for the SaaS v1 workflow lifecycle. They are not open for unassisted signup yet.

Guide

What onboarding includes

A managed integration starts with the business event, source system, destination system, expected payload fields, failure handling, and notification path.

After that scope is agreed, the workflow is configured, tested with sample payloads, connected to the client portal where relevant, and then moved into production with monitoring and backup checks.

Guide

Data and secret handling

Do not paste secrets, bearer tokens, API keys, customer records, or production webhook URLs into public forms or chat. Credentials are handled during onboarding and should be scoped to the minimum permissions required for the workflow.

Webhook URLs, tokens, n8n internals, and private service addresses are not published on this page. That is intentional: current access is issued per client and per workflow.

Guide

Self-service status

The public template catalog, deployment wizard, automatic webhook provisioning, event logs, usage events, and deployment secrets screens are still part of the upcoming self-service workflow lifecycle.

Until those features are live, the honest path is to request onboarding and receive integration details directly for the approved workflow.

Next step

Request access

To start a managed integration, describe the source system, destination system, event trigger, expected payload, and any approval or notification requirements. The issued endpoint details will be shared after the workflow has been scoped.