Side by Side
At a Glance
15 dimensions of comparison between Naftiko and Pandium — same row, different layer of the stack. Scan top-to-bottom to see where each product makes a different choice on the same axis.
Dimension
Naftiko
Pandium
Category
Naftiko
Spec-driven integration platform
Pandium
Embedded iPaaS — multi-tenant credential broker + 200+ pre-built connectors + sync runtime for B2B SaaS
Origin
Naftiko
Kin Lane (API Evangelist) + Jerome Louvel (Restlet → Talend → Qlik), 2025
Pandium
Pandium, Inc. — code-first embedded iPaaS targeting B2B SaaS vendors
Primary primitive
Naftiko
Capability — declared in YAML; consumes + exposes
Pandium
Integration + Tenant + Release + Run + ConnectorCall
Layer in the stack
Naftiko
Build-time + ship-time + runtime engine that authors integrations
Pandium
Runtime execution surface — per-tenant credential broker + scheduled sync engine for the host SaaS's customers
Core artifact
Naftiko
YAML capability spec (declarative, multi-protocol)
Pandium
Versioned Integration release + per-customer Tenant configuration + per-call ConnectorCall proxy
Open source posture
Naftiko
Apache 2.0 Framework, free Fleet community, paid Standard / Enterprise
Pandium
SaaS-only — Free (1K req/mo), Professional (100K req/mo), Enterprise (custom). No on-prem option in public tiers.
Multi-protocol exposure
Naftiko
REST + MCP + Skills + Webhooks + A2A — same capability, all protocols
Pandium
Pandium REST API (14 ops across 5 resources) — single-protocol. The host SaaS embeds Pandium UI / handles MCP itself.
Governance scope
Naftiko
Design-time (Spectral lint), admission (Kyverno / OPA), runtime engine
Pandium
Per-tenant credential isolation + per-plan rate-limit + run-level status observability. No spec-layer governance.
Discovery surface
Naftiko
Backstage capability catalog + scorecards + apis.io discovery
Pandium
Host-SaaS-embedded marketplace UI listing the integrations the SaaS vendor has enabled — no public catalog.
Audit / observability
Naftiko
OpenTelemetry + Prometheus + structured logs from every capability container
Pandium
Per-run status (pending/running/completed/failed) + per-tenant run history. Self-contained — no OTel pipe.
Identity / credential management
Naftiko
Runtime secret injection (env, ExternalSecrets); Keycloak / OpenFGA roadmap
Pandium
Per-tenant credential broker — host SaaS never holds customer OAuth tokens; Pandium proxies every connector call with the tenant's stored credentials.
Cost / FinOps
Naftiko
Cost-center labels propagated to K8s; Kubecost integration
Pandium
Per-request + data_egress (GB) + compute_seconds metered; FOCUS-aligned billing across api/endpoint/tier/region/consumer.
Catalog breadth
Naftiko
Bring-your-own — author any integration as a capability YAML
Pandium
200+ pre-built connectors (Salesforce, HubSpot, NetSuite, Shopify, etc.) + customer-built bespoke connectors
Target buyer
Naftiko
Platform engineers + integration leads at enterprises with API sprawl
Pandium
Product + engineering teams at B2B SaaS vendors who need a customer-facing integration hub
Founder framing
Naftiko
“Capability fleet” — many ships, one navy
Pandium
“Help B2B SaaS companies meet customer integration demands without building the plumbing”
Common Ground
Where They Overlap
Both Naftiko and Pandium bet on the layer above per-vendor MCPs. Here are the 8 concrete places where those bets actually meet — same problem, sometimes the same shape, increasingly the same conversation.
1
Both treat per-tenant credentials as the load-bearing concern
Pandium's per-tenant credential broker is the entire reason customers pick it — the host SaaS never holds the downstream OAuth tokens. Naftiko's
binds block + roadmap toward Keycloak / OpenFGA aims at the same outcome from the engine side. Both refuse the ‘developers manage raw OAuth tokens in app code’ anti-pattern.2
Both ship pre-integrated connector libraries
Pandium ships 200+ pre-built connectors across CRM, ERP, accounting, payments, marketing, and HCM. Naftiko Fleet ships a growing capability catalog (now published at apis.io) where every entry is a versioned, governed, multi-protocol capability. Both refuse the ‘every customer integration starts from zero’ default.
3
Both model integration lifecycle as build → deploy → run → observe
Pandium's Integration → Release → Tenant → Run flow is exactly the lifecycle Naftiko's spec → CRD → Deployment → OTel emits follow. Both products refuse to treat integrations as one-shot scripts; they're versioned artifacts with operational lifecycle.
4
Both ship usage metering with FinOps-aware dimensions
Pandium's FinOps file meters api_requests + data_egress + compute_seconds with cost allocation by api/endpoint/tier/region/consumer. Naftiko propagates cost-center labels into Kubecost for per-call attribution. Both refuse the ‘no per-call cost visibility’ anti-pattern that traditional iPaaS leaves customers stuck in.
5
Both expose machine-readable API surface area
Pandium publishes OpenAPI + JSON Schema + JSON-LD via the api-evangelist/pandium profile. Naftiko publishes capability YAML as the entire spec. Both treat the API surface as a first-class governance artifact, not a side effect.
6
Both have a multi-tenant runtime concept
Pandium's Tenant scopes credentials, config, and run history per customer. Naftiko's capability container runs with its own consume + expose topology and label propagation. Both isolate at a unit-of-customer-value layer, not at the cluster tenant level.
7
Both refuse the visual low-code-builder default
Pandium markets itself as “code-first” — explicitly distinguishing from Workato / Tray / Boomi who lean visual. Naftiko's spec is YAML; capabilities are authored, not dragged. Both target engineering teams, not citizen integrators.
8
Both publish operational signals as machine-readable data
Pandium's rate-limits, plans, and finops files are API Commons specs — discoverable + diffable. Naftiko ships OpenTelemetry + Prometheus from every capability container. Both refuse to make ops a screenshot-and-PDF affair.
Where We Diverge
How Naftiko Is Different
The clearest single-sentence difference: Pandium is a multi-tenant credential broker and sync engine that sits between a B2B SaaS host and its customers' downstream systems; Naftiko is a spec-driven engine that turns any API into a multi-protocol, governed capability. Pandium's value is per-tenant managed plumbing for one SaaS vendor's customer base. Naftiko's value is reusable capability authoring + governance + multi-protocol exposure across an enterprise. Different problem shapes — Pandium for B2B SaaS embedded integrations; Naftiko for enterprise capability fleets.
1
Embedded iPaaS vs spec-driven engine
Naftiko
Naftiko authors capabilities as YAML and runs them as Docker containers. The capability is the artifact; the engine reads it. Not a hosted multi-tenant SaaS — runs on customer infra.
Pandium
Pandium operates the multi-tenant runtime for B2B SaaS vendors. Each SaaS vendor's customers each get a scoped tenant; Pandium runs the syncs, holds the credentials, and surfaces the marketplace.
Different problem — Pandium's value is the operated multi-tenancy; Naftiko's value is the spec layer.
2
Open-source-self-hosted vs SaaS-only
Naftiko
Apache 2.0 Framework runs in your container, your Kubernetes, your VPC. Open-source is the engine.
Pandium
Hosted SaaS by default — Free, Professional, Enterprise tiers all hosted at api.pandium.io. No public on-prem option.
3
Multi-protocol expose vs single REST API
Naftiko
Any capability exposes REST + MCP + Skills + Webhooks + A2A from a single spec. Same capability, multiple surfaces.
Pandium
Pandium exposes a single REST API (14 ops across 5 resources). MCP and agent surfaces are the host SaaS's job to build on top.
4
Capability primitive vs Integration + Tenant + Run primitives
Naftiko
Primary identity is ‘the thing that does X’ — composed from consumes and exposes, versioned as a YAML artifact.
Pandium
Primary identities are Integrations (versioned definitions), Tenants (per-customer instances), Releases (pinning), Runs (execution history), and ConnectorCalls (proxy events). Customer-scoped, sync-shaped.
5
Three governance altitudes vs auth + rate-limit governance
Naftiko
Spectral rulesets at design time, Kyverno / OPA at admission time, runtime checks in the engine. Lifecycle-shaped governance.
Pandium
Governance surface is auth (per-tenant credential isolation) + rate-limit (per-plan quotas) + run status (per-run failure surface). Runtime-shaped — no design-time or admission-time policy layer.
6
Bring-your-own infra vs Pandium-managed infra
Naftiko
Customer runs the engine on their infra; controls the data plane, network egress, secrets, and storage. Backstage + Kubecost + ExternalSecrets are first-class.
Pandium
Pandium runs the infra; customer hands them an OAuth scope per tenant and consumes via REST. The integration runs in Pandium's plane, not the customer's.
7
Enterprise integration team vs B2B SaaS product team
Naftiko
Sally the Integration Engineer at a regulated enterprise — many APIs, many domains, many cost centers, governance is the load-bearing concern.
Pandium
Product + engineering at a B2B SaaS vendor — many customers, many downstream systems, embedded integration UX is the load-bearing concern.
8
Capability composition vs connector library
Naftiko
Capabilities compose — applied capabilities consume source capabilities following DDD aggregate patterns. The spec layer makes composition declarative.
Pandium
Connectors are pre-built and shipped — host SaaS picks from 200+ or builds bespoke. No declarative composition layer; integrations are authored one connector at a time.
Partnership Thesis
Service Partnership
Naftiko is the spec-driven authoring engine. Pandium is the multi-tenant credential broker and sync engine for B2B SaaS. The capability map below treats Pandium as the per-tenant credential broker and downstream sync executor under Naftiko's spec layer — Pandium holds the OAuth tokens, runs the syncs, and brokers the connector calls; Naftiko authors the capability, exposes it as REST + MCP + Skills, governs it with Spectral / OPA / OTel, and ships it into Fleet.
“Naftiko brings the spec layer, the multi-protocol exposure, and the open-source engine. Pandium brings the per-tenant credential broker, 200+ connectors, and the embedded iPaaS runtime. Together: B2B SaaS vendors get a Naftiko-governed, MCP-callable, agent-discoverable integration surface backed by Pandium's tenant-scoped credential management.”
Two First-Meeting Questions
Q1. Pandium connectors as Naftiko capability surfaces
Would Pandium support a documented ‘wrap me as a Naftiko capability’ pattern — where every Pandium connector (Salesforce, HubSpot, NetSuite, etc.) can be auto-synthesized as a Naftiko capability YAML with typed operations, Spectral / OPA governance, and MCP exposure? The capability map below treats the Pandium connector proxy as a Naftiko-consumable surface; codifying that pattern would let every B2B SaaS that ships Pandium also ship an agent-callable, governed integration surface.
Q2. Naftiko-built capabilities back into the Pandium connector library
Would Pandium open a path for customer-built Naftiko capabilities to land in the Pandium connector library as managed connectors — bringing the breadth of Pandium's catalog and the customization of Naftiko's spec layer together in one runtime? Today the Pandium catalog is Pandium-curated; opening it to Naftiko-authored entries would compound the breadth advantage and give B2B SaaS vendors a path from ‘custom one-off’ to ‘managed connector’ without leaving the spec layer.
Integration Kit
Partnership Capability Map
10 Naftiko capabilities authored to integrate with Pandium as a service partner. Each one consumes a specific Pandium surface and exposes it as REST + MCP through the Naftiko engine — shipped as inline alpha2 YAML in the api-evangelist repository and published to the apis.io capability catalog.
Pandium Integrations
pandium-integrations
Browse Pandium's integration catalog and inspect versioned releases — the read-only surface for catalog discovery.
Pandium Tenants
pandium-tenants
Create, list, get, and update Pandium tenants — the per-customer integration instances scoped with their own credentials and config.
Pandium Runs
pandium-runs
List, get, and trigger tenant syncs — the sync execution surface used to drive Pandium's run lifecycle from a Naftiko-governed call.
Pandium Connector Calls
pandium-connector-calls
Proxy a typed connector call through Pandium's tenant credential broker — agents reach downstream APIs without ever holding the OAuth tokens.
Pandium Tenant Metadata
pandium-tenant-metadata
Read and update per-tenant metadata so Naftiko Fleet can decorate tenants with cost-center labels, owners, and provenance fields.
Pandium Onboarding Bridge
pandium-onboarding-bridge
Composite onboarding capability — provisions a new Pandium tenant, pushes initial metadata, and triggers the first sync in a single Naftiko-governed call.
Pandium Integration Catalog Mirror
pandium-integration-catalog-mirror
Mirror Pandium's 200+ integration catalog into Naftiko Fleet discovery — every Pandium integration becomes addressable from Backstage and apis.io.
Pandium Runs Health Monitor
pandium-runs-health-monitor
Walk every Pandium tenant and surface failed or stale runs so Naftiko's OTel + Prometheus pipeline can emit governance events on top of Pandium's run observability.
Pandium Connector Spec Bridge
pandium-connector-spec-bridge
Spec-driven bridge that turns Pandium's generic connector-call proxy into a Naftiko-governed REST + MCP capability — agents reach Salesforce, HubSpot, NetSuite via Pandium-managed credentials, governed by Naftiko spec.
Pandium Fleet Tenant Registry
pandium-fleet-tenant-registry
Pull every Pandium tenant + metadata into Naftiko Fleet's customer/cost-center registry — tenants become first-class Fleet entities visible in Backstage, Kubecost, and OPA policies.
