Enterprise Connectors

AxonFlow Enterprise connectors let platform teams connect governed AI workflows to production systems such as CRM platforms, issue trackers, ITSM tools, travel APIs, and data services.

The important operational detail is that enterprise connector support has two layers:

• the Customer Portal, which manages a subset of connector records directly today
• the Agent runtime, which can load a broader set of connectors per tenant

That split matters for rollout planning, documentation accuracy, and customer expectations.

Connector Surface at a Glance

Connector	Runtime support	Portal-managed today	Typical use cases
Amadeus	Yes	Yes	Travel search, hotel lookup, airport discovery
Salesforce	Yes	Yes	CRM enrichment and customer workflows
Slack	Yes	Yes	Collaboration and incident workflows
Snowflake	Yes	Yes	Analytics and warehouse access
HubSpot	Yes	No	CRM enrichment, contact and deal workflows
Jira	Yes	No	Ticket search, comments, transitions, assignments
ServiceNow	Yes	No	Incident workflows, change requests, CMDB lookup

The current portal connector-management API validates a smaller allowlist than the full enterprise runtime. That is why some enterprise connectors are documented as runtime-supported but not yet portal-managed.

Portal-Managed Connector Types

The Customer Portal currently accepts these connector types directly:

• postgres
• cassandra
• salesforce
• amadeus
• slack
• snowflake
• custom

This is the right control-plane surface when you want to manage connector records, test them, update metadata, or disable them from the portal.

Runtime-Supported Connectors Beyond the Portal

The enterprise Agent runtime also supports:

• hubspot
• jira
• servicenow

These connectors are real enterprise capabilities in the runtime. They simply are not yet exposed through the current portal connector-type validation list.

Why Enterprise Connectors Matter

Connectors are where AxonFlow becomes production infrastructure rather than a generic LLM proxy. Once an agent can open a Jira ticket, query a CMDB, look up a customer in HubSpot, or fetch live travel data, three things matter immediately:

• governance: what the agent is allowed to do
• tenant isolation: whose credentials and downstream systems are in scope
• operations: how to rotate secrets, refresh runtime state, and troubleshoot failures

Operational Principles

• Treat connector setup as production configuration, not just a demo step.
• Keep secret rotation, connectivity validation, and runtime refresh in the same runbook.
• Be explicit about whether a connector is portal-managed today or only runtime-supported.
• Pair high-impact write connectors with approvals, auditing, and policy controls.

Recommended Reading Paths

Onboarding enterprise connectors

1. Connector Capability Matrix
2. Connector Config File
3. MCP Policy Enforcement
4. Monitoring Overview

Integrating business systems

1. HubSpot
2. Jira
3. ServiceNow

Building travel and booking workflows

1. Amadeus
2. Policy Management
3. Deployment Testing & Validation

Enterprise Connector Setup

This section preserves the portal and runtime operating details for connector setup in paid deployments.

Connector setup in enterprise AxonFlow is about much more than credentials. It is where platform teams decide how AI systems will reach production data, how those connections will be isolated across tenants, and how platform teams can change connector posture without redeploying the whole platform.

What The Current Portal Can Manage

The current Customer Portal connector-management API accepts these connector types:

• postgres
• cassandra
• salesforce
• amadeus
• slack
• snowflake
• custom

Those are the connector types you should treat as first-class enterprise portal-managed resources today.

At the same time, the enterprise agent runtime also includes additional enterprise connectors like hubspot, jira, and servicenow. Those connectors are real enterprise runtime capabilities, but the enterprise portal’s current validation layer has not caught up to all of them yet.

Enterprise Connector API

The enterprise portal registers:

Method	Path	Purpose
GET	/api/v1/connectors	List connector records
POST	/api/v1/connectors	Create a connector
GET	/api/v1/connectors/{connectorName}	Fetch one connector
PUT	/api/v1/connectors/{connectorName}	Update one connector
DELETE	/api/v1/connectors/{connectorName}	Delete one connector
POST	/api/v1/connectors/{connectorName}/test	Record a connectivity test result

Managed Connector Record

Each enterprise connector record can include:

• connector_name
• connector_type
• display_name
• description
• connection_url
• options
• credentials_secret_arn
• timeout_ms
• max_retries
• enabled

Defaults:

• timeout_ms: 30000
• max_retries: 3

Example: Create A Snowflake Connector

curl -X POST https://portal.example.com/api/v1/connectors \
  --cookie "axonflow_session=$AXONFLOW_SESSION" \
  -H "Content-Type: application/json" \
  -d '{
    "connector_name": "finance-warehouse",
    "connector_type": "snowflake",
    "display_name": "Finance Snowflake Warehouse",
    "description": "Read-mostly analytics access for finance copilots",
    "connection_url": "finance-org.us-east-1.snowflakecomputing.com",
    "credentials_secret_arn": "arn:aws:secretsmanager:us-east-1:123456789012:secret:axonflow/snowflake-finance",
    "timeout_ms": 30000,
    "max_retries": 3,
    "options": {
      "warehouse": "FINANCE_WH",
      "database": "FINANCE_DB",
      "schema": "PUBLIC"
    }
  }'

Example: Update A Connector

curl -X PUT https://portal.example.com/api/v1/connectors/finance-warehouse \
  --cookie "axonflow_session=$AXONFLOW_SESSION" \
  -H "Content-Type: application/json" \
  -d '{
    "display_name": "Finance Snowflake Warehouse - Production",
    "timeout_ms": 45000,
    "enabled": true
  }'

Use the update path for:

• changing timeouts or retries
• changing secret ARNs
• temporarily disabling a connector
• updating descriptions so platform teams understand production intent

Testing Connectors

The enterprise portal exposes POST /api/v1/connectors/{connectorName}/test, but the current implementation does not run a full live connector validation through the agent runtime yet. It currently:

• checks the record exists
• verifies whether it is enabled
• records a simulated test result
• updates health_status and last_health_check

So the safe interpretation is:

• useful for portal workflow
• not enough for production sign-off

A real production readiness check should still validate the connector through the agent runtime and its target system.

SaaS vs In-VPC Connector Scope

The portal behavior changes by deployment mode:

Mode	Connector Visibility
saas	Only connectors for the current tenant
invpc	Platform-wide connector visibility and management

This is one of the most important enterprise operations differences in AxonFlow:

• SaaS mode protects tenant boundaries
• In-VPC mode optimizes for enterprise platform-team visibility

Credential Strategy

Use credentials_secret_arn for production connector setup whenever possible. This gives you:

• better secret hygiene
• easier rotation
• less credential sprawl in UI or API workflows
• a cleaner audit story

For high-value enterprise systems like Salesforce, Snowflake, and custom internal APIs, this should be the default.

Connector Setup Patterns By Use Case

CRM And Customer Ops

Choose Salesforce or HubSpot when you need:

• governed customer-record access
• renewal and support assistants
• sales and revenue workflow automation

Engineering And ITSM

Choose Jira, ServiceNow, or Slack when you need:

• support escalation workflows
• incident and change automation
• operational approvals

Data And Analytics

Choose Snowflake, PostgreSQL, or custom connectors when you need:

• governed enterprise analytics
• internal knowledge workflows
• operational data retrieval at scale

Multi-Tenant Connector Operations

Use this model when connector records, tenant isolation, runtime loading, and cache refresh operations all need to line up.

AxonFlow Enterprise supports multi-tenant connector isolation, but there are two different surfaces involved:

• the enterprise customer portal, where platform teams create and update certain connector records
• the enterprise runtime, where the Agent loads connector instances per tenant and applies governance, caching, and health behavior

Older docs blurred those together. In practice, platform teams need to understand both.

The Two-Layer Model

Enterprise portal layer

The customer portal stores connector configuration records and exposes the portal API family:

• GET /api/v1/connectors
• POST /api/v1/connectors
• GET /api/v1/connectors/{connectorName}
• PUT /api/v1/connectors/{connectorName}
• DELETE /api/v1/connectors/{connectorName}
• POST /api/v1/connectors/{connectorName}/test

These are session-authenticated enterprise endpoints. They are the right place to manage connector metadata, connection URLs, secret references, timeout values, and enablement state for the connector types the portal accepts today.

Runtime layer

At request time, the Agent uses the tenant connector registry to load connector instances per tenant. That runtime:

• resolves configs with priority database > config file > environment
• caches connector instances with a default 30s TTL
• isolates connector instances by tenant_id + connector_name
• supports targeted refresh operations through Agent-side operational APIs

That distinction matters. A connector can be enterprise runtime-supported even if it is not yet selectable in the current portal UI/API allowlist.

Portal-Managed vs Runtime-Supported

The enterprise portal currently validates these connector types:

• postgres
• cassandra
• salesforce
• amadeus
• slack
• snowflake
• custom

The enterprise Agent runtime supports a broader set, including:

• hubspot
• jira
• servicenow

That means:

• if you are operating amadeus, salesforce, slack, snowflake, or the listed data connectors, the portal is the normal control plane
• if you are operating hubspot, jira, or servicenow, the runtime connector exists today, but you should not document it as a portal dropdown workflow unless the portal allowlist expands

How Tenant Isolation Works

Each cached connector instance is scoped to a tenant-specific key:

tenant-a:crm-primary
tenant-a:travel-search
tenant-b:crm-primary
tenant-b:it-helpdesk

This gives you separate connector instances, credentials, and cache entries even when tenants use the same connector type.

For enterprise SaaS deployments, the customer portal list and get operations are tenant-filtered. In In-VPC deployments, the same portal endpoints can operate with platform-wide visibility because the deployment is not relying on the same SaaS tenant-isolation model.

What a Portal Connector Record Stores

A connector record in the enterprise portal includes fields such as:

• connector_name
• connector_type
• display_name
• description
• connection_url
• options
• credentials_secret_arn
• timeout_ms
• max_retries
• enabled
• health_status
• last_health_check
• last_error

That is the right operational model for enterprise teams. You are managing governed runtime records, not just saving arbitrary YAML.

Example Portal Create Request

Use the enterprise portal session, not a fabricated bearer-token pattern:

curl -X POST https://portal.example.com/api/v1/connectors \
  -H "Cookie: axonflow_session=..." \
  -H "Content-Type: application/json" \
  -d '{
    "connector_name": "travel-search",
    "connector_type": "amadeus",
    "display_name": "Amadeus Travel Search",
    "description": "Tenant travel search connector for booking assistants",
    "credentials_secret_arn": "arn:aws:secretsmanager:us-east-1:123456789012:secret:axonflow/amadeus-travel",
    "options": {
      "environment": "production"
    },
    "timeout_ms": 30000,
    "max_retries": 3
  }'

Defaults in the portal handler today are:

• timeout_ms: 30000
• max_retries: 3

Example Portal List Response

The portal returns connector objects directly, not the older simplified healthy/last_used shape:

[
  {
    "id": "9f2d2f6d-9dc7-46dd-b740-1f82d3abfe21",
    "tenant_id": "tenant-123",
    "connector_name": "travel-search",
    "connector_type": "amadeus",
    "display_name": "Amadeus Travel Search",
    "description": "Tenant travel search connector for booking assistants",
    "credentials_secret_arn": "arn:aws:secretsmanager:us-east-1:123456789012:secret:axonflow/...masked",
    "timeout_ms": 30000,
    "max_retries": 3,
    "enabled": true,
    "health_status": "unknown",
    "created_at": "2026-03-30T09:00:00Z",
    "updated_at": "2026-03-30T09:00:00Z"
  }
]

Testing Connectors

The enterprise portal exposes:

POST /api/v1/connectors/{connectorName}/test

This is the right day-two validation step after:

• creating a connector
• rotating secrets
• updating timeouts or connection URLs
• switching a tenant to a new downstream system

Treat it as a control-plane validation step. It helps catch misconfiguration quickly before an agent workflow starts failing in production.

Agent-Side Refresh and Cache Operations

The following APIs are Agent operational endpoints, not portal endpoints:

• POST /api/v1/connectors/refresh
• POST /api/v1/connectors/refresh/{tenant_id}
• POST /api/v1/connectors/refresh/{tenant_id}/{connector_name}
• GET /api/v1/connectors/cache/stats

Use them when you need the runtime cache to pick up connector changes immediately instead of waiting for the default 30s TTL.

Example: refresh one tenant

curl -X POST https://agent.example.com/api/v1/connectors/refresh/tenant-123 \
  -H "X-License-Key: ${AXONFLOW_LICENSE_KEY}"

Example: refresh one connector

curl -X POST https://agent.example.com/api/v1/connectors/refresh/tenant-123/travel-search \
  -H "X-License-Key: ${AXONFLOW_LICENSE_KEY}"

Example: cache stats

curl https://agent.example.com/api/v1/connectors/cache/stats \
  -H "X-License-Key: ${AXONFLOW_LICENSE_KEY}"

Those runtime stats are especially useful during bulk tenant onboarding, secret rotation, and incident response.

Recommended Enterprise Rollout Pattern

1. Create the connector record in the enterprise portal if the connector type is portal-managed today.
2. Store credentials in AWS Secrets Manager or your approved secret store.
3. Run the portal test endpoint.
4. Force a targeted runtime refresh if you need the new config immediately.
5. Validate one governed request path end to end.
6. Confirm audit and monitoring behavior before exposing the connector broadly.

What Platform Teams Usually Get Wrong

• Treating runtime-supported connectors as though they are all portal-managed today.
• Updating a connector record and forgetting the runtime cache still has the old connector instance for up to 30s.
• Mixing provider-management guidance with connector-management guidance.
• Rolling out tenant credentials without validating the secret ARN and connection URL together.

Related Docs

• MCP Overview
• Connector Capability Matrix
• MCP Policy Enforcement
• Enterprise Provider Operations