Any API. Any direction.

Yes. Etlworks handles APIs that other ETL platforms can't — rotating tokens, custom HMAC signatures, multi-step async polling, deeply nested response payloads, partial failures with retry, multipart uploads with chunking. The HTTP connector exposes every detail you need: custom request templates, response parsing rules, authentication chaining, pagination schemes. If your API has a spec (OpenAPI, WSDL) you can usually be reading from it within an hour. If it's a custom internal API with weird auth, expect a few hours of configuration and you'll have it stable in production.

You can turn any Etlworks flow into a REST endpoint. Define the URL pattern, HTTP method, authentication, and response format — Etlworks handles the rest. Common patterns: expose a database query as a GET endpoint, accept a POST upload that triggers a transformation flow, build CRUD endpoints over a data source, expose internal data to partner systems. Includes auto-generated OpenAPI spec, Swagger UI, versioning, rate limiting. Used by customers who need lightweight backend services without standing up a separate API gateway.

Yes. GraphQL queries and mutations work like any other REST call. Subscriptions are supported via WebSocket transport — events stream into Etlworks and trigger downstream flows. For other streaming protocols: Server-Sent Events (SSE) is supported natively; chunked transfer and long-polling work for legacy streaming patterns.

Encrypted credential storage, per-tenant isolation, never sent to the LLM (relevant for customers using Simba). OAuth tokens are refreshed automatically before expiry. API keys can rotate on schedule. Multi-tenant credentials supported — different end-user OAuth tokens for the same flow. Customer-managed keys (BYOK / CMK) supported on Enterprise via AWS KMS, Azure Key Vault, HashiCorp Vault.

Depends on tier and underlying flow complexity. Standard tier handles thousands of requests per minute per endpoint comfortably. Enterprise scales to high tens of thousands. For published APIs that need extreme throughput (hot path traffic), we recommend horizontal scaling with multiple flow workers — sizing guidance provided during architecture review.

Yes. Simba can read an OpenAPI spec, generate connection configurations, suggest pagination patterns, and write the auth setup. Common workflow: “Connect me to the X API, paginated, OAuth, with rate-limit handling” — Simba builds the configuration, you review and approve. See the AI integration page for more on the agent.

Yes. Standard URL-prefix versioning (/v1/, /v2/) is supported via the routing layer. Header-based versioning also works. You can run multiple versions of the same endpoint simultaneously while consumers migrate, then deprecate older versions on your schedule. Each version maps to a distinct flow definition, so changes don't affect live consumers.