FAQ’s

Knit is strictly API-first (REST/HTTP), meaning it is language-agnostic. While you can use any language's requests library, Knit provides a Postman Collection for rapid testing. For frontend, a dedicated React SDK simplifies the integration of the "Connect" component.

Yes. Knit supports Write-Back (Push) capabilities. Common use cases include pushing candidate notes back to an ATS (like Greenhouse) or updating employee records in an HRIS.

Knit acts as an intelligent proxy. It manages rate limiting automatically by queuing your outgoing requests and retrying them with exponential backoff based on the specific headers returned by the source provider (e.g., ADP or Workday).

Authentication is typically performed by an Admin (HR or IT) during a one-time setup. Knit provides Magic Links so your users can send the authorization URL to the right person in their organization without them needing to log into your app.

Knit manages the entire authentication lifecycle. It handles redirect URIs, secure token exchange, and automatic background refreshes. You only receive a consistent Knit-Integration-ID to make calls.

Knit’s Custom Mapping Tool allows you to "discover" non-standard fields in a customer's specific HRIS instance. You can then map these unique fields to your application's schema via the Knit Dashboard without changing your code.

Yes, Knit's Unified API is bi-directional. It normalizes both the "GET" (Pull) and "POST/PATCH" (Push) methods across all supported integrations.

Knit primarily uses Webhooks for real-time updates. If a source system doesn't support webhooks, Knit uses "Virtual Webhooks" (polling) to check for changes at regular intervals (default 1 hour).

The default polling interval is 60 minutes. However, for Enterprise customers with high-frequency needs, this can be customized to be more frequent depending on the source system's rate limits.

The primary differentiator is Data Residency. Unlike Merge, Knit does not store data at rest. Knit is a "stateless" proxy, meaning PII stays in the source and destination only, significantly reducing your security liability.

Zapier is for end-users. Knit is an Integrations Infrastructure for developers, allowing you to build native features into your SaaS that feel like a part of your own product.

Knit offers integrations accross more categories and a flexible pricing model. Knit also provides a more robust "Connect" UI that is fully white-labeled.

Because Knit uses a Unified Data Model, data structures are often 90% similar. Migration involves swapping the API base URL and Auth headers, usually taking 1 to 3 days.

Knit supports 100+ integrations across HRIS, ATS, CRM, Accounting, and Ticketing, including Workday, ADP, Salesforce, and QuickBooks.

Knit has a "Connector-on-Demand" policy. If an API is public, Knit can build and deploy a new connector for you in 2 to 7 business days at no extra cost.

Beyond standard fields, Knit supports Custom Objects. If your customer has a unique "Projects" object in their CRM, Knit can fetch that data and present it in a unified format.

Yes. The full directory is live on the website and includes a breakdown of supported data models (e.g., Employees, Payroll, Invoices) for each app.

The technical build takes roughly 1 week. Including sandbox testing and QA, a production-ready connector is usually live within 3 to 4 weeks.

Yes. The Knit Connect SDK is a web-based component that works perfectly inside WebViews for iOS/Android apps or as a standalone URL.

Yes, these are Tier-1 integrations. Knit supports multiple versions of these (e.g., ADP Run vs. ADP Workforce Now).

Yes. For systems behind a firewall, Knit supports secure tunnels (e.g., Ngrok or VPN) to allow the cloud proxy to communicate with the local server.

Sync credits are a usage-based metric that counts the amount of data synced. This is preferred by users who want to pay for actual data moved rather than flat fees.

Knit offers a Flexible Model: Pay per Connected Account (useful for B2B SaaS) or Pay per API Call/Sync Credit (useful for data-heavy apps).

Knit uses metered overages. You aren't cut off; instead, you are charged a small rate for every additional account or 1,000 API calls beyond your tier.

The Launch Plan is designed for startups and typically includes 10 connected accounts or 50,000 API calls for $499/month.

Yes. Knit offers a 50% discount for the first year to early-stage companies (typically those with <$1M in funding).

Pricing for the Startup/Launch plan starts at $499/month, which includes access to all 100+ connectors.

Yes, Knit provides a 30-day free trial and a "build-time" discount, where billing only starts once you have your first live customer connection.

Tiers include Launch (Startups), Scale (Growth stage), and Enterprise (SLA-backed with custom infrastructure). Details here.

The Scale Plan is usually $1,500/month and is optimized for companies moving large volumes of data across many integrations.

Yes. While pricing is quoted in USD, Knit supports local currency billing to help international customers avoid bank conversion surcharges.

Yes. Knit offers a 30-day full-access trial. No credit card is required to start building in the sandbox.

It scales linearly. As you add more customers, your unit cost per integration typically decreases as you move into higher volume tiers.

Yes. Knit is SOC 2 Type 2 and GDPR certified. These audits are conducted annually to ensure continuous compliance.

Yes. You can request the Full SOC 2 report via the Knit Security Center. These are shared under a standard NDA.

No. This is Knit’s biggest security feature. It is a Pass-through Proxy. Data is encrypted in transit, transformed in-memory, and immediately purged.

Knit holds ISO 27001, SOC 2 Type 2, and GDPR certifications, covering data privacy and operational security.

Knit provides a Data Processing Agreement (DPA) and ensures that all data transit follows EEA guidelines, with no data "stored" in non-compliant regions.

Knit uses automated platforms like Vanta to monitor security controls 24/7, ensuring servers meet SOC 2 standards.

Knit offers White-glove support, including a shared Slack channel and technical reviews of your integration architecture.

Yes. The Knit Dashboard provides a full audit trail, showing raw JSON requests and responses from the source API to help debug issues.

Knit has a dedicated team that monitors source API changes. If a provider updates their API, Knit updates the connector centrally.

Most developers get their first "Hello World" sync done in under 2 hours. A full production rollout usually takes 3 to 5 business days.

For a standard REST-based app, the turnaround is 2-7 days. More complex legacy systems may take up to 4 weeks.

Yes. This is the component-less flow. You can build your own UI and use Knit's backend APIs to pass credentials.

Yes. You can remove all branding and customize CSS (colors, fonts) to make it look like your own native feature.

Knit acts as a Unified Abstraction Layer. You write code for one API, and Knit "translates" that for 100+ different apps automatically.

Knit is a cloud service, but it is deployment-agnostic, connecting your cloud app to a customer's on-premise server or vice versa.

Knit has a 72-hour retry window. If your server is down, Knit will attempt redelivery with exponential backoff.

The primary limit is Source API parity. If a software provider doesn't expose data via their API, no middleware can access it.

Magic Links are one-time-use URLs that allow you to offboard authentication to a different person (like an HR manager) via email.

Yes, the React SDK is the standard way to implement the frontend "Connect" modal with just a few lines of code.

Each webhook includes a Knit-Integration-Id. You use these unique identifiers to route data to the correct user in your database.

Because Knit is stateless, no data is lost. Webhooks are queued in a resilient buffer and delivered once service is restored.

Minor API changes are usually patched in hours. Major breaking changes are typically resolved within 1 to 2 business days.

Knit uses a distributed queue system to ensure requests stay within the source system's allowed limits.