This evaluation was written by Knit. We have tried to write it the way we'd want to read one - specific technical claims, real pricing with the constraints named, and honest guidance on when a competitor is the better fit. Read it accordingly.
The one architectural decision that defines Knit's evaluation
Knit does not cache or store any of your customers' data at the API layer - not as a compliance option, not as a configurable data residency setting, but as the architecture. Every data request is a live proxy call to the source application, normalized in transit, returned directly to yours. Every evaluation question in this article traces back to that decision.
For teams where the tradeoff lands favorably - compliance-sensitive deployments, AI-native products, regulated industries, enterprise deals where subprocessor lists matter — Knit is a strong fit. For use cases where serving from a local cache is required for performance, it is not.
Does Knit store my customers' data?
Knit does not cache or store any customer data at the API layer. When your application makes a data request, Knit executes five steps in sequence:
- Receives the normalized API request from your application
- Looks up the customer's credentials in Knit's encrypted credential store
- Authenticates with the source application (Workday, QuickBooks, Salesforce, or whichever)
- Fetches the record via a live API call
- Normalizes the response against Knit's unified schema and returns it directly
The data never touches Knit's storage layer. The credential store holds auth tokens - not business records. Employee profiles, financial transactions, candidate data, and HR documents pass through Knit as a proxy.
The compliance implication: Knit does not appear on your subprocessor list for application data. GDPR data residency assessments for the records themselves don't scope Knit's database. Enterprise security questionnaires that ask "who holds copies of our employee data?" don't implicate Knit's infrastructure for the data - only for the auth layer.
The engineering tradeoff: Live API calls have real latency. A cached query from a local database returns in single-digit milliseconds. A live proxy call to the source API typically adds 20ms to 200 ms depending on the platform's response time. For read-heavy dashboards where sub-second response is required, this matters and should be load-tested. For webhook-triggered workflows, write operations, and event-driven pipelines, the latency is immaterial.
This is the central engineering decision in any Knit evaluation.
What integrations does Knit support?
Knit's Unified API covers 160+ applications across 13 categories. For each category, all applications expose the same normalized schema - your application calls one endpoint and receives consistent field names and data structure regardless of which platform the customer is connected to.
HRIS and Payroll: Workday, BambooHR, Rippling, ADP, Gusto, Deel, Personio — employee profiles, payroll, org chart, time-off, benefits
ATS: Greenhouse, Lever, Ashby, Workable, iCIMS — jobs, candidates, applications, interview stages, offers
CRM: Salesforce, HubSpot, Pipedrive, Zoho CRM — contacts, companies, deals, pipeline, notes, activities
Accounting: QuickBooks Online, Xero, Sage, Oracle NetSuite, FreshBooks — invoices, expenses, P&L, balance sheet, transactions
Ticketing: Jira, Linear, Zendesk, GitHub Issues, Asana — tickets, projects, comments, status, assignees
Additional categories: Calendar, Communication (Slack, Teams), Email (Gmail, Outlook), E-Sign (DocuSign, HelloSign), Expense Management (Ramp, Brex, Expensify), Meeting (Zoom, Fireflies), Subscription Management (Stripe, Chargebee). The list of integrations keeps getting additions every week - for an updated list of all integrations supported view the list here
All integrations are bidirectional - reads and writes flow through the same normalized API layer. New connector requests are fulfilled in approximately 2 days per consistent G2 review feedback.
The sync frequency constraint: At the Start Up tier ($499/month), sync frequency is fixed at 24 hours. This is sufficient for daily reporting, employee onboarding / offboarding syncs, periodic reconciliation, and data enrichment workflows. It is not sufficient for any use case where a lag of up to 24 hours is unacceptable. Those use cases require Scale Up, which is custom-priced.
What is Knit's MCP Hub and how does it work?
Knit's MCP Hub provides 100+ managed Model Context Protocol servers across 14+ integration categories, with Knit handling OAuth, token refresh, and infrastructure operations so teams building AI agents don't run their own MCP server layer.
The architecture challenge that MCP Hub addresses is not the MCP protocol itself - the protocol implementation is well-documented and not the hard part. The hard part is operating the auth layer that sits between an AI agent and enterprise applications. Consider what a single tool call to retrieve employee data from Workday requires: a valid OAuth token for that specific customer's Workday instance, with the appropriate scopes, that hasn't expired, and won't expire mid-session. Multiply that across hundreds of customer tenants, each on potentially different HRIS platforms, each with their own token lifecycle. The engineering surface area for managing credentials at that scale is substantial.
Knit's MCP Hub centralizes that auth management. Your AI agent authenticates with Knit once. Knit holds and manages credentials for every downstream application across every connected customer tenant - token rotation, OAuth re-authorization prompts, rate limit backoff, and uptime monitoring all happen at the Knit layer. If a customer's Workday token expires, Knit initiates the refresh flow rather than surfacing a raw auth error to your application. The MCP server infrastructure runs on Knit's managed infrastructure; there is no server to provision, scale, or monitor.
Pre-built tool calls cover common data access patterns: get_employee, list_open_positions, get_invoices_by_date_range, search_tickets_by_assignee. An AI agent querying an HR chatbot, a recruiting copilot reviewing top candidates, or a financial analysis agent pulling quarterly data can wire these queries to pre-built tools rather than building integration middleware.
Knit's zero-storage architecture applies to MCP responses - tool call results are proxied in real time, not served from a cache.
Availability: Free at the Launch tier (5 servers, no credit card required). Unlimited servers from Individual tier ($29/month) onward.
What is Knit's AI Integrations Agent?
Knit's AI Integrations Agent builds connectors to any application - including applications outside Knit's catalog - and runs multi-step integration workflows on Knit's managed infrastructure end to end.
Every unified API platform has a catalog problem: the catalog covers mainstream applications well and fails at the tail. A B2B SaaS product whose customer base includes some share of customers on regional payroll providers, niche vertical ERPs, or custom internal systems will find that any fixed catalog solves the mainstream case and creates a separate engineering problem for the rest.
The AI Integrations Agent addresses the tail in three phases:
Build: If the required connector is part of the existing catalog then this get skipped, if a connector isn't supported - given an OpenAPI spec, Postman collection, or documentation URL, the agent maps the source platform's endpoints the schema required for your workflow - handling authentication flows, pagination patterns, field translation, and error handling. A team that needs to integrate with a regional payroll provider not in any unified API catalog doesn't need to write custom connector code. The agent builds it and wires it into Knit's infrastructure.
Wire: Multi-step workflows across multiple applications can be composed and run through the agent. A concrete example: when an employee is terminated in the HRIS, the workflow can automatically revoke their SSO access, deactivate their email, remove them from Slack, archive their CRM contacts, and notify the finance system of their final payroll date - all as a single orchestrated workflow with Knit managing the sequence, error handling, and retry logic rather than your application code.
Run: Resulting connectors and workflows execute on Knit's managed infrastructure with the same reliability guarantees as Knit's standard connectors.
Limitations with the agent: The AI Integrations Agent is newer than the Unified API and performs most reliably against applications with well-documented, stable public APIs. Closed APIs, poorly-documented endpoints, or aggressively rate-limited platforms require more validation during a proof of concept. Teams with very complex edge-case requirements should test these specifically before going live.
What does Knit cost?
Knit publishes its pricing publicly, which is not universal among unified API platforms.
The evaluation fork that matters: Start Up unlocks the full connector catalog and works well for teams adding integrations where daily sync is acceptable. Scale Up is required for faster sync cadence, whitelabel auth flows, and extended log retention. Enterprise adds the full compliance-friendly feature set - multi-region deployment, SAML SSO, and a dedicated account manager.
The Launch tier is a real starting point: no credit card, immediate access to test MCP Hub integration, and enough API calls to validate the architecture before any procurement conversation.
What compliance certifications does Knit hold?
Knit holds SOC 2 Type II and ISO 27001 certifications. GDPR compliance is supported with data processing agreements for EU deployments. Encryption is AES-256 at rest, TLS 1.3 in transit, with double encryption applied to PII and user credentials.
What Knit does not hold: Knit is not HIPAA certified yet.
The zero-storage architecture provides a compliance property that certifications don't fully express: because Knit does not retain customer data, compliance audits for data residency, retention schedules, and breach notification for the data itself do not need to scope Knit's storage. Knit is in scope for the authentication and proxy layer - the "did the vendor have access to the data?" answer is yes; the "did the vendor store the data?" answer is no. In practice, this distinction materially simplifies enterprise security questionnaires and the annual subprocessor review conversation with enterprise customers.
Full security documentation is at getknit.dev/security.
Who should use Knit?
Knit is the right evaluation when one or more of three conditions are present: integration requirements span multiple SaaS categories (HRIS plus ATS, or CRM plus accounting, or any multi-category pattern common in B2B SaaS), compliance scope of third-party data storage is a recurring friction point in enterprise deals, and the product roadmap includes AI agent workflows where MCP server connectivity or workflow orchestration matters.
The zero-storage architecture resolves a specific problem cleanly: the question "who has copies of our employee data?" has a shorter answer when Knit is the integration layer. That answer matters in enterprise security reviews, in regulated industries, and in products where data sovereignty is part of the value proposition to customers.
