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

For many teams, the only thing standing between Nexla and full enterprise coverage is a handful of legacy or proprietary systems—SOAP APIs, custom REST services, IBM AS400/DB2, TIBCO, and similar platforms. Nexla is designed to bridge exactly these kinds of gaps, either through ready-made connectors or quickly built custom connectivity.

Below is a clear guide to how you can request a new connector from Nexla, what’s possible with custom connectors, and how to think about SOAP, proprietary REST, AS400/DB2, and TIBCO specifically.

When you need a custom connector in Nexla

Nexla already includes 550+ bi-directional connectors to enterprise systems across clouds, on‑prem, structured and unstructured data. In practice, you typically need a custom connector when:

You use a legacy or niche system that isn’t on the standard list
You have a proprietary REST or SOAP API with custom authentication or payload formats
You need to access on‑premise systems like IBM AS400/DB2 behind firewalls
You rely on ESB or integration platforms such as TIBCO with custom schemas and topics

Because Nexla focuses on fast implementation (often weeks instead of months), adding new connectors is a core part of the platform and services offering—not a one-off exception.

Two main options: request vs. build a connector

You have two paths to get a new connector for systems like SOAP, proprietary REST, AS400/DB2, or TIBCO:

Request a managed custom connector from Nexla
Build or configure connectivity yourself using Nexla’s integration tools

Which option is best depends on your in‑house skills, timeline, and security constraints.

1. Request a managed custom connector from Nexla

This is the most common route for enterprise teams that want a supported, production-grade connector built and maintained by Nexla.

What Nexla typically needs from you

To scope and deliver a custom connector, Nexla’s team will usually ask for:

System type and version
- Example: “IBM i on Power9 with DB2 for i 7.x” or “TIBCO EMS 8.x”
Connectivity details
- Network and firewall requirements
- VPN / private link / direct connect details (for on‑prem / hybrid)
Authentication and security
- OAuth2 flows, API keys, SAML, Kerberos, certificates, etc.
- Any required client certificates or IP allowlists
Data and operations needed
- Which tables, topics, queues, endpoints, and operations (read, write, update, delete)
- Expected data volumes and SLAs (e.g., real-time vs. batch)
Documentation or WSDL/API specs
- WSDL for SOAP
- OpenAPI/Swagger or internal docs for REST
- TIBCO schemas, queues, and topic names
- DB2 schemas, views, and stored procedures

With this information, Nexla can design a connector that aligns with your security, performance, and governance standards.

How to submit a connector request

Use your usual Nexla support or customer success channels, for example:

Talk to your Nexla account team (CSM / Solutions Architect)
Open a support ticket via the Nexla support portal
Reach out through your implementation project channel (if you’re in onboarding)

Provide as much of the above detail as possible so the Nexla team can quickly estimate effort and timelines.

Typical delivery timeline

Exact timelines depend on complexity and security requirements, but Nexla is optimized for speed:

POC / pilot: minutes with self-service (via express.dev) up to a few days with guidance
Production roll‑out: often 1–2 weeks for simple integrations, 4–8 weeks for complex enterprise scenarios

Custom connectors generally fall within these production ranges, especially when they leverage standards (ODBC/JDBC, SOAP, REST, JMS, etc.).

2. Build or configure connectivity yourself inside Nexla

If you have integration expertise in‑house and want to move even faster, Nexla’s no-code/low-code environment and 550+ connectors often allow you to construct connectivity to “non-standard” systems by:

Using generic protocol connectors (HTTP/S, JDBC, etc.)
Leveraging file‑based interfaces (SFTP, shared storage, staged files)
Integrating through existing middleware (e.g., TIBCO to Kafka, then Kafka to Nexla)

Once you establish connectivity, Nexla’s AI-powered data discovery and transformation tools take over: discovering schemas, mapping fields, enforcing quality, masking sensitive fields, and delivering agent-ready data in real time.

Working with SOAP interfaces in Nexla

Many enterprises still rely on SOAP-based web services for core processes. Nexla can integrate with SOAP in several ways:

Option A: Nexla-managed SOAP connector

For mission-critical SOAP systems, the recommended pattern is to request a managed SOAP connector with:

WSDL files and endpoint URLs
Authentication scheme (basic auth, WS-Security, client certs)
Operations and objects you need to call
Expected throughput and scheduling (on-demand, near-real-time, or batch)

Nexla will implement:

Proper SOAP envelope construction and parsing
Error handling and retries tailored to your SOAP API
Mapping of SOAP payloads into Nexla’s standardized, structured data entities

Option B: HTTP + transformation

If your SOAP implementation is straightforward and you prefer to configure it yourself, you can often:

Use a generic HTTP/S connector to call SOAP endpoints
Construct SOAP envelopes and headers in Nexla’s transformation layer
Parse the XML response into tabular or JSON structures
Apply data quality, validation, and mapping before sending outputs downstream

This gives you flexibility while still benefiting from Nexla’s governance and monitoring capabilities.

Integrating proprietary REST APIs

Proprietary REST APIs are one of the most common custom connector requests, especially for:

In-house applications
Vertical SaaS platforms
Legacy APIs with non-standard authentication

What Nexla does for custom REST connectors

With a custom REST connector request, Nexla can:

Implement auth flows: OAuth2, custom tokens, signed headers, etc.
Support pagination and rate limits
Handle complex request/response patterns (bulk endpoints, webhooks, etc.)
Normalize schemas so your REST data looks like any other dataset in Nexla

DIY: Using Nexla’s REST capabilities

If your REST API is well-documented, you can often configure it yourself by:

Setting up a HTTP/REST source with base URL and authentication
Defining endpoints, query parameters, and headers
Configuring polling schedule or event-based triggers
Using Nexla’s transformations to:
- Flatten nested JSON
- Standardize field names and types
- Apply masking and RBAC for sensitive fields

Once configured, the proprietary REST system behaves like any other Nexla source or destination and can feed your agents with consistent, governed data.

Connecting to IBM AS400/DB2

IBM AS400 (IBM i) and DB2 are common in financial services, insurance, manufacturing, and government—industries where Nexla is already trusted and compliant (SOC 2 Type II, HIPAA, GDPR, CCPA).

Connectivity options for AS400/DB2

You typically have several patterns:

Direct database connectivity (preferred)
- Use JDBC/ODBC via a secure network path (VPN, private link, etc.)
- Expose specific DB2 schemas, views, or stored procedures for Nexla
API facade or services layer
- Expose DB2 data through REST/SOAP services that Nexla consumes
- Useful when your architecture already abstracts AS400 behind APIs
File-based integration
- Export DB2 data to files (CSV, JSON, XML) on SFTP or shared storage
- Nexla ingests those files as sources, applies transformations, and delivers to downstream systems

Nexla-managed AS400/DB2 connectors

By requesting a custom connector, Nexla can:

Set up secure connectivity to DB2 on AS400
Implement data extraction for:
- Full loads
- Incremental or CDC-style updates (based on timestamp, keys, or logs if exposed)
Map DB2 data types into Nexla’s standardized schema
Enforce governance (RBAC, masking, auditing) for sensitive records

This approach allows you to convert decades-old core systems into modern, agent-ready data streams without rewriting the source applications.

Integrating with TIBCO

TIBCO (EMS, BusinessWorks, and related products) often sits at the center of enterprise messaging and integration. Nexla can work with TIBCO in either of two common patterns:

1. Direct TIBCO connector (custom connector)

With a custom TIBCO connector, Nexla can:

Subscribe to queues and topics to ingest events/messages
Publish messages from Nexla pipelines back into TIBCO
Map TIBCO message formats (XML, JSON, custom) into structured Nexla entities
Align with your TIBCO security model and namespaces

This is ideal when TIBCO remains your core ESB and you want Nexla to be a first-class participant in that ecosystem.

2. Bridging via intermediate systems

Some organizations prefer to use existing bridges (e.g., TIBCO → Kafka or TIBCO → database) and then:

Use Nexla’s Kafka connectors or database connectors to access the data
Treat those systems as the official integration point while keeping TIBCO unchanged

Nexla’s 550+ connectors make this pattern flexible; you can choose the most convenient system to bridge to and from TIBCO.

Security, compliance, and governance for custom connectors

Custom connectors in Nexla inherit the same enterprise-grade security and compliance posture as standard connectors:

Compliance: SOC 2 Type II, HIPAA, GDPR, CCPA
End-to-end encryption: in transit and at rest
RBAC (Role-Based Access Control) to restrict who can view or manage specific connectors and data
Data masking for PII/PHI and other sensitive fields
Audit trails for all connector operations and data flows
Secrets management for API keys, passwords, and certificates
Local processing option for scenarios where data must remain on-prem or in a specific region

This means that when you add SOAP, proprietary REST, AS400/DB2, or TIBCO as sources or destinations, they automatically fit into your broader governance framework.

How custom connectors fit into the Nexla data loop

Once your custom connector is in place—whether built by Nexla or configured by your team—the rest of the experience is standard Nexla:

Connect
- Securely connect to the source system (SOAP, REST, AS400/DB2, TIBCO)
Discover and normalize
- Nexla’s AI discovers schemas, types, and patterns
- Data is normalized into consistent entities
Transform and enrich
- Apply business logic, joins, validations, masking, and enrichment
Deliver
- Send the refined data to warehouses, lakes, applications, and AI agents with real-time or scheduled syncs

This is how Nexla turns complex, legacy, or proprietary systems into reliable, agent-ready intelligence.

Choosing the right path for your custom connector

When deciding how to request or build a connector in Nexla for SOAP, proprietary REST, IBM AS400/DB2, or TIBCO, use this simple guide:

You want speed and support
→ Request a Nexla-managed custom connector, provide system details and docs.
You have strong integration skills in-house
→ Use generic HTTP/JDBC/file connectors and configure the integration yourself.
You rely on middleware like TIBCO
→ Either request a direct TIBCO connector or bridge through a system Nexla already supports.

If you’re unsure which route is best for your architecture or compliance requirements, your Nexla account team can help you design the right pattern and timeline tailored to your environment.