Everything you need to connect your enterprise. Nothing you don't.
Samba delivers serious integration capability in a deployment you own — inside your cluster, under your identity, on your network.
Deployment Model
Your subscription. Your data. Your rules.
Samba runs as a self-contained Kubernetes cluster deployed directly into your own cloud account. There is no shared infrastructure: your credentials, payloads, and audit logs stay inside the boundary you already maintain.
Single-tenant by design
Every customer gets a dedicated deployment. Your configuration, credentials, and integration data share nothing with any other organization — ever. Data sovereignty is structural, not a policy commitment.
Three-tier container isolation
Three purpose-built containers in one cluster: a Control Plane for UI and configuration, a Sandbox Executor for dev and test under constrained resources, and a Production Executor with dedicated priority and exclusive access to production credentials. Dev work cannot reach production secrets.
Cloud-agnostic by architecture
The same architecture runs on AKS, EKS, or GKE, with Helm charts and Kustomize overlays keeping environment-specific configuration clean and repeatable. Deployment is GitOps-driven, so what is running corresponds to a reviewed commit.
AI Authoring
Non-deterministic model, deterministic gate
AI drafts transforms; a formal grammar decides whether the draft is admissible. Nothing reaches the runtime without passing that gate, and what ships is Python a human reviews and a unit test covers.
Grammar-validated output
The grammar encodes what is legal in the domain, not merely what is well-formed. A syntactically perfect expression that breaks a domain rule is rejected with a specific reason, before it can be saved.
Inspectable artifacts
What the AI produces is a Python expression — readable, diffable, unit-testable, and committed to source control like any other change. There is no opaque model artifact and no proprietary DSL in between.
Inference in your tenant
AI authoring runs against your Azure OpenAI endpoint, under your key, inside your tenant — we do not host inference on your behalf. The platform also runs entirely without AI; every AI surface is additive.
Evidence & Audit
Compliance capability, not an enterprise upsell
Audit logging, change control, secrets management, RBAC, and control evaluation ship as the platform. They are not add-ons, and they are not priced separately.
Audit the application cannot rewrite
Every configuration change, flow execution, and credential use is recorded with a correlation ID, the acting user, and old/new values. Immutability is enforced by a database trigger rather than application code, so the guarantee survives a compromise of the application tier.
Live control evaluation
A catalog of 54 security controls is evaluated against the cluster Samba is actually running in — network policy, RBAC, container security, admission policy, secrets, backups, and deployment readiness — each carrying its SOC 2 criterion and NIST 800-53 lineage.
IdP-agnostic OIDC / OAuth 2.0
Authentication is handled entirely via OpenID Connect. Bring your own identity provider — Entra ID, Okta, Google, or any OIDC-compliant IdP. Client IDs, secrets, and authority URLs are supplied at install time via Kubernetes Secrets, never baked into an image.
Secrets management
API credentials and client secrets are centralized in HashiCorp Vault with audit logging on every access, or mounted from Azure Key Vault at runtime. No credentials are persisted in application configuration or container images.
Recovery proven by restoring
Backups run daily and are verified weekly by performing an actual restore, rather than asserted annually by policy. The control fails if the most recent successful restore is more than seven days old — which is a materially stronger answer to a recovery control than most vendors can give.
Execution isolation
The production executor runs under dedicated Kubernetes priority classes and resource quotas with exclusive access to production-tier credentials. The sandbox executor is prevented from reaching production secrets by architecture, not policy.
Core Capabilities
Built for real-world integration work
From a single field mapping to a multi-step orchestration across six systems, without ceremony.
REST endpoint orchestration
Chain any sequence of REST endpoints into a single flow. Output from each step — headers, response body, derived values — can feed the payload or query parameters of the next.
Python-native transforms
Field mappings are plain Python expressions. Simple lookups stay simple; complex business logic is just more Python. No proprietary DSL to learn or to hire for.
Replication & deduplication
Configure source-to-target replication with built-in deduplication. Keep systems in sync without duplicating records or triggering redundant downstream processes.
JSON & XML support
Works natively with both. Map between formats, handle nested structures, and deal with the quirks of legacy XML APIs without special tooling.
Universal API authentication
API keys, bearer tokens, two-legged OAuth, three-legged OAuth, and basic auth. Configure credentials once and reuse them across any number of flows.
Monitoring & alerting
Schedule or trigger integrations on demand. Monitor every run from one dashboard — step-by-step logs, structured error reporting, and configurable alerts.
Synchronize, push, or upsert
Compare source and target to insert what is new and update what changed, or push insert-only when the target does not need reading. Inbound webhook payloads route to the same insert or update lane on a key match, in real time.
Composite record matching
Match source and target records on a combination of fields rather than a single key — for the systems where no one field is actually unique, which is most of the interesting ones.
Incremental sync
An opt-in timestamp parameter on the source call so routine runs fetch only what changed. Format is yours to control — ISO-8601, date-only, Unix epoch. The first run is a full scan, and the cursor advances only after a successful one.
Enrichment & write-back
Fetch related data from a second system before the target write, so a flow can assemble a record from several sources. After the write, stamp the target's returned identifier back onto the source record.
Pagination handled for you
Next-link and offset or page cursors are followed until the full record set is retrieved. Paging is a property of the endpoint configuration, not something you hand-roll per integration.
Promotion with approval gates
Move an integration from Development to Testing to Production behind approval gates, and export any integration as a portable JSON template — reusable across deployments, reviewable in a pull request, and archivable as evidence.
Scope
What Samba deliberately does not do
Disclosed limitations cost less than discovered ones. Each of these is a considered position, not a backlog item.
No target-record deletion
The execution engine never issues a delete against a target system as part of a sync, and no setting changes this. Accidental mass-deletion is the highest-consequence failure in data integration; it should take a deliberate human decision in the system that owns the data.
No silent fallbacks
When something is missing or mismatched, Samba fails explicitly and logs why, rather than substituting a default or guessing at a value.
REST / HTTP and XML only
SFTP, message queues, SOAP, GraphQL, and direct database connections are out of scope by design. The zero-connector model is specifically about API-first integration.
One inference provider today
Azure OpenAI. The provider sits behind a single-method interface, so adding a second is contained work, but it is code, not configuration.
Write-back is not bidirectional sync
Write-back stamps a value onto the source record after a target write. It does not detect or resolve conflicts when both sides change independently between runs.