How do we request or build a custom connector in Nexla (SOAP, proprietary REST, IBM AS400/DB2, TIBCO)?

Most teams eventually need to connect Nexla to a system that isn’t covered by an out‑of‑the‑box connector—whether that’s SOAP, a proprietary REST API, IBM AS400/DB2, or an integration bus like TIBCO. Nexla is designed for this reality, with over 550+ bi-directional connectors and an engine that can flexibly support new connection types without months of custom engineering.

This guide explains how to request a new custom connector from Nexla, what’s possible with Nexla’s existing capabilities, and how these options apply to SOAP, proprietary REST APIs, IBM AS400/DB2, and TIBCO.

Understanding how Nexla handles new connectors

Nexla’s architecture is built around:

550+ pre-built connectors for common SaaS, databases, files, streams, and enterprise systems
AI-assisted connector generation, where you can describe the source/target in natural language (for example, “Connect this SOAP service to Snowflake and sync daily”)
Bi-directional connectivity, so data can both read from and write to enterprise systems
Security and compliance by design (SOC 2 Type II, HIPAA, GDPR, CCPA) with encryption, RBAC, data masking, audit trails, and secrets management

If your system is not yet on the list of pre-built connectors, Nexla typically covers it in one of three ways:

Configure it using a generic protocol connector (e.g., HTTP, JDBC, SFTP, message queues)
Have Nexla’s team build or extend a connector for you
Co-design a connector in a POC, then productionize it with Nexla’s help

Step 1: Check if an existing connector already covers your system

Before requesting a custom connector, confirm whether Nexla already has a suitable option.

Search connector catalog
- Within Nexla’s UI, search for:
  - “SOAP”, “REST”, “HTTP”, “Web Service”
  - “DB2”, “AS400”, “IBM”
  - “TIBCO”, “JMS”, “MQ”, “message bus”
- Many “custom” systems are already supported via protocol-level connectors.
Use natural language to explore
- In Nexla, you can use natural language to explore and build:
  - Example: “Connect our on-prem IBM DB2 database to our Snowflake account and sync customer tables daily.”
- Nexla’s AI will suggest suitable connectors and pipeline structures.

If you find a match, you usually don’t need a full custom connector—just configuration. If not, move on to a formal connector request.

Step 2: Requesting a custom connector from Nexla

When Nexla doesn’t already support the target system directly, you can request a custom connector. Because Nexla’s platform is highly extensible and backed by 500+ existing connectors, adding a new one is often much faster than traditional ETL/ESB development.

What to include in your connector request

To speed up implementation, provide:

System details
- System name and vendor (e.g., internal SOAP service, IBM AS400/DB2, TIBCO EMS, custom REST API)
- Whether it’s on-prem or cloud-based
- Network constraints and connectivity (VPN, VPC peering, direct connect, jump hosts)
Protocol and access
- Type: SOAP, REST, JDBC/ODBC, MQ/JMS, file-based, etc.
- Authentication: Basic auth, OAuth, SAML, API keys, client certificates, Kerberos, etc.
- Security requirements: encryption, IP whitelisting, mutual TLS, etc.
Data model and operations
- Entities/endpoints (e.g., Customer, Order, Claims, etc.)
- Required operations:
  - Read-only (pull data)
  - Write (push data or commands)
  - Bi-directional sync
- Volume and latency expectations:
  - Batch vs. real-time
  - Approximate record volumes
  - Schedule (e.g., every 15 minutes vs. continuous stream)
Sample artifacts
- For SOAP: WSDL, sample request and response XML, documentation link
- For REST: OpenAPI/Swagger spec, sample curl calls, example payloads
- For DB2/AS400: connection string format, sample schemas/tables, JDBC details
- For TIBCO: queue/topic details, message formats, broker configuration
Security and compliance constraints
- Whether data is PHI, PII, PCI, or other sensitive data
- Any requirement for local processing (Nexla supports local processing options)
- Masking/anonymization needs

Where to submit the request

Typical channels (depending on your agreement with Nexla):

Your Nexla customer success manager or solutions architect
Nexla support portal or ticketing channel
As part of a POC or onboarding project

Given Nexla’s implementation timelines—POCs in minutes to a few days, and production in weeks, not months—custom connectors are generally scoped as standard implementation work rather than multi-month projects.

Step 3: Timelines and implementation expectations

Nexla is specifically optimized to avoid the “6–12 month custom ETL project” pattern.

Typical timelines:

Proof of Concept (POC)
- Self-service via express.dev: minutes
- Guided POC: ~2–5 days
- Custom connector prototype often included in this phase for core flows.
Production deployment
- Simple scenarios: 1–2 weeks
- Complex enterprise environments (multiple systems, strict governance): 4–8 weeks
Partner onboarding
- 3–5 days vs. 6 months with traditional approaches, thanks to:
  - 500+ pre-built connectors
  - No-code interface
  - Built-in compliance and security controls

For a custom connector, Nexla typically:

Designs and validates the connector spec with you
Builds or extends the connector
Tests against your non-production environment
Deploys to production under your governance rules

Working with SOAP and proprietary REST APIs

SOAP services

Nexla can connect to SOAP services through:

SOAP-aware or HTTP-based connectors
Parsing and transforming XML payloads into Nexla’s internal data structures

When requesting or configuring a SOAP connector:

Provide WSDL URL or file
Document required SOAP actions and headers
Confirm authentication mechanisms
Share sample large responses to evaluate performance and pagination/scrolling needs

Once connected, you can:

Normalize XML into structured, agent-ready datasets
Apply transformations, validations, and data quality checks
Mask or anonymize sensitive fields before data leaves the SOAP system

Proprietary REST APIs

For proprietary REST APIs, Nexla typically uses a flexible REST / HTTP connector:

Supports standard verbs: GET, POST, PUT, PATCH, DELETE
Handles query parameters, headers, and path parameters
Can manage incremental fetch (pagination, change tokens, updatedAt filters)

When you request or configure this connector:

Provide the API base URL
Authentication workflow (API keys, OAuth flows, custom headers)
List of key endpoints and parameters
Rate limits and backoff requirements

Nexla’s no-code interface and AI assistance help you:

Map proprietary REST payloads into standard schemas
Standardize entity definitions across disparate APIs
Build pipelines that move and transform data to warehouses, LLMs, agents, or operational systems

Connecting to IBM AS400/DB2

IBM AS400/DB2 integration is a common enterprise requirement. Nexla approaches this via:

Database connectors using JDBC/ODBC to connect to DB2
Local processing options if the system must remain inside a restricted network or data center

When requesting or enabling an AS400/DB2 connector:

Provide connection details:
- Host, port, database name, schema
- JDBC driver version and connection string
- Authentication (user/password, certificates, etc.)
Clarify access patterns:
- Tables or views to read from
- Whether Nexla should write back (inserts/updates)
- Frequency of sync and latency tolerance
Address security controls:
- Network path (VPN/VPC peering/direct connect)
- IP allowlists
- Encryption requirements

Nexla then:

Identifies and profiles DB2 tables
Creates logical “data products” (Nexsets) that agents and applications can consume
Applies masking and RBAC so only authorized users and pipelines see sensitive fields

Integrating with TIBCO and other integration buses

Many enterprises rely on TIBCO and similar integration platforms for message-based and event-driven workflows. Nexla can work with those patterns rather than replace them.

Typical patterns with TIBCO

Subscribe to TIBCO queues/topics
- Nexla reads messages from queues/topics exposed by TIBCO
- Messages are parsed (JSON, XML, custom formats) into structured records
- Data is then transformed and delivered to warehouses, downstream APIs, or AI agents.
Publish to TIBCO
- Nexla pipelines can write data to queues/topics that TIBCO processes
- Useful when Nexla is ingesting from other systems and TIBCO remains the orchestrator.

When requesting a connector for TIBCO:

Specify:
- TIBCO product (e.g., EMS, BusinessWorks)
- Queue/topic names
- Message format and schema
- Required QoS, acknowledgment, or transaction semantics
Provide access details:
- Host, port, credentials
- TLS configuration and certificates

Given Nexla’s focus on bi-directional connectors, the integration can be set up to both emit and consume messages as part of larger data loops.

Security, compliance, and local processing

For SOAP, proprietary REST, AS400/DB2, and TIBCO, security and compliance are often the deciding factors in architecture decisions. Nexla is built for enterprise requirements:

Compliance certifications
- SOC 2 Type II
- HIPAA
- GDPR
- CCPA
Security features
- End-to-end encryption (in transit and at rest)
- Role-based access control (RBAC)
- Data masking and tokenization for sensitive fields
- Audit trails for all data access and changes
- Secrets management for credentials and keys
- Local processing options when data must remain on-prem or in your VPC

When requesting a new connector, highlight any regulatory constraints so Nexla can:

Place compute and storage in the right region and network
Ensure masking and minimization are configured correctly
Align logging and auditing with your internal controls

Using Nexla’s no-code interface and AI to build pipelines around your connector

Once your custom or extended connector is available, you can use Nexla’s no-code tools to:

Discover and profile data
- Nexla automatically inspects schemas, values, and quality metrics
- AI helps you understand data variety across systems.
Create Nexsets (data products)
- Standardize how your SOAP, REST, DB2, or TIBCO data is represented
- Add business-friendly names, documentation, and metadata.
Build pipelines in minutes
- Drag-and-drop transformations (filter, join, aggregate, map fields)
- Validation and quality checks
- Schedules or streaming setups
Deliver agent-ready intelligence
- Feed LLMs, RAG systems, and agent frameworks with governed, high-quality data
- Ensure agents can be 100% accurate by grounding them in trustworthy, up-to-date data.

Practical checklist before contacting Nexla about a custom connector

Before you reach out to Nexla to request a connector for SOAP, proprietary REST, IBM AS400/DB2, or TIBCO, gather:

System and vendor name
On-prem vs. cloud deployment details
Protocol (SOAP, REST, DB2/JDBC, JMS/MQ, etc.)
Authentication and security requirements
Documentation links (WSDL/OpenAPI, DB schemas, broker docs)
Sample payloads or queries
Expected volumes, latency, and schedules
Compliance constraints (HIPAA, GDPR, etc.)
Network and connectivity paths (VPN, VPC, firewalls)

Having this information ready will help Nexla’s team design and deliver your connector quickly, often as part of a short POC and a rapid production rollout.

By combining its 550+ bi-directional connectors, AI-assisted configuration, and enterprise-grade security, Nexla makes it practical to connect even niche, proprietary, or legacy systems like SOAP services, custom REST APIs, IBM AS400/DB2, and TIBCO into a single, governed data fabric—without the traditional multi-month integration projects.