● Knowledge base

Connect anything — by protocol.

Vorkar connects by protocol, not by a fixed list of named systems — so you don't need us to "support" your specific system. You need to know how it speaks. This guide shows how to connect anything, including software you built yourself.

The method

Four steps to connect any system.

The same four steps work for a big-name SaaS, a database, or an app your team wrote. Only the details change.

1

Identify the protocol

Does your system speak REST, SOAP, SQL, NoSQL, or does it expose files (SFTP or a network drive)? Most systems state this in their own docs.

2

Identify the auth

How does it prove who you are — an API key, OAuth, a username & password, a token, or a certificate / connection string?

3

Gather the details

The endpoint or host, the credentials for your auth type, and what you want Vorkar to read.

4

Connect in Vorkar

Enter the details. Vorkar tests the connection, installs any driver or library it needs automatically, and connects — about 5–10 minutes when the prerequisites are in place.

By protocol

Find your system's protocol — then connect it.

The named systems below are examples, not a catalog. If your system speaks one of these protocols, it can connect — including software you built yourself. Nothing is "coming soon"; the protocol is what matters, not the brand.

REST

HTTP/JSON web APIs — the common language of modern cloud apps and services.

Typical systemse.g. Salesforce, NetSuite, ServiceNow — or your own REST API.
Typical authAPI key, OAuth 2.0, or a bearer token.
Custom / in-house: any app that speaks REST connects exactly the same way — find its endpoint and auth in its own docs.
SOAP

XML web services described by a WSDL — common in older enterprise apps and ERPs.

Typical systemse.g. SAP, legacy Oracle services — or an in-house SOAP service.
Typical authWS-Security, basic credentials, or a token.
Custom / in-house: point Vorkar at your WSDL and it reads the operations the same way — the brand doesn't matter.
SQL

Relational databases and warehouses queried with SQL.

Typical systemse.g. PostgreSQL, Oracle Database, Snowflake, MySQL — or your own database.
Typical authA database user & password, a key-pair, or a connection string — usually over TLS.
Custom / in-house: any database that speaks SQL connects with its host, credentials and (if needed) a connection string — Vorkar installs the driver for you.
NoSQL

Document and key-value stores that don't use SQL.

Typical systemse.g. document stores such as MongoDB — or your own NoSQL store.
Typical authA connection string, a username & password, or a token.
Custom / in-house: give Vorkar the store's connection string and credentials — find them in your store's own docs. Vorkar installs the driver automatically.
Files

Systems that expose files rather than an API — file shares and exported data.

Typical systemse.g. an SFTP drop, a network drive, or exported reports.
Typical authAn SFTP key or password, or network credentials.
Custom / in-house: a folder your systems drop files into connects the same way — Vorkar reads what's there, no API required.

System and product names are the trademarks of their respective owners, shown only as examples of systems that speak each protocol — not partnerships or endorsements. Wording is Vorkar's own; follow each link for the vendor's official documentation.

Open the platform → Not sure which protocol yours speaks? Ask us →