The latest on API integrations - all in one place

Thanks for joining our newsletter.

Oops! Something went wrong while submitting the form.

ATS Integration : An In-Depth Guide With Key Concepts And Best Practices

Insights

Apr 3, 2026

ATS Integration : An In-Depth Guide With Key Concepts And Best Practices

Popular Blogs

All the hot and popular Knit API resources

Tutorials

Feb 2, 2026

Deep-Dive Developer Guide to Building a Sage 200 API Integration

Sage 200 is a comprehensive business management solution designed for medium-sized enterprises, offering strong accounting, CRM, supply chain management, and business intelligence capabilities. Its API ecosystem enables developers to automate critical business operations, synchronize data across systems, and build custom applications that extend Sage 200's functionality.

The Sage 200 API provides a structured, secure framework for integrating with external applications, supporting everything from basic data synchronization to complex workflow automation.

In this blog, you'll learn how to integrate with the Sage 200 API, from initial setup, authentication, to practical implementation strategies and best practices.

What Sage 200 Does

Sage 200 serves as the operational backbone for growing businesses, providing end-to-end visibility and control over business processes.

Function	Description
Financial Management	Comprehensive accounting, including ledgers, budgets, and financial reporting.
Inventory & Supply Chain	Stock control, procurement, order processing, and warehouse management.
Customer Relationship Management	Sales pipeline management, customer service, and marketing automation.
Business Intelligence	Real-time dashboards, analytics, and performance reporting.
Project Management	Job costing, resource allocation, and project tracking.
Manufacturing & Production	Bill of materials, production planning, and quality control.

Why Sage 200 Matters to Organizations

Sage 200 has become essential for medium-sized enterprises seeking integrated business management by providing a unified platform that connects all operational areas, enabling data-driven decision-making and streamlined processes.

1. Integrated Business Operations

Sage 200 breaks down departmental silos by connecting finance, sales, inventory, and operations into a single system. This integration eliminates duplicate data entry, reduces errors, and provides a 360-degree view of business performance.

2. Scalable Architecture

Designed for growing businesses, Sage 200 scales with organizational needs, supporting multiple companies, currencies, and locations. Its modular structure allows businesses to start with core financials and add capabilities as they expand.

3. Real-Time Business Intelligence

With built-in analytics and customizable dashboards, Sage 200 provides immediate insights into key performance indicators, cash flow, inventory levels, and customer behavior, empowering timely business decisions.

4. Regulatory Compliance

Sage 200 includes features for tax compliance, audit trails, and financial reporting standards, helping businesses meet regulatory requirements across different jurisdictions and industries.

5. Customization and Extensibility

Through its API and development tools, Sage 200 can be tailored to specific industry needs and integrated with specialized applications, providing flexibility without compromising core functionality.

Important Terminology for Sage 200 API

Before integrating with the Sage 200 API, it's important to understand key concepts that define how data access and communication work within the Sage ecosystem.

Company Database: Each Sage 200 company represents a separate business entity with its own financial data, customers, suppliers, and settings. API connections typically target specific company databases.
Web Services: Sage 200 exposes functionality through SOAP and REST web services, providing programmatic access to business objects and data.
OData Protocol: Sage 200 uses the OData (Open Data Protocol) standard for RESTful APIs, enabling querying and manipulation of data using standard HTTP methods.
Authentication Tokens: Security tokens obtained through Sage 200's authentication service, required for all API requests to verify permissions.
Business Objects: Sage 200's object-oriented architecture, where business entities (like Sales Orders, Invoices, Customers) are exposed as objects with properties and methods.
Integration Keys: Unique identifiers used to link records between Sage 200 and external systems, maintaining referential integrity during synchronization.
Batch Processing: Sage 200 supports batch operations for high-volume data transfers, allowing multiple records to be created or updated in a single API call.
Webhook Subscriptions: Event notifications that can be configured to alert external systems when specific changes occur in Sage 200.

Sage 200 API Integration Use Cases

The Sage 200 API enables businesses to connect their ERP system with e-commerce platforms, CRM systems, payment gateways, and custom applications. These integrations automate workflows, improve data accuracy, and create seamless operational experiences.

Below are some of the most impactful Sage 200 integration scenarios and how they can transform your business processes.

1. E-commerce Order Processing Automation

Online retailers using platforms like Shopify, Magento, or WooCommerce need to synchronize orders, inventory, and customer data with their ERP system. By integrating your e-commerce platform with Sage 200 API, orders can flow automatically into Sage for processing, fulfillment, and accounting.

How It Works:

When a customer places an order online, the integration creates a Sales Order in Sage 200 via the /SalesOrders endpoint.
Inventory levels are automatically updated, and stock reservations are made to prevent overselling.
Once dispatched, the Sales Order is converted to an Invoice, and inventory is adjusted
Payment status is synchronized back to the e-commerce platform

2. CRM and Sales Pipeline Integration

Sales teams using CRM systems like Salesforce or Microsoft Dynamics need access to customer financial data, order history, and credit limits. Integrating CRM with Sage 200 ensures sales representatives have complete customer visibility.

How It Works:

Customer records are synchronized bi-directionally between CRM and Sage 200.
When opportunities are won in CRM, they automatically create Sales Orders in Sage 200.
Credit checks are performed in real-time using Sage 200's customer credit data.
Order status and invoice details are visible within the CRM interface.

3. Supply Chain and Vendor Management

Manufacturing and distribution companies need to coordinate with suppliers through procurement portals or vendor management systems. Sage 200 API integration automates purchase order creation, goods receipt, and supplier payment processes.

How It Works:

Inventory levels trigger automatic purchase requisitions in Sage 200.
Purchase Orders are created and sent to suppliers via integrated procurement platforms.
Goods receipt updates inventory and creates supplier invoices automatically.
Three-way matching (PO, receipt, invoice) is automated for faster payment processing.

4. Financial Consolidation and Reporting

Organizations with multiple subsidiaries or complex group structures need consolidated financial reporting. Sage 200 API enables automated data extraction for consolidation tools and business intelligence platforms.

How It Works:

Financial data is extracted from multiple Sage 200 company databases.
Data is transformed and loaded into consolidation or BI tools like Power BI, Tableau, or Excel.
Real-time dashboards show consolidated P&L, balance sheets, and cash flow.
Intercompany transactions are automatically reconciled.

5. Mobile Sales and Field Service Applications

Field sales and service teams need mobile access to customer data, inventory availability, and order processing capabilities. Sage 200 API powers mobile applications for on-the-go business operations.

How It Works:

Mobile apps authenticate with Sage 200 to access customer and product data.
Sales representatives can check stock availability, create orders, and process payments in the field.
Service technicians can view customer history, log service calls, and create invoices.
All transactions sync back to Sage 200 when connectivity is available.

6. Automated Bank Reconciliation

Financial teams spend significant time matching bank transactions with accounting entries. Integrating banking platforms with Sage 200 automates this process, improving accuracy and efficiency.

How It Works:

Bank statements are imported daily via banking APIs or file uploads.
Transactions are automatically matched with invoices, bills, and journal entries in Sage 200.
Unmatched transactions are flagged for review with intelligent suggestions.
Reconciliation reports are generated automatically.

Sage 200 API Architecture and Design Principles

SOAP and REST Services: Sage 200 provides both SOAP-based web services for comprehensive business logic and RESTful OData services for simpler data access scenarios.
OData Standard: REST APIs follow the OData v4 protocol, supporting filtering, sorting, paging, and projection through query parameters.
Service-Oriented Architecture: Business functionality is exposed as discrete services, allowing targeted integration without affecting the entire system.
Batch Operations: Support for batch requests to minimize round-trip and improve performance for bulk data operations.
Metadata Service: Rich metadata describes available entities, properties, and relationships, enabling dynamic client applications.
Concurrency Control: Optimistic concurrency control via ETags prevents conflicting updates to the same resource.
Comprehensive Error Handling: Detailed error responses with codes, messages, and remediation guidance.
Audit Trail Integration: All API operations can be configured to maintain audit trails for compliance and troubleshooting.
Explore complete architectural details in the official Sage 200 API Documentation.

Secure Authentication with Sage 200 API

Sage 200 API uses token-based authentication to secure access to business data:

User Credentials: Traditional authentication using Sage 200 username and password, suitable for server-to-server integration.
OAuth 2.0: Modern authentication for web and mobile applications, allowing delegated access without sharing credentials.
API Keys: Simplified authentication for specific integration scenarios, though less secure than OAuth.
Role-Based Permissions: Access control based on Sage 200 user roles ensures API consumers only access permitted data and functions.
Token Lifetime Management: Automatic token refresh mechanisms maintain sessions without manual intervention.
IP Restriction: Optional IP whitelisting adds security layer for production environments.

Implementation examples and detailed configuration are available in the Sage 200 Authentication Guide.

Authenticating to Sage 200 API

Before making API requests, you need to obtain authentication credentials. Sage 200 supports multiple authentication methods depending on your deployment (cloud or on-premise) and integration requirements.

For Sage 200 Cloud:

Step 1: Register your application in the Sage Developer Portal. Create a new application and note your Client ID and Client Secret.

Step 2: Configure OAuth 2.0 redirect URIs and requested scopes based on the data your application needs to access.

Step 3: Implement the OAuth 2.0 authorization code flow:

Redirect users to the Sage authorization endpoint
Exchange authorization code for access token
Include token in Authorization header: Bearer {access_token}

Step 4: Refresh tokens automatically before expiry to maintain seamless access.

For Sage 200 On-Premise:

Step 1: Enable web services in the Sage 200 system administration and configure appropriate security settings.

Step 2: Use basic authentication or Windows authentication, depending on your security configuration:

Authorization: Basic {base64_encoded_credentials}

Step 3: For SOAP services, configure WS-Security headers as required by your deployment.

Step 4: Test connectivity using Sage 200's built-in web service test pages before proceeding with custom development.

Detailed authentication guides are available in the Sage 200 Authentication Documentation.

Step-by-Step: Building a Sage 200 API Integration

IIntegrating with the Sage 200 API may seem complex at first, but breaking the process into clear steps makes it much easier. This guide walks you through everything from registering your application to deploying it in production. It focuses mainly on Sage 200 Standard (cloud), which uses OAuth 2.0 and has the API enabled by default, with notes included for Sage 200 Professional (on-premise or hosted) where applicable.

Step 1: Registering Your Application and Obtaining Client Credentials

Before making any API calls, you need to register your application with Sage to get a Client ID (and Client Secret for web/server applications).

Step 1: Submit the official Sage 200 Client ID and Client Secret Request Form.

Provide your Sage account details (or request a developer account if needed).
Include application name, description, type (Web/Confidential for server apps, or Desktop/Mobile/Public for client-side apps), redirect URIs (must be HTTPS; localhost allowed for testing as https://127.0.0.1:<port>/callback), and desired refresh token expiry (up to 90 days).
Specify if you need Development or Production credentials (start with Development).

Step 2: Sage will process your request (typically within 72 hours) and email you the Client ID and Client Secret (for confidential clients).

Step 3: Store these credentials securely, never expose the Client Secret in client-side code.

For Sage 200 Standard: No additional site setup needed; the API is enabled by default for users with Sage ID.
For Sage 200 Professional: Additional server configuration may be required (e.g., enabling Native API or Windows Authentication). Refer to Sage's setup guides via your Business Partner.

✅ At this stage, you have the credentials needed for authentication.

Step 2: Setting Up OAuth 2.0 Authentication

Sage 200 uses OAuth 2.0 Authorization Code Flow with Sage ID for secure, token-based access.

Steps to Implement the Flow:

1. Redirect User to Authorization Endpoint (Ask for Permission):

GET https://id.sage.com/authorize?
audience=s200ukipd/sage200&
client_id={YOUR_CLIENT_ID}&
response_type=code&
redirect_uri={YOUR_REDIRECT_URI}&
scope=openid%20profile%20email%20offline_access&
state={RANDOM_STATE_STRING}

state: Recommended for CSRF protection (random string; verify on return).

2. User logs in with their Sage ID and consents to access.

3. Sage redirects back to your redirect_uri with a code:

{YOUR_REDIRECT_URI}?code={AUTHORIZATION_CODE}&state={YOUR_STATE}

Verify the state matches to prevent attacks.

4. Exchange Code for Tokens:

POST https://id.sage.com/oauth/token
Content-Type: application/x-www-form-urlencoded

client_id={YOUR_CLIENT_ID}
&client_secret={YOUR_CLIENT_SECRET}  // Only for confidential clients
&redirect_uri={YOUR_REDIRECT_URI}
&code={AUTHORIZATION_CODE}
&grant_type=authorization_code

Response includes access_token (expires in ~8 hours), refresh_token (up to 90 days), and other details.

5. Refresh Token When Needed:

POST https://id.sage.com/oauth/token
Content-Type: application/x-www-form-urlencoded
client_id={YOUR_CLIENT_ID}
&client_secret={YOUR_CLIENT_SECRET}
&refresh_token={YOUR_REFRESH_TOKEN}
&grant_type=refresh_token

Gets a new access_token (no new refresh token issued).

Step 3: Discovering Sites and Companies

Sage 200 organizes data by sites and companies. You need their IDs for most requests.

Steps:

1. Call the sites endpoint (no X-Site/X-Company headers needed here):

Standard: GET https://api.columbus.sage.com/uk/sage200/accounts/v1/sites
Professional: GET https://api.columbus.sage.com/uk/sage200extra/accounts/v1/sites

Headers:

Authorization: Bearer {ACCESS_TOKEN}
Content-Type: application/json

2. Response lists available sites with site_id, site_name, company_id, etc. Note the ones you need.

Step 4: Understanding the API Architecture (REST and OData)

Sage 200 API is fully RESTful with OData v4 support for querying.

Key Features:

Base URLs:
- Standard: https://api.columbus.sage.com/uk/sage200/accounts/v1/
- Professional: https://api.columbus.sage.com/uk/sage200extra/accounts/v1/
HTTP Methods: GET (read), POST (create), PUT (update), DELETE (delete).
OData Queries: Use $filter, $select, $top, $skip, $orderby, $expand for efficient data retrieval.
Common Categories: Cash Book, Financials, Purchases, Sales, SOP (Sales Orders), Stock, etc.

No SOAP Support in Current API - It's all modern REST/JSON.

Step 5: Building Your Integration (with Examples)

All requests require:

Authorization: Bearer {ACCESS_TOKEN}
X-Site: {SITE_ID}
X-Company: {COMPANY_ID}
Content-Type: application/json

Use Case 1: Fetching Customers (GET)

GET https://api.columbus.sage.com/uk/sage200/accounts/v1/customers?$top=10

Response Example (Partial):

[
  {
    "id": 27828,
    "reference": "ABS001",
    "name": "ABS Garages Ltd",
    "balance": 2464.16,
    ...
  }
]

Use Case 2: Creating a Customer (POST)

POST https://api.columbus.sage.com/uk/sage200/accounts/v1/customers
Body:
{
  "reference": "NEW001",
  "name": "New Customer Ltd",
  "short_name": "NEW001",
  "credit_limit": 5000.00,
  ...
}

Success: Returns 201 Created with the new customer object.

Step 6: Testing Your Integration

1. Use Development Credentials from your registration.

2. Test with a demo or non-production site (request via your Sage partner if needed).

3. Tools:

Postman: Import Sage collections for quick tests.
Sage API Test Tool: Verify site access.
Sample apps from the developer portal (C# solutions).

4. Test scenarios: Create/read/update/delete key entities (customers, orders), error handling, token refresh.

5. Monitor responses for errors (e.g., 401 for invalid token).

Sage 200 API Best Practices

Building reliable Sage 200 integrations requires understanding platform capabilities and limitations. Following these best practices ensures optimal performance and maintainability.

Managing Data Volume and Performance

Sage 200 APIs have practical limits on data volume per request. For large data transfers:

Use pagination with $top and $skip query parameters
Implement batch operations for creating/updating multiple records
Schedule large syncs during off-peak hours
Use delta queries to fetch only changed records since the last sync

Handling Errors and Retries

Implement robust error handling:

Check HTTP status codes and parse error responses
Implement exponential backoff for rate limit errors (429)
Maintain idempotency for retried operations
Log errors with sufficient context for troubleshooting

Maintaining Data Integrity

Ensure data consistency between systems:

Use integration keys to maintain record relationships
Implement reconciliation processes to identify and resolve discrepancies
Validate data before submission using Sage 200's validation rules
Maintain audit trails of all integration activities

Security Considerations

Protect sensitive business data:

Never store credentials in client-side code
Use the least-privilege principle for API permissions
Implement input validation to prevent injection attacks
Encrypt sensitive data in transit and at rest
Regularly rotate authentication tokens and review access logs

Optimizing for Real-Time vs Batch Processing

Choose the right approach for each integration scenario:

Use webhooks or event-driven patterns for real-time requirements
Implement scheduled batch processing for large data volumes
Consider hybrid approaches with real-time for critical operations and batch for background syncs

How Knit Simplifies Sage 200 Integration

Integrating directly with Sage 200 API requires handling complex authentication, data mapping, error handling, and ongoing maintenance. Knit simplifies this by providing a unified integration platform that connects your application to Sage 200 and dozens of other business systems through a single, standardized API.

One Unified API for Sage 200 and Other ERP Systems

Instead of writing separate integration code for each ERP system (Sage 200, SAP Business One, Microsoft Dynamics, NetSuite), Knit provides a single Unified ERP API. Your application connects once to Knit and can instantly work with multiple ERP systems without additional development.

Knit automatically handles the differences between systems—different authentication methods, data models, API conventions, and business rules—so you don't have to.

Simplified Authentication and Connection Management

Sage 200 authentication varies by deployment (cloud vs. on-premise) and requires ongoing token management. Knit's pre-built Sage 200 connector handles all authentication complexities:

OAuth 2.0 flows for Sage 200 Cloud
Basic/Windows authentication for on-premise deployments
Automatic token refresh and reconnection
Secure credential storage with enterprise-grade encryption

Your application interacts with a simple, consistent authentication API regardless of the underlying Sage 200 configuration.

Automatic Data Normalization Across Systems

Every ERP system has different data models. Sage 200's customer structure differs from SAP's, which differs from NetSuite's. Knit solves this with a Unified Data Model that normalizes data across all supported systems.

When you fetch customers from Sage 200 through Knit, they're automatically transformed into a consistent schema. When you create an order, Knit transforms it from the unified model into Sage 200's specific format. This eliminates the need for custom mapping logic for each integration.

Real-Time Sync with Event-Driven Architecture

Polling Sage 200 for changes is inefficient and can impact system performance. Knit provides real-time webhooks that notify your application immediately when data changes in Sage 200:

New orders created
Inventory levels updated
Invoices posted
Customer information changed

This event-driven approach ensures your application always has the latest data without constant polling.

Reduced Development Time and Maintenance

Building and maintaining a direct Sage 200 integration typically takes months of development and ongoing maintenance. With Knit, you can build a complete integration in days:

Pre-built connectors with comprehensive test coverage
SDKs for popular programming languages
Sandbox environments for testing
Detailed documentation and example code
Automatic updates when Sage 200 changes its API

Your team can focus on core product functionality instead of integration maintenance.

Sage 200 API Integration FAQs

Q. What versions of Sage 200 are supported by the API?

A. Sage 200 provides API support for both cloud and on-premise versions. The cloud API is generally more feature-rich and follows standard REST/OData patterns. On-premise versions may have limitations based on the specific release.

Q. Does Sage 200 API support webhooks for real-time notifications?

A. Yes, Sage 200 supports webhooks for certain events, particularly in cloud deployments. You can subscribe to notifications for created, updated, or deleted records. Configuration is done through the Sage 200 administration interface or API. Not all object types support webhooks, so check the specific documentation for your requirements.

Q. What are the rate limits for Sage 200 API?

A. Sage 200 Cloud enforces API rate limits to ensure system stability:

100 requests per minute per company
10,000 requests per day per company
5 concurrent requests maximum

On-premise deployments may have different limits based on server capacity and configuration. Implement retry logic with exponential backoff to handle rate limit responses gracefully.

Q. Can I test the API without a live Sage 200 system?

A. Yes, Sage provides several options for testing:

Sandbox Environment: Available for Sage 200 Cloud with sample data
Demo Companies: Pre-configured demo data in both cloud and on-premise versions
Developer Trial: Free trial of Sage 200 Cloud, specifically for development
Mock Services: Local mock services for development and testing without a live connection

Q. How do I handle errors and troubleshoot integration issues?

A. Sage 200 APIs provide detailed error responses, including:

HTTP status codes (400, 401, 403, 404, 429, 500, etc.)
Error codes specific to Sage 200 business logic
Descriptive messages with troubleshooting guidance
Correlation IDs for support investigations

Enable detailed logging in your integration code and monitor both application logs and Sage 200's audit trails for comprehensive troubleshooting.

Q. What programming languages are supported for Sage 200 integration?

A. You can use any programming language that supports HTTP requests and JSON parsing. Sage provides SDKs and examples for:

C# .NET (most comprehensive)
JavaScript/Node.js
Python
Java

Community-contributed libraries may be available for other languages. The REST/OData API ensures broad language compatibility.

Q. How do I handle large data volumes or batch operations?

A. For large data operations:

Use OData query options ($top, $skip) for pagination
Implement the $batch endpoint for multiple operations in one request
Use asynchronous processing for long-running operations
Consider incremental sync patterns rather than full data dumps
Schedule large operations during off-peak hours

Q. Where can I get support for Sage 200 API development?

A. Multiple support channels are available:

Official Documentation: developer.sage.com/200
Developer Forums: Community support and discussions
Sage Partner Network: Certified partners with integration expertise
Professional Services: Sage consulting for complex implementations
GitHub Repositories: Sample code and community contributions

Tutorials

Jun 20, 2026

Deep-Dive Developer Guide to Building a Jira API Integration

Jira is one of those tools that quietly powers the backbone of how teams work—whether you're NASA tracking space-bound bugs or a startup shipping sprints on Mondays. Over 300,000 companies use it to keep projects on track, and it’s not hard to see why.

This guide is meant to help you get started with Jira’s API—especially if you’re looking to automate tasks, sync systems, or just make your project workflows smoother. Whether you're exploring an integration for the first time or looking to go deeper with use cases, we’ve tried to keep things simple, practical, and relevant.

Understanding the Jira API

At its core, Jira is a powerful tool for tracking issues and managing projects. The Jira API takes that one step further—it opens up everything under the hood so your systems can talk to Jira automatically.

Think of it as giving your app the ability to create tickets, update statuses, pull reports, and tweak workflows—without anyone needing to click around. Whether you're building an integration from scratch or syncing data across tools, the API is how you do it.

It’s well-documented, RESTful, and gives you access to all the key stuff: issues, projects, boards, users, workflows—you name it.

Why Integrate with Jira?

Chances are, your customers are already using Jira to manage bugs, tasks, or product sprints. By integrating with it, you let them:

Create and update tickets automatically
Keep data in sync across tools
Build dashboards that show real-time project health

It’s a win-win. Your users save time by avoiding duplicate work, and your app becomes a more valuable part of their workflow. Plus, once you set up the integration, you open the door to a ton of automation—like auto-updating statuses, triggering alerts, or even creating tasks based on events from your product.

Foundational Jira Concepts for Developers

Before you dive into the API calls, it's helpful to understand how Jira is structured. Here are some basics:

Issues: These are the core units—bugs, tasks, features, etc.
Projects: A collection of issues under one umbrella (e.g., a product or team).
Boards: Visual tools for managing issues, especially in agile workflows.
Workflows: The path an issue takes from "To Do" to "Done."
Schemes: Settings that define permissions, notifications, and more.

Visual representation of the Jira API data models and their relationships

Each of these maps to specific API endpoints. Knowing how they relate helps you design cleaner, more effective integrations.

Preparing Your Development Space

1. Prerequisites

To start building with the Jira API, here’s what you’ll want to have set up:

A language you’re comfortable with (Node.js, Python, Java, etc.)
An HTTP client like Postman or curl for testing
Version control (Git)
Your favorite IDE or code editor

If you're using Jira Cloud, you're working with the latest API. If you're on Jira Server/Data Center, there might be a few quirks and legacy differences to account for.

2. Setting Up a Jira Test Environment (Highly Recommended)

Before you point anything at production, set up a test instance of Jira Cloud. It’s free to try and gives you a safe place to break things while you build.

You can:

Spin up a trial via Atlassian’s website
Use default settings to mimic real-world use
Invite teammates for collaborative testing

Testing in a sandbox means fewer headaches down the line—especially when things go wrong (and they sometimes will).

Getting Started with the Jira API: The Basics

1. Navigating API Documentation

The official Jira API documentation is your best friend when starting an integration. It's hosted by Atlassian and offers granular details on endpoints, request/response bodies, and error messages. Use the interactive API explorer and bookmark sections such as Authentication, Issues, and Projects to make your development process efficient.

2. Authentication and Security

Jira supports several different ways to authenticate API requests. Let’s break them down quickly so you can choose what fits your setup.

A. Basic Authentication (Deprecated)

Basic authentication is now deprecated but may still be used for legacy systems. It consists of passing a username and password with every request. While easy, it does not have strong security features, hence the phasing out.

B. OAuth 1.0 (Deprecated)

OAuth 1.0a has been replaced by more secure protocols. It was previously used for authorization but is now phased out due to security concerns.

C. Utilizing API Tokens (Recommended)

For most modern Jira Cloud integrations, API tokens are your best bet. Here’s how you use them:

Head to your Atlassian account and generate a token.
Use basic auth with your email and the token instead of a password.

For the full walkthrough - scoped vs. un-scoped tokens, the cloud id routing quirk, and a working curl example - see Knit's guide on how to get a Jira API token.

It’s simple, secure, and works well for most use cases.

D. OAuth 2.0 (3LO)

If your app needs to access Jira on behalf of users (with their permission), you’ll want to go with 3-legged OAuth. You’ll:

Set up an app on Atlassian Developer Console
Get the user’s consent via a browser flow
Use the token you receive to make authenticated API calls

It’s a bit more work upfront, but it gives you scoped, permissioned access.

E. Forge & Connect Apps

If you're building apps *inside* the Atlassian ecosystem, you'll either use:

OAuth 2.0 via Forge (for apps built on Atlassian’s new cloud dev platform)
JWT (for legacy Connect apps)

Both offer deeper integrations and more control, but require additional setup.

3. Permissions & Rules

Whichever method you use, make sure:

Your user/token has the right permissions (some endpoints need admin access)
You handle errors gracefully (403s usually mean you’re missing access)
You’re storing tokens securely (env vars, secret managers, etc.)

A lot of issues during integration come down to misconfigured auth—so double-check before you start debugging the code.

Managing Issues Using the Jira API

Once you're authenticated, one of the first things you’ll want to do is start interacting with Jira issues. Here’s how to handle the basics: create, read, update, delete (aka CRUD).

1. Creating Issues

To create a new issue, you’ll need to call the `POST /rest/api/3/issue` endpoint with a few required fields:

{
"fields": {
"project": { "key": "PROJ" },
"issuetype": { "name": "Bug" },
"summary": "Something’s broken!",
"description": "Details about the bug go here."
}
}

At a minimum, you need the project key, issue type, and summary. The rest—like description, labels, and custom fields—are optional but useful.
Make sure to log the responses so you can debug if anything fails. And yes, retry logic helps if you hit rate limits or flaky network issues.

2. Reading Issues

To fetch an issue, use a GET request:

GET /rest/api/3/issue/{issueIdOrKey}

You’ll get back a JSON object with all the juicy details: summary, description, status, assignee, comments, history, etc.
It’s pretty handy if you’re syncing with another system or building a custom dashboard.

3. Updating Issues

Need to update an issue’s status, add a comment, or change the priority? Use PUT for full updates or PATCH for partial ones.
A common use case is adding a comment:
{
"body": "Following up on this issue—any updates?"
}
Make sure to avoid overwriting fields unintentionally. Always double-check what you're sending in the payload.

4. Deleting Issues (Use with Caution!)

Deleting issues is irreversible. Only do it if you're absolutely sure—and always ensure your API token has the right permissions.

It’s best practice to:
Confirm the issue should be deleted (maybe with a soft-delete flag first)
Keep an audit trail somewhere. Handle deletion errors gracefully

5. Searching for Issues with JQL

Jira comes with a powerful query language called JQL (Jira Query Language) that lets you search for precise issues.

Want all open bugs assigned to a specific user? Or tasks due this week? JQL can help with that.

Example: project = PROJ AND status = "In Progress" AND assignee = currentUser()

When using the search API, don't forget to paginate. Note that Atlassian has moved this to a new endpoint: POST /rest/api/3/search/jql, which returns a nextPageToken instead of using startAt/maxResults. Pass the token back on your next request until it's empty. (The older GET /rest/api/3/search endpoint shown in some docs is being phased out - see Knit's Jira API guide for the current request shape.)

This helps when you're dealing with hundreds (or thousands) of issues.

Managing Projects, Boards, and Workflows

1. Project Management via the API

The API also allows you to create and manage Jira projects. This is especially useful for automating new customer onboarding.
Use the `POST /rest/api/3/project` endpoint to create a new project, and pass in details like the project key, name, lead, and template.
You can also update project settings and connect them to workflows, issue type schemes, and permission schemes.

2. Agile Management: Boards and Sprints (Agile API)

If your customers use Jira for agile, you’ll want to work with boards and sprints.
Here’s what you can do with the API:
- Fetch boards (`GET /board`)
- Retrieve or create sprints
- Move issues between sprints
It helps sync sprint timelines or mirror status in an external dashboard.

3. Workflow Interactions via the API

Jira Workflows define how an issue moves through statuses. You can:
- Get available transitions (`GET /issue/{key}/transitions`)
- Perform a transition (`POST /issue/{key}/transitions`)
This lets you automate common flows like moving an issue to "In Review" after a pull request is merged.

Advanced Features and Webhooks

1. Leveraging Advanced Jira API Features

Jira’s API has some nice extras that help you build smarter, more responsive integrations.

2. Establishing Links Between Issues

You can link related issues (like blockers or duplicates) via the API. Handy for tracking dependencies or duplicate reports across teams.
Example:

{
"type": { "name": "Blocks" },
"inwardIssue": { "key": "PROJ-101" },
"outwardIssue": { "key": "PROJ-102" }
}

Always validate the link type you're using and make sure it fits your project config.

3. Establishing Links Between Issues

Need to upload logs, screenshots, or files? Use the attachments endpoint with a multipart/form-data request.

Just remember:

Respect file size limits
Watch out for unsupported types
Secure file handling matters if you’re building a public-facing app

‍

4. Implementing Event-Driven Integrations with Webhooks

Want your app to react instantly when something changes in Jira? Webhooks are the way to go.

You can subscribe to events like issue creation, status changes, or comments. When triggered, Jira sends a JSON payload to your endpoint.

Make sure to:

Validate incoming payloads
Log and retry failed deliveries
Secure your endpoint (rate limits + auth)

5. Key Differences Between Jira Cloud and Jira Server

Understanding the differences between Jira Cloud and Jira Server is critical:

Endpoints: Some endpoints differ in URL and available features.
Version-Specific Features: Jira Cloud often has newer features not available in Server.
Limitations: Be aware of any restrictions that may affect your integration.

Keep updated with the latest changes by monitoring Atlassian’s release notes and documentation.

Error Handling, Rate Limits, and Performance

Even with the best setup, things can (and will) go wrong. Here’s how to prepare for it.

1. Common Error Codes

Jira’s API gives back standard HTTP response codes. Some you’ll run into often:

400 Bad Request: Usually a missing field or invalid format. Double-check your payload.
401 Unauthorized: Your token might be missing or incorrect.
403 Forbidden: You’re authenticated, but don’t have permission to do the thing.
404 Not Found: The issue/project/resource doesn’t exist.
429 Too Many Requests: You hit a rate limit. Time to back off and retry later.
500 Internal Server Error: Something broke on Jira’s side. Try again with a delay.

Always log error responses with enough context (request, response body, endpoint) to debug quickly.

2. Handling Rate Limiting and API Throttling

Jira Cloud rate-limits requests through a few overlapping systems: a points-based hourly quota (a default Global Pool of 65,000 points/hour for most apps), burst limits of 100 requests/second for GET/POST and 50/second for PUT/DELETE, and a per-issue write cap (around 20 requests in 2 seconds). A 429 response includes a RateLimit-Reason header telling you which limit you hit. Here's how to handle it safely:

‍

Watch for `429` status codes
Check headers like `X-Rate-limit-Remaining` if available
Use exponential backoff to retry: e.g., wait 1s, 2s, 4s, etc.
Avoid sending bursts of traffic—spread out API calls where possible

If you’re building a high-throughput integration, test with realistic volumes and plan for throttling.

3. Strategies for Performance Enhancement

To make your integration fast and reliable:

Use JQL wisely: Don’t pull every issue—fetch only what you need.
Paginate properly: Jira caps results. Always check `startAt` and `maxResults`.
Batch requests: If possible, group changes to reduce roundtrips.
Cache where safe: For static metadata (like field definitions), caching improves speed.
Async processing: Don’t make users wait—trigger long processes in the background.

These small tweaks go a long way in keeping your integration snappy and stable.

Logging, Debugging, and Testing

Getting visibility into your integration is just as important as writing the code. Here's how to keep things observable and testable.

1. Best Practices for Logging API Interactions

Solid logging = easier debugging. Here's what to keep in mind:

Structure your logs: Use a consistent format (JSON works great for parsing).
Log requests/responses: Especially when working with external APIs.
Redact sensitive data: Mask things like API tokens before logging.
Trace IDs: Use correlation IDs to trace a flow across systems.

If something breaks, good logs can save hours of head-scratching.

2. Approaches to Debugging Common Integration Issues

When you’re trying to figure out what’s going wrong:

Postman: Great for testing individual API calls.
curl: Quick and flexible for command-line requests.
Request logs: Look at the exact payloads being sent/received.
Jira UI: Check if what you're doing via API reflects in the frontend.

Also, if your app has logs tied to user sessions or sync jobs, make those searchable by ID.

3. Incorporating Automated Testing

Testing your Jira integration shouldn’t be an afterthought. It keeps things reliable and easy to update.

Unit tests: Mock the API and validate your logic.
Integration tests: Run tests against a test Jira instance.
CI/CD: Plug your tests into your pipeline to catch regressions early.

The goal is to have confidence in every deploy—not to ship and pray.

Real-World Use Cases (Code Samples)

Let’s look at a few examples of what’s possible when you put it all together:

1. Auto-Creating Jira Tickets from Your App

Trigger issue creation when a bug or support request is reported:

curl --request POST \
  --url 'https://your-domain.atlassian.net/rest/api/3/issue' \
  --user 'email@example.com:<api_token>' \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --data '{
    "fields": {
      "project": { "key": "PROJ" },
      "issuetype": { "name": "Bug" },
      "summary": "Bug in production",
      "description": "A detailed bug report goes here."
    }
  }'

2. Syncing Two Project Management Tools

Read issue data from Jira and sync it to another tool:

bash
curl -u email@example.com:API_TOKEN -X GET \ https://your-domain.atlassian.net/rest/api/3/issue/PROJ-123

Map fields like title, status, and priority, and push updates as needed.

3. Auto-Transitioning Overdue Tasks

Use a scheduled script to move overdue tasks to a "Stuck" column:

```python
import requests
import json
jira_domain = "https://your-domain.atlassian.net"
api_token = "API_TOKEN"
email = "email@example.com"
headers = {"Content-Type": "application/json"}
# Find overdue issues
jql = "project = PROJ AND due < now() AND status != 'Done'"
response = requests.get(f"{jira_domain}/rest/api/3/search", 
                        headers=headers, 
                        auth=(email, api_token), 
                        params={"jql": jql})
for issue in response.json().get("issues", []):
    issue_key = issue["key"]
    payload = {"transition": {"id": "31"}}  # Replace with correct transition ID
    requests.post(f"{jira_domain}/rest/api/3/issue/{issue_key}/transitions",
                  headers=headers, 
                  auth=(email, api_token), 
                  data=json.dumps(payload))
```

Automations like this can help keep boards clean and accurate.

Keeping Your Jira Integration Secure

Security's key, so let's keep it simple:

1. Handle Secrets Right

Think of API keys like passwords.

Env Vars: Store them there, not in your code.
Encryption: For keepsies, encrypt them.
Rotate: Change them regularly.

Secure secrets = less risk.

2. User Data - Be Smart

If you touch user data:

Compliance: Know the rules (GDPR, etc.).
Retention: Don't keep it forever.
Access: Only those who need it see it.

Making Your Jira Integration Better

Quick tips to level up:

1. Client Libraries - Maybe?

Libraries (Java, Python, etc.) can help with the basics.

Good for: Quick setup, common tasks.
Less good for: Full control.

Your call is based on your needs.

2. CI/CD is Your Friend

Automate testing and deployment.

Test often: Catch issues early.
Deploy smoothly: Less manual work.
Monitor: Keep an eye on things.

Reliable integration = happy you.

Conclusion and Final Checklist

If you’ve made it this far—nice work! You’ve got everything you need to build a powerful, reliable Jira integration. Whether you're syncing data, triggering workflows, or pulling reports, the Jira API opens up a ton of possibilities.

Here’s a quick checklist to recap:

✅ Before You Start

Choose between Jira Cloud or Server/Data Center.
Set up a sandbox/test environment.
Pick your preferred auth method (API token, OAuth, etc).

🛠️ While Building

Use the right endpoints for issues, projects, boards, and workflows.
Test API calls in Postman or curl.
Log requests and responses (without leaking sensitive data).
Handle common errors and rate limits
Optimize with pagination, batching, and caching

🚀 Before Shipping

Write automated tests (unit + integration).
Monitor logs for failures or edge cases.
Document your field mappings and logic.
Validate your webhook setup if used.

Keep Exploring

Jira is constantly evolving, and so are the use cases around it. If you want to go further:

- Follow [Atlassian’s Developer Changelog]
- Explore the [Jira API Docs]
- Join the [Atlassian Developer Community]

And if you're building on top of Knit, we’re always here to help.

Drop us an email at hello@getknit.dev if you run into a use case that isn’t covered.

Happy building! 🙌

Tutorials

May 7, 2026

Sage Intacct API Integration Guide: REST, XML & Auth (2026)

Introduction to Sage Intacct API

Sage Intacct API integration allows businesses to connect financial systems with other applications, enabling real-time data synchronization and reducing errors and missed opportunities. Manual data transfers and outdated processes can lead to errors and missed opportunities. This guide explains how Sage Intacct API integration removes those pain points. We cover the technical setup, common issues, and how using Knit can cut down development time while ensuring a secure connection between your systems and Sage Intacct.

Overview of Sage Intacct API Integration

Sage Intacct API integration integrates your financial and ERP systems with third-party applications. It connects your financial information and tools used for reporting, budgeting, and analytics.

What is Sage Intacct API integration?
It allows two or more software systems to share data seamlessly. This connection reduces manual entries and synchronizes data across platforms.
The role of APIs in modern ERP and financial management:
APIs facilitate real-time data exchange and perform repetitive tasks automatically. They are the foundation of contemporary software systems as they make sure each component is current.
Why seamless integration matters for your business:
A reliable API integration cuts down on errors, saves time, and provides access to real-time insights that help in strategic planning.

Overview of Sage Intacct API Documentation

The Sage Intacct API documentation provides all the necessary information to integrate your systems with Sage Intacct’s financial services. It covers two main API protocols: REST and SOAP, each designed for different integration needs. REST is commonly used for web-based applications, offering a simple and flexible approach, while SOAP is preferred for more complex and secure transactions.

By following the guidelines, you can ensure a secure and efficient connection between your systems and Sage Intacct.

Key Features Included:

API Types: REST (simpler, web-based) and SOAP (robust, secure).
Endpoint Structure: Learn how to interact with functions like invoicing, reporting, and customer management.
API Usage Limits: Understand the traffic limits to avoid throttling.
Authentication: Detailed methods for secure API access.
Best Practices: Recommendations to optimize your integration.

Business and Technical Benefits of Sage Intacct API

Integrating Sage Intacct with your existing systems offers a host of advantages.

Real-time synchronization of financial data: Stay in sync with the newest financial records as they occur.
Automation of repetitive financial tasks: Avoid manual data entry and minimize the chances of errors.
Improved reporting, compliance, and analytics: Facilitate better decision-making by bringing together timely, accurate data.
Scalability and improved operational efficiency: Easily adjust to growing data loads without sacrificing performance.

Steps for Building a Sage Intacct API Integration

Before you start the integration process, you should properly set up your environment. Proper setup creates a solid foundation and prevents most pitfalls.

STEP 1: Setting up a Sage Intacct tenant and obtaining API endpoint

A clear understanding of Sage Intacct’s account types and ecosystem is vital.

Sage Intacct account types (Demo vs. Production):
- Demo Account: Use this for testing and proof-of-concept projects. It mimics the production environment.
- Production Account: This account handles live data and transactions.
Developer Registration:
Before you can start using the API, you must register as a developer with Sage Intacct. To do this:

Sign up on the Sage Intacct Developer portal.
Request your Sender ID, User ID, and Company ID, which are required for authentication.

Understanding the Sage Intacct ecosystem and access tiers:
Know the differences between various access tiers. Each tier has specific permissions and usage limits.
Reviewing Sage Intacct API usage limits and guidelines:
Get familiar with the API limits to prevent throttling during heavy traffic. Always refer to the latest guidelines in the official documentation.

STEP 2: Establishing a Secure Development Environment

A secure environment protects your data and credentials.

Benefits of using a sandbox environment:
Test your integration without affecting live data. A sandbox replicates your production environment safely.
Steps to create and configure a Sage Intacct sandbox:
- Sign up for a demo account.
- Follow the setup wizard to configure your sandbox.
- Test all functions thoroughly before moving to production.
Best practices for data anonymization and security:
- Use dummy data for testing.
- Ensure API credentials are stored securely.
- Limit access to the development environment.

STEP 3: Enabling API Access and Setting Up Authentication

Setting up authentication is crucial to secure the data flow.

Configuring API permissions and roles:
Assign roles based on the principle of least privilege. Only allow necessary permissions to each user.
Overview of available authentication methods:
- Web Services Authentication: Uses XML-based requests.
- OAuth 2.0: Offers secure token-based authentication.
Generating and managing API credentials:
Follow official documentation to create and store API keys or tokens securely.
Troubleshooting common authentication challenges:
- Check API endpoint URLs.
- Ensure your credentials are correct.
- Monitor logs for errors and consult Sage Intacct support if needed.

STEP 4: Sage Intacct API Options: SOAP(Legacy) vs REST

An understanding of the different APIs and protocols is necessary to choose the best method for your integration needs.

API Architecture and Protocols

Sage Intacct offers a flexible API ecosystem to fit diverse business needs.

Overview of Sage Intacct’s API ecosystem:
Sage Intacct provides multiple API protocols to interact with its services. You have choices depending on your technical preference.
REST vs. SOAP: Which fits your use case?
- REST: Simpler, uses JSON, and is widely used for modern web applications.
- SOAP: More robust, relies on XML, and can be better for strict enterprise requirements.
Understanding key endpoints and services:
Look for endpoints that map to critical business functions such as invoicing, customer management, and reporting.

Sage Intacct REST API Overview

The Sage Intacct REST API offers a clean, modern approach to integrating with Sage Intacct.

Introduction to the RESTful API framework:
REST APIs use standard HTTP methods. They are easy to implement and scale well.
Common REST endpoints and their functionalities:
- GET: Retrieve data.
- POST: Create new records.
- PUT: Update existing records.
- DELETE: Remove records.
Example of GET API:

Note (2025): Sage Intacct has designated the XML API as legacy. All new objects and features are now released via the REST API only. The XML API remains supported for existing integrations, but new builds should use the REST API. See developer.intacct.com for the current migration guidance.

Get a Bank Account

Curl request:

curl -i -X GET \ 'https://api.intacct.com/ia/api/v1/objects/cash-management/bank-acount {key}' \-H 'Authorization: Bearer <YOUR_TOKEN_HERE>'

‍Here’s a detailed reference to all the Sage Intacct REST API Endpoints.

Sage Intacct SOAP API Overview

For environments that need robust enterprise-level integration, the Sage Intacct SOAP API is a strong option.

Introduction to the SOAP API environment:
SOAP uses XML for its messages. It enforces strict rules on message structure.
Working with WSDL, XML requests, and responses:
Developers use a WSDL file to understand available methods. Your XML requests must adhere to the schema defined.
Example:

Each operation is a simple HTTP request. For example, a GET request to retrieve account details:

Parameters for request body:

<read>
    <object>GLACCOUNT</object>
    <keys>1</keys>
    <fields>*</fields>
</read>

Data format for the response body:

xml (default)
json
Csv

Here’s a detailed reference to all the Sage Intacct SOAP API Endpoints.

Comparing SOAP versus REST for various scenarios:

SOAP: Better for complex transactions and when high security is required.
REST: Preferred for lighter, web-based interactions.

Additional Integration Options

Beyond the primary REST and SOAP APIs, Sage Intacct provides other modules to enhance integration.

Overview of other available modules and scripting capabilities:
Use custom scripts to automate tasks not covered by standard endpoints.
Custom scripting and automation possibilities with Sage Intacct:
Developers can extend functionalities using server-side scripts and connectors. Refer to the official scripting guides for more details.

STEP 5: Building Your Sage Intacct API Integration (With Examples)

Now that your environment is ready and you understand the API options, you can start building your integration.

Making Your First API Call

A basic API call is the foundation of your integration.

Step-by-step guide for a basic API call using REST and SOAP:

REST Example:

Set up your environment.
Authenticate using your API token.
Send a GET request to a sample endpoint say list a customer.

Example:

Curl Request:

curl -i -X GET \
https://api.intacct.com/ia/api/v1/objects/accounts-receivable/customer \
-H 'Authorization: Bearer <YOUR_TOKEN_HERE>'
Response 200 (Success):
{
  "ia::result": [
    {
      "key": "68",
      "id": "CUST-100",
      "href": "/objects/accounts-receivable/customer/68"
    },
    {
      "key": "69",
      "id": "CUST-200",
      "href": "/objects/accounts-receivable/customer/69"
    },
    {
      "key": "73",
      "id": "CUST-300",
      "href": "/objects/accounts-receivable/customer/73"
    }
  ],
  "ia::meta": {
    "totalCount": 3,
    "start": 1,
    "pageSize": 100
  }
}
Response 400 (Failure):
{
  "ia::result": {
    "ia::error": {
      "code": "invalidRequest",
      "message": "A POST request requires a payload",
      "errorId": "REST-1028",
      "additionalInfo": {
        "messageId": "IA.REQUEST_REQUIRES_A_PAYLOAD",
        "placeholders": {
          "OPERATION": "POST"
        },
        "propertySet": {}
      },
      "supportId": "Kxi78%7EZuyXBDEGVHD2UmO1phYXDQAAAAo"
    }
  },
  "ia::meta": {
    "totalCount": 1,
    "totalSuccess": 0,
    "totalError": 1
  }
}

‍

SOAP(Legacy) Example:

Set up your WSDL-based client.
Create an XML request as per the schema.
Send the request and process the XML response:

Name	Required	Type	Description
REPORTINGPERIOD	Required	Object	Object to create

‍

Example snippet of creating a reporting period:

<create>
    <REPORTINGPERIOD>
        <NAME>Month Ended January 2017</NAME>
        <HEADER1>Month Ended</HEADER1>
        <HEADER2>January 2017</HEADER2>
        <START_DATE>01/01/2017</START_DATE>
        <END_DATE>01/31/2017</END_DATE>
        <BUDGETING>true</BUDGETING>
        <STATUS>active</STATUS>
    </REPORTINGPERIOD>
</create>

Setting up your development environment and authentication:
Ensure that you follow best practices for API key storage. Use environment variables or secure vaults.
Interpreting API responses and error handling:
Check status codes and error messages. A 200 status code indicates success, while a 400 or 500 series indicates issues.

Postman Usage

Using Postman for Testing and Debugging API Calls

Postman is a good tool for sending and confirming API requests before implementation to make the testing of your Sage Intacct API integration more efficient.

You can import the Sage Intacct Postman collection into your Postman tool, which has pre-configured endpoints for simple testing. You can use it to simply test your API calls, see results in real time, and debug any issues.

This helps in debugging by visualizing responses and simplifying the identification of errors.

Mapping Business Processes to API Workflows

Mapping your business processes to API workflows makes integration smoother.

Automating invoice generation and payment processing:
Use API calls to trigger invoice creation and payment confirmation.
- Define the data flow from order entry to invoice output.
- Use error-handling routines to catch exceptions during processing.
Synchronizing customer and vendor data across platforms:
Maintain a consistent view of your contacts by syncing updates in real time.
- Map fields between your CRM and Sage Intacct.
- Schedule regular sync jobs to update records.
Integrating financial reporting and analytics tools:
Pull data into BI tools to generate live reports.
- Use data batching and pagination to manage large volumes.
- Implement caching strategies to reduce load on the API endpoints.

To test your Sage Intacct API integration, using Postman is recommended. You can import the Sage Intacct Postman collection and quickly make sample API requests to verify functionality. This allows for efficient testing before you begin full implementation.

Real-World Integration Scenarios and Case Studies

Understanding real-world applications helps in visualizing the benefits of a well-implemented integration.

Use Cases Across Industries

This section outlines examples from various sectors that have seen success with Sage Intacct integrations.

Examples of successful Sage Intacct integrations:
- Skydance:
  Skydance integrated Sage Intacct to synchronize their financial and production data. This automation improved invoice processing and provided real-time visibility into project budgets.
- XML International:
  XML International leveraged the API to streamline vendor management and reporting. Their integration automated data reconciliation processes, reducing manual intervention and cutting processing time significantly.
How various sectors benefit from integration:
- Retail:
  Integrate point-of-sale systems to update inventory and sales records in real time.
- Manufacturing:
  Connect production management with financial reporting to track costs and resource allocation efficiently.
- Services:
  Sync project-based billing systems with financial records for improved cash flow management.

Industry‍

Industry	Key Integration Benefit	Example Use Case
Retail	Real-time sales and inventory updates	Synchronize point-of-sale data
Manufacturing	Production cost tracking and resource planning	Integrate ERP with production systems
Services	Project-based billing and cash flow management	Connect project management with finance

‍

Sage Intacct Partnership Program

Joining a sage intacct partnership program can offer additional resources and support for your integration efforts.

Overview of the Partnership Program

The partnership program enhances your integration by offering technical and marketing support.

Key benefits and strategic features:
- Access to exclusive technical resources.
- Early access to new API features and updates.
- Co-marketing opportunities that boost your market presence.
How the partnership enhances integration and drives business growth:
- Streamlined support for resolving technical issues.
- Training and certification programs for your team.
- Joint ventures to expand your market reach.

Partnership Levels and Opportunities

Different partnership tiers cater to varied business needs.

Description of partnership tiers:
- Authorized Partner: Basic support and access to essential resources.
- Premium Partner: Enhanced support, training, and co-marketing initiatives.
Exclusive benefits for partners:
- Priority technical support.
- Dedicated account management.
- Invitations to exclusive events and webinars.

Best Practices for Sage Intacct API Integration

Following best practices ensures that your integration runs smoothly over time.

Optimizing Performance and Scalability

Manage API calls effectively to handle growth.

Managing API rate limits and avoiding throttling:
- Use batching and pagination to limit the number of requests.
  - Sage Intacct Performance Tiers (enforced April 2025): Sage Intacct now enforces API transaction limits under a Performance Tier model. The default tier (Tier 1) allows 100,000 transactions per month. Overages are charged at $0.15 per pack of 10 transactions above the limit. A "transaction" counts each query, readByQuery, create, update, or delete call — query results are capped at 2,000 per call, so large datasets require multiple queries, each counting separately. Monitor your usage at Company → Admin → Usage Insights → API Usage. Higher tiers are available for additional fees — contact your Sage Intacct Customer Success Manager. Knit manages transaction volume automatically, batching requests and staying within tier limits to avoid unexpected overage charges.
- Monitor usage and adjust call frequencies as needed.
Efficient data retrieval:
- Apply caching strategies for frequently accessed data.
- Use pagination to handle large data sets.
Tips for scaling your integration:
- Regularly review API performance metrics.
- Consider load-balancing solutions for high-traffic periods.

Securing Your API Environment

Security must remain a top priority.

Safeguarding API credentials and data:
- Store credentials in secure vaults or environment variables.
- Use encryption for data in transit and at rest.
Implementing role-based access control (RBAC) and encryption protocols:
- Grant permissions based on user roles.
- Regularly update and audit access controls.

Monitoring and Logging

Effective monitoring helps catch issues early.

Set up logging: Track API calls and responses to troubleshoot errors.
Use monitoring tools: Set alerts for unusual patterns and track API health via dashboards.
Regular health checks: Schedule periodic reviews and ensure timely updates and patches to maintain security.

Troubleshooting and Support

No integration is without its challenges. This section covers common problems and how to fix them.

Common Integration Challenges

Prepare for and resolve typical issues quickly.

Authentication and connectivity issues:
- Verify credentials.
- Check network settings and firewall rules.
Handling data discrepancies and synchronization errors:
- Compare API logs with your internal records.
- Implement validation checks during data transfer.
Common API errors and their causes:
- 400-level errors often indicate bad requests.
- 500-level errors suggest server issues that may require a retry or escalation.

Debugging and Resolution Techniques

Effective troubleshooting minimizes downtime.

Troubleshooting common API errors:
- Use logging to identify where errors occur.
- Cross-reference with official documentation for error codes.
Best practices for debugging and logging:
- Implement detailed logging at every integration point.
- Use tools that automatically flag and diagnose issues.
Handling Legacy or Undocumented API Functions
- Legacy Functions: If using older functions, check for compatibility or consider upgrading to newer ones.
- Undocumented Functions: If a function is missing from the documentation, check with Sage Intacct support or the community for assistance. Always be cautious when using undocumented features, as they might not be stable or officially supported.

Maintaining and Evolving Your Integration

Long-term management of your integration is key to ongoing success.

Keeping Up with API Updates

Stay informed about changes to avoid surprises.

Monitoring Sage Intacct API version changes and release notes:
- Subscribe to the official developer portal.
- Regularly review documentation for updates.
Best practices for migrating from legacy endpoints:
- Test migration paths in your sandbox.
- Update your integration gradually to avoid disruptions.

Long-Term Integration Management

Ensure your integration remains robust as your business grows.

Regular performance audits and security assessments:
- Schedule routine audits of your integration environment.
- Use third-party tools to check security compliance.
Strategies for scaling your integration:
- Plan for increased data volume.
- Consider a microservices architecture to isolate components.
- Use cloud-based solutions for elasticity and cost efficiency.

How Knit Can Help with Sage Intacct API Integration

Knit offers a streamlined approach to integrating Sage Intacct. This section details how Knit simplifies the process.

Knit’s Role in Simplifying Integration

Knit reduces the heavy lifting in integration tasks by offering pre-built accounting connectors in its Unified Accounting API.

Overview of Knit’s features tailored for Sage Intacct:
- Provides secure, pre-configured connectors.
- Offers automated workflows that reduce manual coding.
- Continuously updates to match the latest Sage Intacct API changes.
Pre-built connectors and automated workflows:
- Instant integration with a few configuration steps.
- Dashboard for real-time monitoring and troubleshooting.

Step-by-Step Integration Using Knit

This section provides a walk-through for integrating using Knit.

Sign up for free on Knit
Complete the getting started flow
Obtain your own Sage Intacct Sandbox or Request Knit for access to our sandbox
Build and test your integration
Go-live in production!

A sample table for mapping objects and fields can be included:

Source Field	Target Field	Data Transformation
customer_id	client_reference	Direct mapping
invoice_amount	total_due	Currency conversion applied
invoice_date	transaction_date	Date format adjustment

‍

Advantages Over Manual Integration

Knit eliminates many of the hassles associated with manual integration.

Reduced development and maintenance time:
- Avoid writing repetitive code.
- Focus on business logic rather than API quirks.
Enhanced security and compliance through automation:
- Rely on updated connectors that follow best security practices.
- Regular audits and compliance checks are built into the platform.
Streamlined troubleshooting and performance optimization:
- Use built-in tools to diagnose issues.
- Leverage community support and expert guidance from Knit.

Takeaway

In this guide, we have walked you through the steps and best practices for integrating Sage Intacct via API. You have learned how to set up a secure environment, choose the right API option, map business processes, and overcome common challenges.

If you're ready to link Sage Intacct with your systems without the need for manual integration, it's time to discover how Knit can assist. Knit delivers customized, secure connectors and a simple interface that shortens development time and keeps maintenance low. Book a demo with Knit today to see firsthand how our solution addresses your integration challenges so you can focus on growing your business rather than worrying about technical roadblocks

Frequently Asked Questions

Does Sage Intacct have an API?

Yes. Sage Intacct provides two API interfaces: the REST API (recommended for all new integrations, available at api.intacct.com) and the XML API (legacy, still supported but receiving no new features). The REST API uses standard HTTP verbs and OAuth 2.0 Bearer token authentication. It covers the full financial data model — customers, vendors, invoices, bills, GL accounts, and reporting objects. Knit's Unified Accounting API normalises Sage Intacct alongside QuickBooks, NetSuite, and Xero into a consistent schema, so teams build one integration rather than one per platform.

What is the API limit for Sage Intacct?

Sage Intacct enforces API transaction limits under a Performance Tier model (enforced April 2025). The default Tier 1 allows 100,000 transactions per month. Each query, readByQuery, create, update, or delete call counts as one transaction — query results are capped at 2,000 per call, so large datasets require multiple queries. Overages are charged at $0.15 per pack of 10 transactions. Monitor usage at Company → Admin → Usage Insights → API Usage. Knit manages transaction volume automatically to avoid unexpected overage charges.

How do I authenticate with the Sage Intacct API?

The Sage Intacct REST API uses OAuth 2.0 Bearer token authentication. Register an application in the Sage Developer Portal to obtain a Client ID and Client Secret, then use the Authorization Code flow for user-delegated access. The legacy XML API uses Web Services credentials — a Sender ID, User ID, and Company ID passed in the XML request body. For new integrations, use OAuth 2.0 via the REST API. Knit handles the full OAuth flow for Sage Intacct; users authorise once and Knit manages token refresh automatically.

What is the difference between the Sage Intacct REST API and the XML API?

The REST API is Sage Intacct's current recommended interface — it uses standard HTTP verbs, JSON payloads, and OAuth 2.0 authentication. All new objects and features are released via REST only. The XML API (also called the SOAP or Web Services API) is the legacy interface — it uses XML request/response structures and Web Services credentials (Sender ID + User ID). It remains supported for existing integrations but receives no new features. New integrations should always use the REST API.

Is Sage Intacct open API?

Yes — Sage Intacct provides an openly documented API available to any developer. The REST API documentation is published at developer.sage.com and the legacy XML API reference is at developer.intacct.com. Both are accessible without special partnership status, though production access requires a Sage Intacct subscription or a developer sandbox account. Some advanced modules (multi-entity consolidation, project accounting) require the corresponding Sage Intacct subscription to access via API.

What AI features does Sage Intacct have?

Sage Intacct includes Sage Copilot, an AI assistant embedded natively in the product that proactively analyses financial data, surfaces insights, and responds to natural language queries within the application. For AI agent integrations (external tools calling Sage Intacct programmatically), the REST API provides the data layer — an external MCP server or AI agent can call Sage Intacct endpoints to retrieve invoices, GL balances, or vendor data as part of a multi-step workflow. Knit provides a unified accounting API that enables AI agents to query Sage Intacct alongside other accounting platforms through a consistent interface.

How do I get a Sage Intacct developer sandbox?

Sage Intacct provides a sandbox environment that mirrors your production account for safe testing. You can request a sandbox via the Sage Intacct Developer Portal at developer.intacct.com. If you don't have an existing Sage Intacct subscription, Sage offers a demo account at sage.com/intacct for proof-of-concept work. The sandbox uses the same API endpoints as production — note that the base URL differs slightly from production and must be configured separately in your integration. Knit might also be able provide access to a Sage Intacct sandbox for testing integrations built on the Knit platform -speak to your account manager to request for it.

‍

Insights

Apr 16, 2026

Integrations for AI Agents

In today's AI-driven world, AI agents have become transformative tools, capable of executing tasks with unparalleled speed, precision, and adaptability. From automating mundane processes to providing hyper-personalized customer experiences, these agents are reshaping the way businesses function and how users engage with technology. However, their true potential lies beyond standalone functionalities—they thrive when integrated seamlessly with diverse systems, data sources, and applications.

This integration is not merely about connectivity; it’s about enabling AI agents to access, process, and act on real-time information across complex environments. Whether pulling data from enterprise CRMs, analyzing unstructured documents, or triggering workflows in third-party platforms, integration equips AI agents to become more context-aware, action-oriented, and capable of delivering measurable value.

This article explores how seamless integrations unlock the full potential of AI agents, the best practices to ensure success, and the challenges that organizations must overcome to achieve seamless and impactful integration.

Rise of AI Agents

The rise of Artificial Intelligence (AI) agents marks a transformative shift in how we interact with technology. AI agents are intelligent software entities capable of performing tasks autonomously, mimicking human behavior, and adapting to new scenarios without explicit human intervention. From chatbots resolving customer queries to sophisticated virtual assistants managing complex workflows, these agents are becoming integral across industries.

This rise of use of AI agents has been attributed to factors like:

Advances in AI and machine learning models, and access to vast datasets which allow AI agents to understand natural language better and execute tasks more intelligently.
Demand for automating routine tasks, reducing the burden on human resources, and improving efficiency, driving operational efficiency

Understanding How AI Agents Work

AI agents are more than just software programs; they are intelligent systems capable of executing tasks autonomously by mimicking human-like reasoning, learning, and adaptability. Their functionality is built on two foundational pillars:

1) Contextual Knowledge

For optimal performance, AI agents require deep contextual understanding. This extends beyond familiarity with a product or service to include insights into customer pain points, historical interactions, and updates in knowledge. However, to equip AI agents with this contextual knowledge, it is important to provide them access to a centralized knowledge base or data lake, often scattered across multiple systems, applications, and formats. This ensures they are working with the most relevant and up-to-date information. Furthermore, they need access to all new information, such as product updates, evolving customer requirements, or changes in business processes, ensuring that their outputs remain relevant and accurate.

For instance, an AI agent assisting a sales team must have access to CRM data, historical conversations, pricing details, and product catalogs to provide actionable insights during a customer interaction.

2) Strategic Action

AI agents’ value lies not only in their ability to comprehend but also to act. For instance, AI agents can perform activities such as updating CRM records after a sales call, generating invoices, or creating tasks in project management tools based on user input or triggers. Similarly, AI agents can initiate complex workflows, such as escalating support tickets, scheduling appointments, or launching marketing campaigns. However, this requires seamless connectivity across different applications to facilitate action.

For example, an AI agent managing customer support could resolve queries by pulling answers from a knowledge base and, if necessary, escalating unresolved issues to a human representative with full context.

The capabilities of AI agents are undeniably remarkable. However, their true potential can only be realized when they seamlessly access contextual knowledge and take informed actions across a wide array of applications. This is where integrations play a pivotal role, serving as the key to bridging gaps and unlocking the full power of AI agents.

Enter Integrations: Powering AI Agents

The effectiveness of an AI agent is directly tied to its ability to access and utilize data stored across diverse platforms. This is where integrations shine, acting as conduits that connect the AI agent to the wealth of information scattered across different systems. These data sources fall into several broad categories, each contributing uniquely to the agent's capabilities:

Types of Agent Data Sources: The Foundation of AI Agent Functionality

1) Structured Data Sources

Platforms like databases, Customer Relationship Management (CRM) systems (e.g., Salesforce, HubSpot), and Enterprise Resource Planning (ERP) tools house structured data—clean, organized, and easily queryable. For example, CRM integrations allow AI agents to retrieve customer contact details, sales pipelines, and interaction histories, which they can use to personalize customer interactions or automate follow-ups.

2) Unstructured Data Sources

The majority of organizational knowledge exists in unstructured formats, such as PDFs, Word documents, emails, and collaborative platforms like Notion or Confluence. Cloud storage systems like Google Drive and Dropbox add another layer of complexity, storing files without predefined schemas. Integrating with these systems allows AI agents to extract key insights from meeting notes, onboarding manuals, or research reports. For instance, an AI assistant integrated with Google Drive could retrieve and summarize a company’s annual performance review stored in a PDF document.

3) Streaming Data Sources

Real-time data streams from IoT devices, analytics tools, or social media platforms offer actionable insights that are constantly updated. AI agents integrated with streaming data sources can monitor metrics, such as energy usage from IoT sensors or engagement rates from Twitter analytics, and make recommendations or trigger actions based on live updates.

4) Third-Party Applications

APIs from third-party services like payment gateways (Stripe, PayPal), logistics platforms (DHL, FedEx), and HR systems (BambooHR, Workday) expand the agent's ability to act across verticals. For example, an AI agent integrated with a payment gateway could automatically reconcile invoices, track payments, and even issue alerts for overdue accounts.

The Role of Data Ingestion

To process this vast array of data, AI agents rely on data ingestion—the process of collecting, aggregating, and transforming raw data into a usable format. Data ingestion pipelines ensure that the agent has access to a broad and rich understanding of the information landscape, enhancing its ability to make accurate decisions.

However, this capability requires robust integrations with a wide variety of third-party applications. Whether it's CRM systems, analytics tools, or knowledge repositories, each integration provides an additional layer of context that the agent can leverage.

Without these integrations, AI agents would be confined to static or siloed information, limiting their ability to adapt to dynamic environments. For example, an AI-powered customer service bot lacking integration with an order management system might struggle to provide real-time updates on a customer’s order status, resulting in a frustrating user experience.

The Case for Real-Time Integrations

In many applications, the true value of AI agents lies in their ability to respond with real-time or near-real-time accuracy. Integrations with webhooks and streaming APIs enable the agent to access live data updates, ensuring that its responses remain relevant and timely.

Consider a scenario where an AI-powered invoicing assistant is tasked with generating invoices based on software usage. If the agent relies on a delayed data sync, it might fail to account for a client’s excess usage in the final moments before the invoice is generated. This oversight could result in inaccurate billing, financial discrepancies, and strained customer relationships.

Why Agents Need Integrations:

1) Empowering Action Across Applications

Integrations are not merely a way to access data for AI agents; they are critical to enabling these agents to take meaningful actions on behalf of other applications. This capability is what transforms AI agents from passive data collectors into active participants in business processes.

Integrations play a crucial role in this process by connecting AI agents with different applications, enabling them to interact seamlessly and perform tasks on behalf of the user to trigger responses, updates, or actions in real time.

For instance, A customer service AI agent integrated with CRM platforms can automatically update customer records, initiate follow-up emails, and even generate reports based on the latest customer interactions. SImilarly, if a popular product is running low, the AI agent for e-commerce platform can automatically reorder from the supplier, update the website’s product page with new availability dates, and notify customers about upcoming restocks. Furthermore, A marketing AI agent integrated with CRM and marketing automation platforms (e.g., Mailchimp, ActiveCampaign) can automate email campaigns based on customer behaviors—such as opening specific emails, clicking on links, or making purchases.

Integrations allow AI agents to automate processes that span across different systems. For example, an AI agent integrated with a project management tool and a communication platform can automate task assignments based on project milestones, notify team members of updates, and adjust timelines based on real-time data from work management systems.

For developers driving these integrations, it’s essential to build robust APIs and use standardized protocols like OAuth for secure data access across each of the applications in use. They should also focus on real-time synchronization to ensure the AI agent acts on the most current data available. Proper error handling, logging, and monitoring mechanisms are critical to maintaining reliability and performance across integrations. Furthermore, as AI agents often interact with multiple platforms, developers should design integration solutions that can scale. This involves using scalable data storage solutions, optimizing data flow, and regularly testing integration performance under load.

2) Building RAG (Retrieval-Augmented Generation) pipelines

Retrieval-Augmented Generation (RAG) is a transformative approach that enhances the capabilities of AI agents by addressing a fundamental limitation of generative AI models: reliance on static, pre-trained knowledge. RAG fills this gap by providing a way for AI agents to efficiently access, interpret, and utilize information from a variety of data sources. Here’s how iintegrations help in building RAG pipelines for AI agents:

Access to Diverse Data Sources

Traditional APIs are optimized for structured data (like databases, CRMs, and spreadsheets). However, many of the most valuable insights for AI agents come from unstructured data—documents (PDFs), emails, chats, meeting notes, Notion, and more. Unstructured data often contains detailed, nuanced information that is not easily captured in structured formats.

RAG enables AI agents to access and leverage this wealth of unstructured data by integrating it into their decision-making processes. By integrating with these unstructured data sources, AI agents:

Employ Optical Character Recognition (OCR) for scanned documents and Natural Language Processing (NLP) for text extraction.
Use NLP techniques like keyword extraction, named entity recognition, sentiment analysis, and topic modeling to parse and structure the information.
Convert text into vector embeddings using models such as Word2Vec, GloVe, and BERT, which represent words and phrases as numerical vectors capturing semantic relationships between them.
Use similarity metrics (e.g., cosine similarity) to find relevant patterns and relationships between different pieces of data, allowing the AI agent to understand context even when information is fragmented or loosely connected.

Unified Retrieval Layer

RAG involves not only the retrieval of relevant data from these sources but also the generation of responses based on this data. It allows AI agents to pull in information from different platforms, consolidate it, and generate responses that are contextually relevant.

For instance, an HR AI agent might need to pull data from employee records, performance reviews, and onboarding documents to answer a question about benefits. RAG enables this agent to access the necessary context and background information from multiple sources, ensuring the response is accurate and comprehensive through a single retrieval mechanism.

Real-Time Contextual Understanding

RAG empowers AI agents by providing real-time access to updated information from across various platforms with the help of Webhooks. This is critical for applications like customer service, where responses must be based on the latest data.

For example, if a customer asks about their recent order status, the AI agent can access real-time shipping data from a logistics platform, order history from an e-commerce system, and promotional notes from a marketing database—enabling it to provide a response with the latest information. Without RAG, the agent might only be able to provide a generic answer based on static data, leading to inaccuracies and customer frustration.

Key Benefits of RAG for AI Agents

Enhanced Accuracy
By incorporating real-time information retrieval, RAG reduces the risk of hallucinations—a common issue with LLMs—ensuring responses are accurate and grounded in authoritative data sources.
Scalability Across Domains and Use Cases
With access to external knowledge repositories, AI agents equipped with RAG can seamlessly adapt to various industries, such as healthcare, finance, education, and e-commerce.
Improved User Experience
RAG-powered agents offer detailed, context-aware, and dynamic responses, elevating user satisfaction in applications like customer support, virtual assistants, and education platforms.
Cost Efficiency
By offloading the need to encode every piece of knowledge into the model itself, RAG allows smaller LLMs to perform at near-human accuracy levels, reducing computational costs.
Future-Proofing AI Systems
Continuous learning becomes effortless as new information can be integrated into the retriever without retraining the generator, making RAG an adaptable solution in fast-evolving industries.

Challenges in Implementing RAG (Retrieval-Augmented Generation)

While RAG presents immense opportunities to enhance AI capabilities, its implementation comes with a set of challenges. Addressing these challenges is crucial to building efficient, scalable, and reliable AI systems.

Latency and Performance Bottlenecks: Real-time retrieval and generation involve multiple computational steps, including embedding queries, retrieving data, and generating responses. This can introduce delays, especially when handling large-scale queries or deploying RAG on low-powered devices.some text
- Mitigation Strategies:some text
  - Approximate Nearest Neighbor (ANN) Search: Use ANN techniques in retrievers (e.g., FAISS or ScaNN) to speed up vector searches without sacrificing too much accuracy.
  - Caching Frequent Queries: Cache the most common retrieval results to bypass the retriever for repetitive queries.
  - Parallel Processing: Leverage parallelism in data retrieval and model inference to minimize bottlenecks.
  - Model Optimization: Use quantized or distilled models for faster inference during embedding generation or response synthesis.
Data Quality and Bias in Knowledge Bases: The quality and relevance of retrieved data heavily depend on the source knowledge base. If the data is outdated, incomplete, or biased, the generated responses will reflect those shortcomings.some text
- Mitigation Strategies:some text
  - Regular Data Updates: Ensure the knowledge base is periodically refreshed with the latest and most accurate information.
  - Source Validation: Use reliable, vetted sources to build the knowledge base.
  - Bias Mitigation: Perform audits to identify and correct biases in the retriever’s dataset or the generator’s output.
  - Content Moderation: Implement filters to exclude low-quality or irrelevant data during the retrieval phase.
Scalability with Large Datasets: As datasets grow in size and complexity, retrieval becomes computationally expensive. Indexing, storage, and retrieval from large-scale knowledge bases require robust infrastructure.some text
- Mitigation Strategies:some text
  - Hierarchical Retrieval: Use multi-stage retrievers where a lightweight model filters down the dataset before passing it to a heavier, more precise retriever.
  - Distributed Systems: Deploy distributed retrieval systems using frameworks like Elasticsearch clusters or AWS-managed services.
  - Efficient Indexing: Use optimized indexing techniques (e.g., HNSW) to handle large datasets efficiently.
Alignment Between Retrieval and Generation: RAG systems must align retrieved information with user intent to generate coherent and contextually relevant responses. Misalignment can lead to confusing or irrelevant outputs.some text
- Mitigation Strategies:some text
  - Query Reformulation: Preprocess user queries to align them with the retriever’s capabilities, using NLP techniques like rephrasing or entity extraction.
  - Context-Aware Generation: Incorporate structured prompts that explicitly guide the generator to focus on the retrieved context.
  - Feedback Mechanisms: Enable end-users or moderators to flag poor responses, and use this feedback to fine-tune the retriever and generator.
Handling Ambiguity in Queries: Ambiguous user queries can lead to irrelevant or incomplete retrieval, resulting in suboptimal generated responses.some text
- Mitigation Strategies:some text
  - Clarification Questions: Build mechanisms for the AI to ask follow-up questions when the user query lacks clarity.
  - Multi-Pass Retrieval: Retrieve multiple potentially relevant contexts and use the generator to combine and synthesize them.
  - Weighted Scoring: Assign higher relevance scores to retrieved documents that align more closely with query intent, using additional heuristics or context-based filters.
Integration Complexity: Seamlessly integrating retrieval systems with generative models requires significant engineering effort, especially when handling domain-specific requirements or legacy systems.some text
- Mitigation Strategies:some text
  - Frameworks and Libraries: Use existing RAG frameworks like Haystack or LangChain to reduce development complexity.
  - API Abstraction: Wrap the retriever and generator in unified APIs to simplify the integration process.
  - Microservices Architecture: Deploy retriever and generator components as independent services, allowing for modular development and easier scaling.
Using Unreliable Sources: A Key Challenge in RAG Implementation**: The effectiveness of Retrieval-Augmented Generation (RAG) depends heavily on the quality of the knowledge base. If the system relies on unreliable, biased, or non-credible sources, it can lead to the generation of inaccurate, misleading, or harmful outputs. This undermines the reliability of the AI and can damage user trust, especially in high-stakes domains like healthcare, finance, or legal services.some text
- Mitigation Strategies:some text
  - Source Vetting and Curation: Establish strict criteria for selecting sources, prioritizing those that are credible, authoritative, and up-to-date along with regular audit.
  - Trustworthiness Scoring: Assign trustworthiness scores to sources based on factors like citation frequency, domain expertise, and author credentials.
  - Multi-Source Validation: Cross-reference retrieved information against multiple trusted sources to ensure accuracy and consistency.

Steps to Build a RAG Pipeline

Define the Use Case
- Identify the specific application for your RAG pipeline, such as answering customer support queries, generating reports, or creating knowledge assistants for internal use.
Select Data Sources
- Determine the types of data your pipeline will access, including structured (databases, APIs) and unstructured (documents, emails, knowledge bases).
Choose Tools and Technologies
- Vectorization Tools: Select pre-trained models for creating text embeddings.
- Databases: Use a vector database to store and retrieve embeddings.
- Generative Models: Choose a model optimized for your domain and use case.
Develop and Deploy Retrieval Models
- Train retrieval models to handle semantic queries effectively. Focus on accuracy and relevance, balancing precision with speed.
Integrate Generative AI
- Connect the retrieval mechanism to the generative model. Ensure input prompts include the retrieved context for highly relevant outputs.
Implement Quality Assurance
- Regularly test the pipeline with varied inputs to evaluate accuracy, speed, and the relevance of responses.
- Monitor for potential biases or inaccuracies and adjust models as needed.
Optimize and Scale
- Fine-tune the pipeline based on user feedback and performance metrics.
- Scale the system to handle larger datasets or higher query volumes as needed.

Built for AI developers

The integration layer your AI agents have been waiting for.

Knit's unified API + MCP Servers give your AI agents read/write access to every major HRIS, ATS, ERP, and CRM — with a single OAuth flow and zero custom connectors to maintain.

Book a Demo Explore MCP Servers

Real-World Use Cases of integrations for AI Agents

AI-Powered Customer Support for an eCommerce Platform

Integration of an AI-powered customer service agent with CRM systems, ticketing platforms, and other tools can help enhance contextual knowledge and take proactive actions, delivering a superior customer experience.

‍

For instance, when a customer reaches out with a query—such as a delayed order—the AI agent retrieves their profile from the CRM, including past interactions, order history, and loyalty status, to gain a comprehensive understanding of their background. Simultaneously, it queries the ticketing system to identify any related past or ongoing issues and checks the order management system for real-time updates on the order status. Combining this data, the AI develops a holistic view of the situation and crafts a personalized response. It may empathize with the customer’s frustration, offer an estimated delivery timeline, provide goodwill gestures like loyalty points or discounts, and prioritize the order for expedited delivery.

‍

The AI agent also performs critical backend tasks to maintain consistency across systems. It logs the interaction details in the CRM, updating the customer’s profile with notes on the resolution and any loyalty rewards granted. The ticketing system is updated with a resolution summary, relevant tags, and any necessary escalation details. Simultaneously, the order management system reflects the updated delivery status, and insights from the resolution are fed into the knowledge base to improve responses to similar queries in the future. Furthermore, the AI captures performance metrics, such as resolution times and sentiment analysis, which are pushed into analytics tools for tracking and reporting.

Retail AI Agent with Omni-Channel Integration

In retail, AI agents can integrate with inventory management systems, customer loyalty platforms, and marketing automation tools for enhancing customer experience and operational efficiency. For instance, when a customer purchases a product online, the AI agent quickly retrieves data from the inventory management system to check stock levels. It can then update the order status in real time, ensuring that the customer is informed about the availability and expected delivery date of the product. If the product is out of stock, the AI agent can suggest alternatives that are similar in features, quality, or price, or provide an estimated restocking date to prevent customer frustration and offer a solution that meets their needs.

‍

Similarly, if a customer frequently purchases similar items, the AI might note this and suggest additional products or promotions related to these interests in future communications. By integrating with marketing automation tools, the AI agent can personalize marketing campaigns, sending targeted emails, SMS messages, or notifications with relevant offers, discounts, or recommendations based on the customer’s previous interactions and buying behaviors. The AI agent also writes back data to customer profiles within the CRM system. It logs details such as purchase history, preferences, and behavioral insights, allowing retailers to gain a deeper understanding of their customers’ shopping patterns and preferences.

Key challenges with integrations for AI agents

Integrating AI (Artificial Intelligence) and RAG (Recommendations, Actions, and Goals) frameworks into existing systems is crucial for leveraging their full potential, but it introduces significant technical challenges that organizations must navigate. These challenges span across data ingestion, system compatibility, and scalability, often requiring specialized technical solutions and ongoing management to ensure successful implementation.

Data Compatibility and Quality:

Data Fragmentation: Many organizations operate in data-rich but siloed environments, where critical information is scattered across multiple tools and platforms. For instance, customer data may reside in CRMs, operational data in ERP systems, and communication data in collaboration tools like Slack or Google Drive. These systems often store data in incompatible formats, making it difficult to consolidate into a single, accessible source. This fragmentation obstructs AI's ability to deliver actionable insights by limiting its access to the complete context required for accurate recommendations and decisions. Overcoming this challenge is particularly difficult in organizations with legacy systems or highly customized architectures.
Data Quality Issues: AI systems rely heavily on data accuracy, completeness, and consistency. Common issues such as duplicate records, missing fields, or outdated entries can severely undermine the performance of AI models. Inconsistent data formatting, such as differences in date structures, naming conventions, or measurement units across systems, can lead to misinterpretation of information by AI agents. Low-quality data not only reduces the effectiveness of AI but also erodes stakeholder confidence in the system's outputs, creating a cycle of distrust and underutilization.

Complexity of Integration:

System Compatibility: Integrating AI frameworks with existing platforms is often hindered by discrepancies in system architecture, API protocols, and data exchange standards. Enterprise systems such as CRMs, ERPs, and proprietary databases are frequently designed without interoperability in mind. These compatibility issues necessitate custom integration solutions, which can be time-consuming and resource-intensive. Additionally, the lack of standardization across APIs complicates the development process, increasing the risk of integration failures or inconsistent data flow.
Real-Time Integration: Real-time functionality is critical for AI systems that generate recommendations or perform actions dynamically. However, achieving this is particularly challenging when dealing with high-frequency data streams, such as those from IoT devices, e-commerce platforms, or customer-facing applications. Low-latency requirements demand advanced data synchronization capabilities to ensure that updates are processed and reflected instantaneously across all systems. Infrastructure limitations, such as insufficient bandwidth or outdated hardware, further exacerbate this challenge, leading to performance degradation or delayed responses.

Scalability Issues:

High Volume or Large Data Ingestion: AI integrations often require processing enormous volumes of data generated from diverse sources. These include transactional data from e-commerce platforms, behavioral data from user interactions, and operational data from business systems. Managing these data flows requires robust infrastructure capable of handling high throughput while maintaining data accuracy and integrity. The dynamic nature of data sources, with fluctuating volumes during peak usage periods, further complicates scalability, as systems must be designed to handle both expected and unexpected surges.
Third-Party Limitations and Data Loss: Many third-party systems impose rate limits on API calls, which can restrict the volume of data an AI system can access or process within a given timeframe. These limitations often lead to incomplete data ingestion or delays in synchronization, impacting the overall reliability of AI outputs. Additional risks, such as temporary outages or service disruptions from third-party providers, can result in critical data being lost or delayed, creating downstream effects on AI performance.

Building AI Actions for Automation:

API Research and Management: AI integrations require seamless interaction with third-party applications through APIs, which involves extensive research into their specifications, capabilities, and constraints. Organizations must navigate a wide variety of authentication protocols, such as OAuth 2.0 or API key-based systems, which can vary significantly in complexity and implementation requirements. Furthermore, APIs are subject to frequent updates or deprecations, which may lead to breaking changes that disrupt existing integrations and necessitate ongoing monitoring and adaptation.
Cost of Engineering Hours: Developing and maintaining AI integrations demands significant investment in engineering resources. This includes designing custom solutions, monitoring system performance, and troubleshooting issues arising from API changes or infrastructure bottlenecks. The long-term costs of managing these integrations can escalate as the complexity of the system grows, placing a strain on both technical teams and budgets. This challenge is especially pronounced in smaller organizations with limited technical expertise or resources to dedicate to such efforts.

Monitoring and Observability Gaps

Lack of Unified Dashboards: Organizations often use disparate monitoring tools that focus on specific components, such as data pipelines, model health, or API integrations. However, these tools rarely offer a comprehensive view of the overall system performance. This fragmented approach creates blind spots, making it challenging to identify interdependencies or trace the root causes of failures and inefficiencies. The absence of a single pane of glass for monitoring hinders decision-making and proactive troubleshooting.
Failure Detection: AI systems and their integrations are susceptible to several issues, such as dropped API calls, broken data pipelines, and data inconsistencies. These problems, if undetected, can escalate into critical disruptions. Without robust failure detection mechanisms—like anomaly detection, alerting systems, and automated diagnostics—such issues can remain unnoticed until they significantly impact operations, leading to downtime, loss of trust, or financial setbacks.

Versioning and Compatibility Drift

API Deprecations: Third-party providers frequently update or discontinue APIs, creating potential compatibility issues for existing integrations. For example, a CRM platform might revise its API authentication protocols, making current integration setups obsolete unless they are swiftly updated. Failure to monitor and adapt to such changes can lead to disrupted workflows, data loss, or security vulnerabilities.
Model Updates: AI models require periodic retraining and updates to improve performance, adapt to new data, or address emerging challenges. However, these updates can unintentionally introduce changes in outputs, workflows, or integration points. If not thoroughly tested and managed, such changes can disrupt established business processes, leading to inconsistencies or operational delays. Effective version control and compatibility testing are critical to mitigate these risks.

How to Add Integrations to AI Agents?

Adding integrations to AI agents involves providing these agents with the ability to seamlessly connect with external systems, APIs, or services, allowing them to access, exchange, and act on data. Here are the top ways to achieve the same:

Custom Development Approach

Custom development involves creating tailored integrations from scratch to connect the AI agent with various external systems. This method requires in-depth knowledge of APIs, data models, and custom logic. The process involves developing specific integrations to meet unique business requirements, ensuring complete control over data flows, transformations, and error handling. This approach is suitable for complex use cases where pre-built solutions may not suffice.

Pros:

Highly Tailored Solutions: Custom development allows for precise control over the integration process, enabling specific adjustments to meet unique business requirements.
Full Control: Organizations can implement specific data validation rules, security protocols, and transformations that best suit their needs.
Complex Use Cases: Custom development is ideal for complex integrations involving multiple systems or detailed workflows that existing platforms cannot support.

Cons:

Resource-Intensive: Building and maintaining custom integrations requires specialized skills in software development, APIs, and data integration.
Time Consuming: Development can take weeks to months, depending on the complexity of the integration.
Maintenance: Ongoing maintenance is required to adapt the integration to changes in APIs, business needs, or system upgrades.

Embedded iPaaS Approach

Embedded iPaaS (Integration Platform as a Service) solutions offer pre-built integration platforms that include no-code or low-code tools. These platforms allow organizations to quickly and easily set up integrations between the AI agent and various external systems without needing deep technical expertise. The integration process is simplified by using a graphical interface to configure workflows and data mappings, reducing development time and resource requirements.

Pros:

Quick Deployment: Rapid implementation thanks to the use of visual interfaces and pre-built connectors, enabling organizations to integrate systems quickly.
Scalability: Easy to adjust and scale as business requirements evolve, ensuring flexibility over time.
Reduced Costs: Lower upfront costs and less need for specialized development teams compared to custom development.

Cons:

Limited Customization: Some iPaaS solutions may not offer enough customization for complex or highly specific integration needs.
Platform Dependency: Integration capabilities are restricted by the APIs and features provided by the chosen iPaaS platform.
Recurring Fees: Subscription costs can accumulate over time, making this approach more expensive for long-term use.

Unified API Solutions (e.g., Knit)

Unified API solutions provide a single API endpoint that connects to multiple SaaS products and external systems, simplifying the integration process. This method abstracts the complexity of dealing with multiple APIs by consolidating them into a unified interface. It allows the AI agent to access a wide range of services, such as CRM systems, marketing platforms, and data analytics tools, through a seamless and standardized integration process.

Pros:

Speed: Quick deployment due to pre-built connectors and automated setup processes.
100% API Coverage: Access to a wide range of integrations with minimal setup, reducing the complexity of managing multiple API connections.
Ease of Use: Simplifies integration management through a single API, reducing overhead and maintenance needs.

How Knit AI Can Power Integrations for AI Agents

Knit offers a game-changing solution for organizations looking to integrate their AI agents with a wide variety of SaaS applications quickly and efficiently. By providing a seamless, AI-driven integration process, Knit empowers businesses to unlock the full potential of their AI agents by connecting them with the necessary tools and data sources.

Rapid Integration Deployment: Knit AI allows AI agents to deploy dozens of product integrations within minutes. This speed is achieved through a user-friendly interface where users can select the applications they wish to integrate with. If an application isn’t supported yet, Knit AI will add it within just 2 days. This ensures businesses can quickly adapt to new tools and services without waiting for extended development cycles.
100% API Coverage: With Knit AI, AI agents can access a wide range of APIs from various platforms and services through a unified API. This means that whether you’re integrating with CRM systems, marketing platforms, or custom-built applications, Knit provides complete API coverage. The AI agent can interact with these systems as if they were part of a single ecosystem, streamlining data access and management.
Custom Integration Options: Users can specify their needs—whether they want to read or write data, which data fields they need, and whether they require scheduled syncs or real-time API calls. Knit AI then builds connectors tailored to these specifications, allowing for precise control over data flows and system interactions. This customization ensures that the AI agent can perform exactly as required in real-time environments.
Testing and Validation: Before going live, users can test their integrations using Knit’s available sandboxes. These sandboxes allow for a safe environment to verify that the integration works as expected, handling edge cases and ensuring data integrity. This process minimizes the risk of errors and ensures that the integration performs optimally once it’s live.
Publish with Confidence: Once tested and validated, the integration can be published with a single click. Knit simplifies the deployment process, enabling businesses to go from development to live integration in minutes. This approach significantly reduces the friction typically associated with traditional integration methods, allowing organizations to focus on leveraging their AI capabilities without technical barriers.

By integrating with Knit, organizations can power their AI agents to interact seamlessly with a wide array of applications. This capability not only enhances productivity and operational efficiency but also allows for the creation of innovative use cases that would be difficult to achieve with manual integration processes. Knit thus transforms how businesses utilize AI agents, making it easier to harness the full power of their data across multiple platforms.

Ready to see how Knit can transform your AI agents? Contact us today for a personalized demo!

Frequently Asked Questions

What are integrations for AI agents?

Integrations for AI agents are the connections that give an AI agent access to external data sources, APIs, and tools it needs to complete tasks. An AI agent without integrations can only work with the information in its context window - it can't read a CRM record, trigger a payroll run, or pull a customer's support history. Integrations bridge the gap between the agent's reasoning capability and the real-world systems it needs to act on. Common integration types include REST APIs (for SaaS platforms like HubSpot, Salesforce, or Workday), file storage systems, databases, and event streams. For agents built on LLMs, integrations are typically exposed as tools the model can call - either through direct API connections, an embedded iPaaS, or a unified API platform like Knit.

Why do AI agents need integrations?

AI agents need integrations for two reasons: knowledge and action. For knowledge, integrations give agents access to up-to-date, customer-specific data they can't get from their training - CRM records, HR data, support tickets, financial history. For action, integrations let agents do things beyond generating text - update a record, trigger a workflow, send a message, or write to a database. Without integrations, an AI agent is a sophisticated chatbot. With integrations, it becomes a system that can perceive context across your tech stack and take meaningful actions on behalf of users.

What is MCP and how does it relate to AI agent integrations?

MCP (Model Context Protocol) is an open standard that defines how AI models connect to external tools and data sources. Rather than every agent framework implementing its own tool-calling conventions, MCP provides a standardised protocol so that any MCP-compatible agent can use any MCP server. For AI agent integrations, this means a well-built MCP server can expose your SaaS integrations (CRM, HRIS, ticketing) to any agent framework that supports MCP - without bespoke wiring for each one. Knit provides an MCP hub that you could use for MCP servers across 150+ apps that knit supports, so agents built on Claude, GPT-4o, or any MCP-compatible framework can call Knit's 100+ HRIS, payroll, and CRM integrations through a single MCP connection.

What is the best way to add integrations to an AI agent?

There are three main approaches. Custom development gives you the most control but requires building and maintaining each integration individually - practical for one or two integrations, but it doesn't scale. Embedded iPaaS platforms (like Zapier Embedded or Workato) provide pre-built connectors with a workflow layer, which speeds up deployment but adds cost and a middleware dependency. Unified API platforms (like Knit) provide a single API endpoint that normalises data from hundreds of SaaS tools into a consistent schema - the fastest path to multi-tool coverage for agents. For 2026, unified APIs combined with MCP server support is becoming the standard architecture for production AI agents that need to act across many systems.

What are examples of integrations for AI agents?

Common AI agent integration examples include: an HR agent that reads employee data from Workday or BambooHR to answer questions about org structure, leave balances, or comp data; a sales agent that pulls deal context from Salesforce or HubSpot before drafting outreach; a support agent that retrieves ticket history from Zendesk or Intercom to provide contextual responses; a finance agent that reads invoices from accounting software like QuickBooks or NetSuite; and an onboarding agent that writes new hire records to an HRIS and provisions access in an identity provider.

What is a unified API for AI agents and why does it matter?

A unified API normalises multiple third-party APIs into a single consistent interface. Instead of building separate connectors for Workday, BambooHR, and Rippling, an AI agent calls one endpoint like GET /hris/employees and receives normalised data regardless of the underlying platform. This matters for AI agents specifically because agents often need to act across multiple systems in a single workflow - pulling an employee record from Workday, updating a ticket in Jira, and logging the action in a CRM. Without a unified API, the agent needs custom connector logic for each system, which multiplies engineering cost and maintenance burden. Knit is built specifically as a unified API for enterprise HRIS, ATS, and ERP platforms.

What are the main challenges of building integrations for AI agents?

The main challenges are: data compatibility (different SaaS tools structure the same data differently, requiring normalisation); rate limits (agents can make far more API calls per session than traditional integrations, requiring careful throttling); authentication management across many customer accounts; maintaining integrations as upstream APIs evolve; and observability - understanding exactly which integration call caused a failure in a multi-step agent workflow. Unified API platforms like Knit address these by abstracting the integration layer: one endpoint, normalised schema, managed auth, and built-in rate limit handling across all connected platforms.

How do MCP servers help AI agents access enterprise data?

MCP servers wrap enterprise APIs in a standardised tool interface that any MCP-compatible AI agent can call. The agent calls a named tool like get_employee_list or get_open_roles and the MCP server handles the underlying API call, authentication, pagination, and data transformation - without any per-platform custom code in the agent itself. Knit's MCP servers expose tools covering employees, org structure, payroll, and job profiles across 100+ HRIS and ATS platforms, all accessible from Claude, GPT, or any MCP-compatible agent through a single server connection.

‍

Tutorials

Apr 5, 2026

The Ultimate Developer Guide to Calendar API Integration

In today’s fast-paced digital landscape, organizations across all industries are leveraging Calendar APIs to streamline scheduling, automate workflows, and optimize resource management. While standalone calendar applications have always been essential, Calendar Integration significantly amplifies their value—making it possible to synchronize events, reminders, and tasks across multiple platforms seamlessly. Whether you’re a SaaS provider integrating a customer’s calendar or an enterprise automating internal processes, a robust API Calendar strategy can drastically enhance efficiency and user satisfaction.

Explore more Calendar API integrations

In this comprehensive guide, we’ll discuss the benefits of Calendar API integration, best practices for developers, real-world use cases, and tips for managing common challenges like time zone discrepancies and data normalization. By the end, you’ll have a clear roadmap on how to build and maintain effective Calendar APIs for your organization or product offering in 2026.

1. Why Calendar API Integration Matters

In 2026, calendars have evolved beyond simple day-planners to become strategic tools that connect individuals, teams, and entire organizations. The real power comes from Calendar Integration, or the ability to synchronize these planning tools with other critical systems—CRM software, HRIS platforms, applicant tracking systems (ATS), eSignature solutions, and more.

Efficiency Gains: Manual scheduling is prone to error and time-consuming. By automating these tasks through Calendar APIs, businesses can streamline processes and eliminate back-and-forth communication.
Customer Experience: Integrating with customers’ existing calendars enhances convenience, creating a frictionless user experience. In highly competitive markets, seamless scheduling can be a crucial differentiator.
Resource Management: For ERP systems managing logistics or field service appointments, real-time schedule visibility optimizes resource allocation, ensuring the right teams and equipment are always in the right place at the right time.
Scalability: As organizations grow, manual scheduling quickly becomes untenable. API Calendar solutions allow for easy scaling across multiple departments, regions, or even continents.

Essentially, Calendar API integration becomes indispensable for any software looking to reduce operational overhead, improve user satisfaction, and scale globally.

2. Top Benefits of Calendar APIs

Automated Scheduling

One of the most notable advantages of Calendar Integration is automated scheduling. Instead of manually entering data into multiple calendars, an API can do it for you. For instance, an event management platform integrating with Google Calendar or Microsoft Outlook can immediately update participants’ schedules once an event is booked. This eliminates the need for separate email confirmations and reduces human error.

Enhanced Customer Experience

When a user can book or reschedule an appointment without back-and-forth emails, you’ve substantially upgraded their experience. For example, healthcare providers that leverage Calendar APIs can let patients pick available slots and sync these appointments directly to both the patient’s and the doctor’s calendars. Changes on either side trigger instant notifications, drastically simplifying patient-doctor communication.

Optimized Resource Management

By aligning calendars with HR systems, CRM tools, and project management platforms, businesses can ensure every resource—personnel, rooms, or equipment—is allocated efficiently. Calendar-based resource mapping can reduce double-bookings and idle times, increasing productivity while minimizing conflicts.

Real-time Notifications

Notifications are integral to preventing missed meetings and last-minute confusion. Whether you run a field service company, a professional consulting firm, or a sales organization, instant schedule updates via Calendar APIs keep everyone on the same page—literally.

Workflow Automation Across Platforms

API Calendar solutions enable triggers and actions across diverse systems. For instance, when a sales lead in your CRM hits “hot” status, the system can automatically schedule a follow-up call, add it to the rep’s calendar, and send a reminder 15 minutes before the meeting. Such automation fosters a frictionless user experience and supports consistent follow-ups.

3. Calendar API Data Models Explained

To integrate calendar functionalities successfully, a solid grasp of the underlying data structures is crucial. While each calendar provider may have specific fields, the broad data model often consists of the following objects:

Calendar Object
- id: A unique identifier, such as calendar12345.
- name: E.g., “Work Calendar,” “Personal Calendar.”
- description: Optional text describing the calendar.
- timeZone: Default time zone for events (e.g., “UTC,” “America/New_York”).
- owner: Information about who owns or manages the calendar.
Event Object
- id: A unique identifier for the event.
- title: A short description (e.g., “Team Standup”).
- description: Detailed notes or instructions.
- start and end: DateTime fields for event timing.
- location: Physical or virtual meeting link.
- attendees: A list of people (or groups) invited, each with an email and response status.
- recurrence: Rules for repeating events, such as frequency or exceptions.
- reminders: Notification triggers before an event begins.
- status: (confirmed, tentative, canceled)
- visibility: Defines who can see event details.
Attendee Object
- email: The attendee’s email address.
- responseStatus: e.g., accepted, declined.
- comment: Optional notes from the attendee.
Reminder Object
- method: email, popup, or SMS.
- minutesBeforeStart: E.g., remind 10 minutes before the event.
Recurrence Rule Object
- frequency: daily, weekly, monthly, etc.
- interval: e.g., every 2 days or every week.
- daysOfWeek: For weekly events.
- endDate: When the series ends.
- exceptions: Specific dates skipped in the recurrence pattern.

Properly mapping these objects during Calendar Integration ensures consistent data handling across multiple systems. Handling each element correctly—particularly with recurring events—lays the foundation for a smooth user experience.

4. Best Practices for Calendar API Integration

1. Choose the Right Calendar API

Customer Demand: Are users frequently requesting Google Calendar, Apple Calendar, or Microsoft Outlook integration? Prioritize your efforts accordingly.
API Documentation & Support: Evaluate if the calendar provider offers robust docs, SDKs, or community support.
Business Potential: A highly demanded integration with thousands of potential users may take precedence over niche calendar integrations.

2. Leverage Webhooks for Real-Time Updates

Reduce Polling: Instead of constantly querying the API, webhooks send event data to your application as soon as changes happen.
Key Event Triggers: Keep track of crucial events like creation, deletion, or modifications.
Failover Mechanisms: Implement retry logic for webhook delivery if the receiving server is temporarily unreachable.

3. Handle Recurring Events and Exceptions Carefully

Implement Standard Recurrence Rules: Align with iCalendar or similar standards for cross-platform compatibility.
Account for Partial Cancellations: Users might cancel one instance in a recurring series without affecting the rest.
Test Thoroughly: Recurring events can get complex quickly—test edge cases like end-dates, changing frequency mid-series, etc.

4. Manage Rate Limits Gracefully

Caching: Store non-time-sensitive data (time zones, user profiles) to minimize API calls.
Exponential Backoff: When you hit rate limits, increase wait times between retries.
Prioritize Calls: Identify essential calls that need real-time data vs. those that can be deferred.

5. Log Data for Troubleshooting

Comprehensive Logging: Capture API endpoints, payloads, response codes, and error messages.
Error Tracking: Implement real-time alerts for major failures.
Secure Storage: Protect logs from unauthorized access or data breaches.

6. Undertake Data Normalization

Cross-Platform Consistency: Ensure you normalize date-time formats, time zones, and event statuses when multiple calendar providers are involved.
Schema Mapping: Map each field from the external calendar to your internal data model to avoid confusion.

5. Popular Calendar APIs

Below are several well-known Calendar APIs that dominate the market. Each has unique features, so choose based on your users’ needs:

Google Calendar API
- Documentation: Google Calendar Developer Docs
- Advantages: Wide user base, robust features, extensive documentation.
Outlook Calendar (Microsoft Graph) API
- Documentation: Microsoft Graph Calendar Overview
- Advantages: Deep integration with Microsoft 365 ecosystem, enterprise-friendly.
Apple Calendar API
- Documentation: Apple Developer Documentation
- Advantages: Native iOS and macOS support, strong for personal usage.
Cronofy API
- Documentation: Cronofy Developer Docs
- Advantages: Unified calendar API bridging major calendar platforms.
Calendly API
- Documentation: Calendly API Docs
- Advantages: Scheduling app specialty, widely adopted among sales and consultants.
Timekit API
- Documentation: Timekit Docs
- Advantages: Flexible booking rules and advanced scheduling features.

6. Real-World Use Cases

Candidate Interview Scheduling for ATS

Applicant Tracking Systems (ATS) like Lever or Greenhouse can integrate with Google Calendar or Outlook to automate interview scheduling. Once a candidate is selected for an interview, the ATS checks availability for both the interviewer and candidate, auto-generates an event, and sends reminders. This reduces manual coordination, preventing double-bookings and ensuring a smooth interview process.

Learn more on How Interview Scheduling Companies Can Scale ATS Integrations Faster

Resource Allocation for ERP

ERPs like SAP or Oracle NetSuite handle complex scheduling needs for workforce or equipment management. By integrating with each user’s calendar, the ERP can dynamically allocate resources based on real-time availability and location, significantly reducing conflicts and idle times.

Client Meetings for CRM

Salesforce and HubSpot CRMs can automatically book demos and follow-up calls. Once a customer selects a time slot, the CRM updates the rep’s calendar, triggers reminders, and logs the meeting details—keeping the sales cycle organized and on track.

Employee Onboarding and Training for HRIS

Systems like Workday and BambooHR use Calendar APIs to automate onboarding schedules—adding orientation, training sessions, and check-ins to a new hire’s calendar. Managers can see progress in real-time, ensuring a structured, transparent onboarding experience.

Assessment Scheduling

Assessment tools like HackerRank or Codility integrate with Calendar APIs to plan coding tests. Once a test is scheduled, both candidates and recruiters receive real-time updates. After completion, debrief meetings are auto-booked based on availability.

Document Signing Deadlines for eSignature

DocuSign or Adobe Sign can create calendar reminders for upcoming document deadlines. If multiple signatures are required, it schedules follow-up reminders, ensuring legal or financial processes move along without hiccups.

Invoice Due Dates and Tax Filing for Accounting Systems

QuickBooks or Xero integrations place invoice due dates and tax deadlines directly onto the user’s calendar, complete with reminders. Users avoid late penalties and maintain financial compliance with minimal manual effort.

7. Common Calendar API Integration Challenges

While Calendar Integration can transform workflows, it’s not without its hurdles. Here are the most prevalent obstacles:

1. Time Zone Discrepancies and Recurring Events

Global Teams: Multinational organizations must dynamically adjust meeting times across time zones.
Recurring Event Modifications: A single instance of a recurring meeting might move or get canceled without affecting the entire series.
DateTime Inconsistencies: Some APIs treat all-day events differently, causing confusion across platforms.

2. Scaling Across Multiple Providers

Diverse Endpoints: Google, Microsoft, and Apple each have unique endpoints, data fields, and authentication protocols.
Ongoing Maintenance: Providers frequently update or deprecate endpoints, necessitating regular engineering work.

3. Permissions and Access Controls

Privacy Concerns: Misconfiguration can expose private events to unauthorized viewers.
Varying Permission Protocols: Each provider (Google, Outlook, Apple) handles read/write permissions differently, complicating integration code.

4. Data Sync Inconsistencies

Format Mismatches: Each calendar might store date/time data in a slightly different format.
Lost Fields: Failing to map custom fields or statuses can cause partial data loss.
All-day vs. Timed Events: Some calendars represent “all-day” as a 24-hour block, causing scheduling confusion.

5. Dealing with API Updates and Deprecations

Version Upgrades: Provider APIs change version protocols, sometimes forcing urgent updates to avoid outages.
Deprecated Endpoints: If a crucial endpoint is retired, your integration can break unless you adapt quickly.

8. Unified Calendar API vs. Direct Connector APIs

Businesses can integrate Calendar APIs either by building direct connectors for each calendar platform or opting for a Unified Calendar API provider that consolidates all integrations behind a single endpoint. Here’s how they compare:

Aspect	Unified Calendar APIs	Direct Connector APIs
Integration Setup	Single integration for multiple calendars	Separate connectors for each calendar
Maintenance	Centralized updates and versioning	Ongoing work for each provider’s changes
Data Normalization	Automatic standardization across providers	Custom normalization logic per API
Scalability	Effortless: Add new providers via existing platform	Difficult: Each new calendar = new connector
Authentication & Security	Centralized handling of OAuth, encryption, etc.	Multiple protocols to manage individually
Customization	Limited advanced features for each calendar	High control for unique or edge-case features
Time & Cost	Faster initial deployment; lower TCO	Higher development overhead; can add up quickly

‍

When to Choose a Unified Calendar API

Rapid Multi-Calendar Integration: If you need Google, Outlook, and Apple Calendar simultaneously, a unified approach saves time.
Resource Constraints: Your engineering team can focus on core product features, leaving integration complexities to the platform.
Scalability: Ideal if you foresee adding more calendar providers as you grow.

When to Choose Direct Connectors

Niche Requirements: If you need very specialized or advanced features that a unified API doesn’t cover.
Single-Platform Focus: For example, a solution that only needs Google Calendar might find a direct connector sufficient.

Learn more about what should you look for in a Unified API Platform

9. TL;DR: Key Takeaways

Calendar Integration is a competitive necessity in 2026, bridging siloed tools, improving user experiences, and automating workflows.
Key Use Cases include ATS scheduling, ERP resource allocation, CRM follow-ups, HR onboarding, and eSignature reminders.
Biggest Challenges revolve around time zone differences, data normalization, permission settings, and dealing with API updates.
Best Practices: Implement webhooks, handle recurring events carefully, manage rate limits gracefully, and log data meticulously.
Unified APIs vs. Direct Connectors: Unified solutions provide quick multi-calendar scalability, while direct connectors give deeper customization for single-use cases.

10. Conclusion and Next Steps

The calendar landscape is only getting more complex as businesses and end users embrace an ever-growing range of tools and platforms. Implementing an effective Calendar API strategy—whether through direct connectors or a unified platform—can yield substantial operational efficiencies, improved user satisfaction, and a significant competitive edge. From Calendar APIs that power real-time notifications to AI-driven features predicting best meeting times, the potential for innovation is limitless.

If you’re looking to add API Calendar capabilities to your product or optimize an existing integration, now is the time to take action. Start by assessing your users’ needs, identifying top calendar providers they rely on, and determining whether a unified or direct connector strategy makes the most sense. Incorporate the best practices highlighted in this guide—like leveraging webhooks, managing data normalization, and handling rate limits—and you’ll be well on your way to delivering a next-level calendar experience.

Ready to transform your Calendar Integration journey?
Book a Demo with Knit to See How AI-Driven Unified APIs Simplify Integrations

11. Frequently Asked Questions

What is Calendar API integration?

Calendar API integration is the process of connecting your software application to a calendar platform - such as Google Calendar, Microsoft Outlook, or Apple Calendar - using that platform's API to read, create, update, and delete events programmatically. Instead of requiring users to manually copy meeting details between systems, a calendar API integration lets your product sync scheduling data directly with the user's existing calendar. For B2B SaaS products, calendar integrations are commonly used for interview scheduling in ATS tools, client meeting sync in CRM platforms, and onboarding milestone tracking in HRIS systems. Knit provides a unified Calendar API that connects your product to all major calendar platforms through a single integration.

How do you integrate a calendar API?

To integrate a calendar API:

(1) Register your application with the calendar provider (Google Cloud Console for Google Calendar, Azure AD for Microsoft Graph);

(2) implement OAuth 2.0 to authenticate users and obtain access tokens scoped to calendar permissions;

(3) call the API endpoints to list, create, or update calendar events using the provider's REST API;

(4) handle webhooks or push notifications to receive real-time event changes;

(5) implement time zone normalization, since calendar APIs return timestamps in various formats. Each calendar platform has a different authentication model, event schema, and rate limit.

For products integrating multiple calendar providers, a unified calendar API layer handles per-provider differences automatically.

What can I do with the Calendar API?

With a calendar API you can: read a user's upcoming events and availability windows; create new events with attendees, location, conferencing links, and reminders; update or cancel existing events; access free/busy information to find open slots for scheduling; subscribe to calendar change notifications via webhooks; and manage recurring event series including exceptions and cancellations. Calendar APIs expose the core scheduling primitives - events, attendees, reminders, recurrence rules - that power features like automated interview scheduling, appointment booking, resource allocation, and cross-platform event sync in B2B SaaS products.

Is Google Calendar API free?

Yes. Google Calendar API is free to use - there is no per-request charge and exceeding quota limits does not incur extra billing. The default quota is 1,000,000 queries per day per project, with a per-user rate limit of 60 requests per minute. For production applications with high request volumes, you can apply for a quota increase via Google Cloud Console. The Microsoft Graph Calendar API (Outlook/Microsoft 365) is similarly free to use for reading and writing calendar data, provided the end user has a valid Microsoft 365 licence. You pay for the underlying platform licences (if applicable), not for API calls themselves.

Which calendar APIs should developers integrate with first?

Prioritise based on your users' calendar providers. For most B2B SaaS products, start with Google Calendar API (dominant among SMB and tech-forward companies) and Microsoft Graph Calendar API (dominant in enterprise and regulated industries). Together these two cover the vast majority of business users. Apple Calendar (CalDAV-based) is worth adding if your users skew to Mac-heavy or mobile-first workflows. Zoho Calendar and Exchange on-premises matter for specific verticals. Most products build Google first, then Microsoft, then expand based on customer demand. If you want to go live with all of them at once consider a unified API like Knit that lets you integrate with all calendar apps via a single integration

What are the main challenges in Calendar API integration?

Key challenges include: time zone handling - calendar events use IANA timezone identifiers and RFC 5545 recurrence rules (RRULE) that must be normalised across providers; recurring events - modifying a single instance vs. the entire series requires careful handling of exception logic; permission scopes - requesting overly broad calendar access triggers user friction during OAuth consent; rate limits - Google Calendar enforces per-user limits requiring exponential backoff; data sync inconsistencies - webhook delivery can be delayed or missed, requiring periodic polling as a fallback; and multi-provider divergence, where the event object structure differs significantly between Google, Microsoft, and Apple calendar APIs.

What are best practices for Calendar API integration?

‍Key best practices: use webhooks (Google Calendar push notifications, Microsoft Graph change notifications) for real-time event updates rather than polling; request the minimum OAuth scopes needed - for read-only use cases, avoid requesting write permissions; normalise time zones using the IANA timezone database before storing or displaying event times; handle recurring event exceptions carefully - modifying a single occurrence requires sending the recurrence ID; implement exponential backoff for rate limit errors (HTTP 429); store event ETags or sync tokens to detect changes efficiently; and test edge cases like all-day events, multi-day events, and events with no attendees, which vary in structure across providers.

When should I use a unified Calendar API instead of direct calendar integrations?

‍Use a unified calendar API when your product needs to support more than one or two calendar providers and you want to avoid maintaining separate integration codebases for each. A unified layer normalises the event schema, handles per-provider OAuth flows, and abstracts webhook differences - so you build once and gain coverage across Google Calendar, Microsoft Outlook, Apple Calendar, and others. Direct integrations make sense when you need provider-specific features not exposed by a unified layer, or when you're building deeply for a single platform. Knit's unified Calendar API lets B2B SaaS products connect to all major calendar platforms through a single integration without managing per-provider authentication or event schema differences.

‍

References and External Links

By following the strategies in this comprehensive guide, you’ll not only harness the power of Calendar APIs but also future-proof your software or enterprise operations for the decade ahead. Whether you’re automating interviews, scheduling field services, or synchronizing resources across continents, Calendar Integration is the key to eliminating complexity and turning time management into a strategic asset.

Tutorials

Apr 16, 2026

Workday API Integration Guide (In-Depth)

This guide is part of our growing collection on HRIS integrations. We’re continuously exploring new apps and updating our HRIS Guides Directory with fresh insights.

Introduction to Workday API

Overview of Workday

Workday has become one of the most trusted platforms for enterprise HR, payroll, and financial management. It’s the system of record for employee data in thousands of organizations. But as powerful as Workday is, most businesses don’t run only on Workday. They also use performance management tools, applicant tracking systems, payroll software, CRMs, SaaS platforms, and more.

The challenge? Making all these systems talk to each other.

That’s where the Workday API comes in. By integrating with Workday’s APIs, companies can automate processes, reduce manual work, and ensure accurate, real-time data flows between systems.

In this blog, we’ll give you everything you need, whether you’re a beginner just learning about APIs or a developer looking to build an enterprise-grade integration.

We’ll cover terminology, use cases, step-by-step setup, code examples, and FAQs. By the end, you’ll know how Workday API integration works and how to do it the right way.

Looking to quickstart with the Workday API Integration? Check our Workday API Directory for common Workday API endpoints

What Workday Does‍

Function	What Workday Does
Human Resources (HR)	Stores and manages employee information, including names, job titles, promotions, transfers, and performance data.
Payroll	Automates salaries, benefits, tax deductions, and ensures compliance across regions.
Recruiting	Post job openings, track candidates, and manage complete hiring workflows.
Finance	Handles expenses, budgets, procurement, and supplier contracts.
Analytics	Provides leadership with real-time dashboards for data-driven decisions.

‍

Why Workday Matters to Organizations

Single Source of Truth: Workday centralizes HR and finance data, ensuring accuracy and consistency across the organization.
Efficiency: Automates repetitive HR and payroll tasks, saving teams hours of manual work.
Compliance & Security: Keeps sensitive employee and financial information secure while meeting regional regulations.
Scalability: Grows with your business, supporting small teams as well as global enterprises.
Real-time insights give leaders visibility into workforce and financial health.

Workday API integration use cases

Workday integrations can support both internal workflows for your HR and finance teams, as well as customer-facing use cases that make SaaS products more valuable. Let’s break down some of the most impactful examples.

1. Analyze Employee Performance and Adjust Compensation

Performance reviews are key to fair salary adjustments, promotions, and bonus payouts. Many organizations use tools like Lattice to manage reviews and feedback, but without accurate employee data, the process can become messy.

By integrating Lattice with Workday, job titles and salaries stay synced and up to date. HR teams can run performance cycles with confidence, and once reviews are done, compensation changes flow back into Workday automatically — keeping both systems aligned and reducing manual work.

2. Streamline Employee Onboarding

Onboarding new employees is often a race against time , from getting payroll details set up to preparing IT access. With Workday, you can automate this process.

For example, by integrating an ATS like Greenhouse with Workday:

As soon as a candidate is marked as “hired” in Greenhouse, their employee record is created automatically in Workday.
Workday then provides HR teams with the new hire’s start date, address, job title, and department.
This kickstarts payroll setup, benefits enrollment, and access provisioning without delays.

3. Add Users to Your Product Seamlessly

For SaaS companies, onboarding users efficiently is key to customer satisfaction. Workday integrations make this scalable.

Take BILL, a financial operations platform, as an example:

When a new employee is added to a company’s Workday tenant, BILL automatically notifies admin users.
Admins can then add these employees into the platform with one click.
They can also bulk-import groups of employees for even faster setup.

4. Remove Users Quickly and Securely

Offboarding is just as important as onboarding, especially for maintaining security. If a terminated employee retains access to systems, it creates serious risks.

Platforms like Ramp, a spend management solution, solve this through Workday integrations:

When an employee is marked as terminated in Workday (or another HRIS like Gusto), Ramp automatically flags their account.
Admins can remove or lock the account with just a few clicks.
In some cases, the employee’s account can remain open but with restricted permissions (like frozen cards).

While this guide equips developers with the skills to build robust Workday integrations through clear explanations and practical examples, the benefits extend beyond the development team. You can also expand your HRIS integrations with the Workday API integration and automate tedious tasks like data entry, freeing up valuable time to focus on other important work. Business leaders gain access to real-time insights across their entire organization, empowering them to make data-driven decisions that drive growth and profitability. This guide empowers developers to build integrations that streamline HR workflows, unlock real-time data for leaders, and ultimately unlock Workday's full potential for your organization.

Important Terminology of Workday API

Understanding key terms is essential for effective integration with Workday. Let’s look upon few of them, that will be frequently used ahead -

Workday Tenant: Imagine your Workday tenant as your company’s own secure vault within the workday system. It’s a self-contained environment, and it will contain all your company’s data and configuration. Companies typically have separate tenants for development, testing, and production.
Webhooks: Notifications that tell you when something changes (like a new employee added).
Integration System User (ISU): This is like a “robot login” created just for apps and systems to connect to Workday. Instead of using a real person’s account, this special account is used only for integrations.
OAuth 2.0: A modern way of logging in without sharing passwords. Apps get secure “keys” (tokens) to connect, and these keys can be refreshed automatically when they expire.
REST API: A simple, modern way for apps to talk to Workday using easy-to-read data (JSON). It’s commonly used for cloud apps.
SOAP API: An older method for apps to connect with Workday using more complicated data (XML). It’s often used for things like payroll and financial systems.
PECI (Payroll Effective Change Interface): This feature automatically sends employee updates (like new hires, promotions, or exits) from Workday to payroll providers, so payroll stays accurate.

Overview of Workday API Documentation

1. API Types: Workday offers REST and SOAP APIs, which serve different purposes. REST APIs are commonly used for web-based integrations, while SOAP APIs are often utilized for complex transactions.

2. Endpoint Structure: You must familiarize yourself with the Workday API structure as each endpoint corresponds to a specific function. A common workday API example would be retrieving employee data or updating payroll information.

3. API Documentation: Workday API documentation provides a comprehensive overview of both REST and SOAP APIs.

Workday REST API: The REST API allows developers to interact with Workday's services using standard HTTP methods. It is well-documented and provides a straightforward way to integrate with Workday.

Workday REST API Documentation: Workday's REST API documentation provides detailed information on using the API, including endpoints, parameters, and response formats. It is a valuable resource for developers looking to integrate with Workday.

Workday SOAP API Documentation: Workday's SOAP API documentation provides information on how to use the SOAP API for more complex transactions. SOAP APIs are often used for integrations that require a higher level of security and reliability.

Workday SOAP API Example: An example of using Workday's SOAP API could be retrieving employee information from Workday's HR system to update a payroll system. This example demonstrates the use of SOAP APIs for complex transactions.

Authentication and Authorization in Workday

Workday supports two primary ways to authenticate API calls. Which one you use depends on the API family you choose:

SOAP APIs – ISU (Integration System User) + Password

SOAP requests are authenticated with a special Workday user account (the ISU) using WS-Security headers. Access is controlled by the security group(s) and domain policies assigned to that ISU.

REST APIs – OAuth 2.0 (Tokens)

REST requests use OAuth 2.0. You register an API client in Workday, grant scopes (what the client is allowed to access), and obtain access tokens (and a refresh token) to call endpoints.

When to use what

Choose SOAP + ISU if you’re working with complex, highly structured business processes (e.g., payroll, certain staffing operations) and you need Workday’s strict WSDL contracts.
Choose REST + OAuth if you’re building modern SaaS integrations that prefer JSON, simpler request/response patterns, and scope-based access control.

Security basics (that apply to both)

Least privilege: Give your ISU/security groups or OAuth client only the permissions/scopes needed.
Separate environments: Use different credentials for Sandbox vs. Production.
Protect secrets: Store client secrets and passwords in a secure vault, not in code or repos.
Rotate regularly: Rotate passwords/keys/tokens on a schedule.
‍Audit & monitor: Enable logging, review access, and alert on failures or unusual activity.

Steps for building a Workday API Integration

To ensure a secure and reliable connection with Workday's APIs, this section outlines the essential prerequisites. These steps will lay the groundwork for a successful integration, enabling seamless data exchange and unlocking the full potential of Workday within your existing technological infrastructure.

Setup up a Workday Developer Account: If you are new to Workday, sign up for a Workday developer account. This grants access to documentation, sample code, and APIs
Explore Workday's API Playground: Get familiar with Workday API endpoints and resources. Download the API docs – they'll be your roadmap.
Setup a Workday Tenant: A workday tenant is basically an instance of the Workday software. It is your orgs private area within Workday. You will need Tenant Credentials (Tenant Name, Username, Password), and appropriate roles and permissions within Workday.
Setup an Integration System User (ISU): Once the Workday tenant is set up, you will need to enable API access in it. This typically involves creating a dedicated Integration System User (ISU) in Workday, assigning it to a security group, and configuring the necessary domain security policies.
Register API Client: Register your API client within Workday to get a unique client ID and secret (like a secret handshake) for secure API calls. Store these credentials safely!
Setup up OAuth 2.0: Workday supports OAuth 2.0. After registering your API client in the Workday system to obtain a Client ID and Client Secret, just use these credentials to request OAuth 2.0 access tokens, which are required by the Integration System User (ISU) for authenticating API calls.
Pick between REST and SOAP: Workday supports both REST and SOAP protocols. You must pick between the two based on your requirements of integration performance, complexity, security and flexibility. While SOAP offers more security and is better suited for complex integrations, it can be slower in terms of data transfer speeds. On the other hand, REST is flexible and often recommended for lightweight integrations.
Build your integration use case: Once you have decided which Workday API protocol suits you best, you need to write the actual code using the right APIs for your integration use case.
Test your integration in a sandbox: After writing the integration code using Workday APIs, it is highly recommended to test the integration in a Workday sandbox. At times, it can be difficult to get access to a Workday sandbox, because Workday only provisions sandbox access to paid customers on certain plans. This is where working with Knit can help. Knit API provides Workday Sandbox access to its customers on the Scale and Enterprise plans for development and testing Workday integrations. Get in touch here.
Deploy to production: Once tested on the Workday sandbox, your Workday API integration is all set to go live! Keep an eye on your integration – implement logging and monitoring for API calls. Review and update your integration settings as needed.

Now that you have a comprehensive overview of the steps required to build a Workday API Integration and an overview of the Workday API documentation, lets dive deep into each step so you can build your Workday integration confidently!

STEP 1: Setting up a Workday tenant and obtaining Web Services Endpoint

The Web Services Endpoint for the Workday tenant serves as the gateway for integrating external systems with Workday's APIs, enabling data exchange and communication between platforms. To access your specific Workday web services endpoint, follow these steps:

Locate Public Web Services:
1. In Workday, search for "Public Web Services".
2. Open the "Public Web Services Report".
Access the Human Resources WSDL:
1. Hover over the "Human Resources" section.
2. Click the three dots (ellipses) to open the menu.
3. Select "Web Services" and then click "View WSDL".
Find the Endpoint Host:
1. On the page that opens, scroll to the bottom.
2. Locate the host URL, which will look something like https://wd5-services1.myworkday.com/ccx.
3. Copy the URL before /service.

Workday Public Web Services list showing available SOAP web services including Human Resources, Financial Management, and External Integrations — Finding your public web services endpoint url on Workday

STEP 2: Setting up an Integration System User (ISU) in Workday

Next, you need to establish an Integration System User (ISU) in Workday, dedicated to managing API requests. This ensures enhanced security and enables better tracking of integration actions. Follow the below steps to set up an ISU in Workday:

Log into Workday:
- Access your Workday portal and log into your Workday tenant.
Create an Integration System User:
- In the search field, type "Create Integration System User" and select the corresponding task.
Fill in User Details:‍
- On the "Create Integration System User" page, go to the "Account Information" section.
- Enter a username, and then enter and confirm the password.
- Do not select the Require New Password at the Next Sign In check box
- Type 0 (zero) for Session Timeout Minutes to prevent session expiration
- Click "OK" to save.
- Note: You'll want to add this user to the list of System Users to make sure the password doesn't expire.

Workday Create Integration System User screen showing ISU account setup with username, password, and session timeout configuration — Setting up an Integration System User (ISU) on Workday

‍

Create a Security Group and Assign an Integration System User: Now, add this Integration System User to a Security Group to ensure controlled access to Workday APIs, enhancing security by restricting permissions to authorized entities only:
- Create a Security Group: In the search field, type "Create Security Group" and select the task.
- Click "OK"

Workday Create Security Group screen showing Integration System Security Group type selection for API access control — Creating an Integration System Security Group on Workday

Configure the security group
- On the "Create Security Group" page, select "Integration System Security Group" from the "Type of Tenanted Security Group" drop-down menu.
- In the "Name" field, enter a name for the security group.
- Click "OK".
Edit the security group
- On the "Edit Integration System Security Group (Unconstrained)" page, enter the same name you used when creating the ISU in the "Name" field.
- Click “OK”.

Edit Integration System Security Group on Workday

Configure Domain Security Policy Permissions: Now, we need to ensure that the Integration System User (ISU) has the necessary access rights to interact with specific domains and perform operations within Workday's ecosystem. Here are the steps to configure Domain Security Policy Permissions for the same:
- Maintain Permissions for the Security Group:
  - In the search field, type "Maintain Permissions for Security Group" and select the corresponding task.
  - The "Maintain Permissions for Security Group" page will appear.
- Configure the Permissions:
- Select the necessary "Maintain” Operation.
- Ensure the "Source Security Group" name matches your created security group.
- Click “OK”

Configure Domain Security Policy Permission in Workday

Add Domain Security Policy Permissions
- Add the required Domain Security Policy Permissions with the "GET" operation

Adding Domain Security Policy Permissions in Workday

Note: The permissions listed below are necessary for the full HRIS API. These permissions may vary depending on the specific implementation

Parent Domains for HRIS

Job Requisition Data
Person Data: Name
Person Data: Personal Data
Person Data: Home Contact Information
Person Data: Work Contact Information
Worker Data: Compensation
Worker Data: Workers
Worker Data: All Positions
Worker Data: Current Staffing Information
Worker Data: Public Worker Reports
Worker Data: Employment Data
Worker Data: Organization Information

Parent Domains for HRIS‍

Candidate Data: Job Application
Candidate Data: Personal Information
Candidate Data: Other Information
Pre-Hire Process Data: Name and Contact Information
Job Requisition Data
Person Data: Personal Data
Person Data: Home Contact Information
Person Data: Work Contact Information
Manage: Location
Worker Data: Public Worker Reports

Activate Security Policy Changes: Next, we will activate Security Policy Changes to ensure that any modifications made to security settings within the system take effect and are enforced.
- In the search bar, type "Activate Pending Security Policy Changes"
- Review the summary of the changes that need approval
- Approve the pending security policy changes to activate them

‍

Activate Security Policy Changes in Workday

STEP 3: Setting up OAuth 2.0 in Workday

Workday offers different authentication methods. Here, we will focus on OAuth 2.0, a secure way for applications to gain access through an ISU (Integrated System User). An ISU acts like a dedicated user account for your integration, eliminating the need to share individual user credentials. Below steps highlight how to obtain OAuth 2.0 tokens in Workday:

Retrieve Endpoints
- Access "View API Clients"
- Use the Workday search bar to navigate to "View API clients"
- At the top of the page, locate the base REST API endpoint
- Extract Host and Tenant Names
- The Workday REST API Endpoint format is: https://{host name}.workday.com/ccx/api/v1/{tenant name}.
- Retrieve and securely store the hostname and tenant name for future use in connecting to the Workday integration
Obtain Workday REST Client ID: Now, we will need the Workday REST Client ID, which is necessary for authenticating and authorizing API requests, ensuring secure access to Workday's resources. Here are the steps to get your Workday REST Client ID
- Access Workday Application: Log in to the Workday application
- Register API Client: Navigate to the "Register API Client" section

- Enter Client Details
  - In the "Client Name" field, input the desired name for the client
  - Choose "Authorization Code Grant" for the "Client Grant Type"
- Set Access Token Type: Select "Bearer" as the access token type.
- Select Scope Values: From the Workday REST API scopes, select the relevant functional areas
  - Benefits
  - Candidate Engagement
  - Core Compensation
  - Organizations and Roles
  - Performance Enablement
  - Pre-Hire Process
  - Recruiting
  - Staffing
  - Time Off and Leave
  - Time Tracking
  - Worker Profile and Skills
- Generate Client ID and Client Secret: Click "OK" to generate the Client ID and Client Secret.

Obtain Workday REST Refresh Token: If you want your application to have continuous access to Workday data without needing to reauthenticate frequently, you should use the Workday REST Refresh token. Here are the steps you can follow to obtain your Workday REST Refresh token
- Log in to Workday
- Access API Client Information
  - In the search field, type "View API client" and select the corresponding task
  - Click on the "API Clients for Integrations" tab.
  - Select the relevant API client that you created
- Manage Refresh Tokens
  - Choose "Manage Refresh Tokens for Integrations"
  - Enter the ISU account you generated in the "Workday Account" field
  - Click "OK" and return to the Workday home page
- Generate New Refresh Token
  - Select the "Generate New Refresh Token" option on the "Delete or Regenerate Refresh Token" page
  - Set "Non-Expiring Refresh Token" to "Yes"
  - Click "OK
- Copy Refresh Token
  - On the "Successfully Regenerated Refresh Token" page, copy the refresh token provided and store securely. These refresh tokens will be used to generate access tokens for authenticating your ISU when accessing Workday APIs.

STEP 4: SOAP vs. REST: Picking the Right Workday API for the Job

When building a Workday integration, one of the first decisions you’ll face is: Should I use SOAP or REST?

Both are supported by Workday, but they serve slightly different purposes. Let’s break it down.

SOAP - The Structured and Secure Option

SOAP (Simple Object Access Protocol) has been around for years and is still widely used in Workday, especially for sensitive data and complex transactions.

Advantages of SOAP APIs

Feature	Description
High Security	Enforces strict rules and supports WS-Security, making it excellent for sensitive areas like payroll and financial data.
Consistency	Uses a WSDL file (Web Services Description Language) as a contract, ensuring both the app and Workday know exactly what data is expected.
Reliability	Built for transactional accuracy, making it ideal for payroll runs, employee hiring, or compliance-heavy processes.

How to work with SOAP:

Download the WSDL file for the service you want (e.g., Human Resources, Staffing).
Use tools like SOAP UI or cURL to send XML-based requests.
Authenticate with an ISU (Integration System User) username and password.

REST - The Flexible and Modern Choice

REST (Representational State Transfer) is the newer, lighter, and easier option for Workday integrations. It’s widely used in SaaS products and web apps.

Advantages of REST APIs

Feature	Description
Simple to Use	Works with standard HTTP methods (GET, POST, PUT, DELETE) familiar to most developers.
Faster	REST requests are lightweight and stateless, making them quicker to process than SOAP.
Easy Data Handling	Responses are usually in JSON, which is human-readable and integrates smoothly with modern apps.

How to work with REST:

Use the REST endpoint URL for your tenant. Example: https://{host}.workday.com/ccx/api/v1/{tenant}
Authenticate with OAuth 2.0 tokens.
Test requests easily with tools like Postman or directly from your code.

Which One Should You Choose?

Criteria / Use Case	Use SOAP If…	Use REST If…
Type of Work	Handling payroll, financial transactions, or compliance-critical data where accuracy and strong security are non-negotiable.	Building a web or mobile application that requires quick, responsive interactions with Workday data.
Contracts & Reliability	Need strict contracts and high reliability, ensured by WSDL (Web Services Description Language), which acts as a formal agreement between systems.	Want fast, lightweight integrations that use simple HTTP methods and reduce overhead in processing.
Process Complexity	Use cases involve complex multi-step processes, such as employee onboarding workflows, benefits enrollment, or government reporting.	The main need is simple data exchange, like fetching employee information, syncing HR profiles, or displaying data in a dashboard.
Security & Transactions	Want to leverage WS-Security and transactional guarantees, making sure no step in the process fails unnoticed.	Prefer JSON responses, which are easy to read, debug, and integrate into modern applications and APIs.
Audit & Error Handling	System requires auditability and detailed error handling, making SOAP’s strict protocol advantageous.	Want a stateless, scalable solution that supports quick calls and works well in cloud-native environments.

‍

STEP 5: Building your Workday API integration (With Examples)

Now that you have picked between SOAP and REST, let's proceed to utilize Workday HCM APIs effectively. We'll walk through creating a new employee and fetching a list of all employees – essential building blocks for your integration. Remember, if you are using SOAP, you will authenticate your requests with an ISU user name and password, while if your are using REST, you will authenticate your requests with access tokens generated by using the OAuth refresh tokens we generated in the above steps.

In this guide, we will focus on using SOAP to construct our API requests.

First let's learn about constructing a SOAP Request Body

SOAP requests follow a specific format and use XML to structure the data. Here's an example of a SOAP request body to fetch employees using the Get Workers endpoint:

<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:bsvc="urn:com.workday/bsvc">
    <soapenv:Header>
        <wsse:Security>
            <wsse:UsernameToken>
                <wsse:Username>{ISU USERNAME}</wsse:Username>
                <wsse:Password>{ISU PASSWORD}</wsse:Password>
            </wsse:UsernameToken>
        </wsse:Security>
    </soapenv:Header>
    <soapenv:Body>
        <bsvc:Get_Workers_Request xmlns:bsvc="urn:com.workday/bsvc" bsvc:version="v40.1">
        </bsvc:Get_Workers_Request>
    </soapenv:Body>
</soapenv:Envelope>

👉 How it works:

The <wsse:Security> block carries the ISU login credentials.
The <bsvc:Get_Workers_Request> tells Workday which API function you’re calling.
You can add filters, limits, or extra fields inside the request body as needed.

Now that you know how to construct a SOAP request, let's look at a couple of real life Workday integration use cases:

Use Case 1: Creating a New Employee: Hire Employee API (SOAP Example)

Let's add a new team member. For this we will use the Hire Employee API! It lets you send employee details like name, job title, and salary to Workday. Here's a breakdown:

What it Does: Adds a new employee to your Workday system.
What it Needs: Employee details like name, job information.‍

curl --location 'https://wd2-impl-services1.workday.com/ccx/service/{TENANT}/Staffing/v42.0' \
--header 'Content-Type: application/xml' \
--data-raw '<soapenv:Envelope xmlns:bsvc="urn:com.workday/bsvc" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
    <soapenv:Header>
        <wsse:Security>
            <wsse:UsernameToken>
                <wsse:Username>{ISU_USERNAME}</wsse:Username>
                <wsse:Password>{ISU_PASSWORD}</wsse:Password>
            </wsse:UsernameToken>
        </wsse:Security>
        <bsvc:Workday_Common_Header>
            <bsvc:Include_Reference_Descriptors_In_Response>true</bsvc:Include_Reference_Descriptors_In_Response>
        </bsvc:Workday_Common_Header>
    </soapenv:Header>
    <soapenv:Body>
        <bsvc:Hire_Employee_Request bsvc:version="v42.0">
            <bsvc:Business_Process_Parameters>
                <bsvc:Auto_Complete>true</bsvc:Auto_Complete>
                <bsvc:Run_Now>true</bsvc:Run_Now>
            </bsvc:Business_Process_Parameters>
            <bsvc:Hire_Employee_Data>
                <bsvc:Applicant_Data>
                    <bsvc:Personal_Data>
                        <bsvc:Name_Data>
                            <bsvc:Legal_Name_Data>
                                <bsvc:Name_Detail_Data>
                                    <bsvc:Country_Reference>
                                        <bsvc:ID bsvc:type="ISO_3166-1_Alpha-3_Code">USA</bsvc:ID>
                                    </bsvc:Country_Reference>
                                    <bsvc:First_Name>Employee</bsvc:First_Name>
                                    <bsvc:Last_Name>New</bsvc:Last_Name>
                                </bsvc:Name_Detail_Data>
                            </bsvc:Legal_Name_Data>
                        </bsvc:Name_Data>
                        <bsvc:Contact_Data>
                            <bsvc:Email_Address_Data bsvc:Delete="false" bsvc:Do_Not_Replace_All="true">
                                <bsvc:Email_Address>employee@work.com</bsvc:Email_Address>
                                <bsvc:Usage_Data bsvc:Public="true">
                                    <bsvc:Type_Data bsvc:Primary="true">
                                        <bsvc:Type_Reference>
                                            <bsvc:ID bsvc:type="Communication_Usage_Type_ID">WORK</bsvc:ID>
                                        </bsvc:Type_Reference>
                                    </bsvc:Type_Data>
                                </bsvc:Usage_Data>
                            </bsvc:Email_Address_Data>
                        </bsvc:Contact_Data>
                    </bsvc:Personal_Data>
                </bsvc:Applicant_Data>
                <bsvc:Position_Reference>
                    <bsvc:ID bsvc:type="Position_ID">P-SDE</bsvc:ID>
                </bsvc:Position_Reference>
                <bsvc:Hire_Date>2024-04-27Z</bsvc:Hire_Date>
            </bsvc:Hire_Employee_Data>
        </bsvc:Hire_Employee_Request>
    </soapenv:Body>
</soapenv:Envelope>'

Elaboration:‍

We use `curl` to send a POST request (because we're creating something new).
The URL points to the specific Workday endpoint for hiring employees. We include our tenant name in the URL to point the API to our corresponding tenant.
We include the ISU Username and Password in the <wsse:Security> header in the SOAP envelope to authenticate our API call
The `Content-Type` header specifies we're sending xml data.
The actual employee data goes in the request body, including details like first name, position, work email.

Response:

<bsvc:Hire_Employee_Event_Response
xmlns:bsvc="urn:com.workday/bsvc" bsvc:version="string">
<bsvc:Employee_Reference bsvc:Descriptor="string">
<bsvc:ID bsvc:type="ID">EMP123</bsvc:ID>
</bsvc:Employee_Reference>
</bsvc:Hire_Employee_Event_Response>

If everything goes well, you'll get a success message and the ID of the newly created employee!‍

Use Case 2: Fetching All Employees: Get Workers API (SOAP Example)

Now, if you want to grab a list of all your existing employees. The Get Workers API is your friend!

What it Does: Retrieves a list of all employees in your Workday system.
What it Needs: Your ISU username and password
Where it's Used: The Workday Get Workers API is part of the Workday Developer API suite, which allows developers to interact with Workday's Human Capital Management (HCM) system programmatically. These APIs are commonly used for integrating Workday data and functionality into other applications and systems.

Below is workday API get workers example: ‍

curl --location 'https://wd2-impl-services1.workday.com/ccx/service/{TENANT}/Human_Resources/v40.1' \
--header 'Content-Type: application/xml' \
--data '<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:bsvc="urn:com.workday/bsvc">
    <soapenv:Header>
        <wsse:Security>
            <wsse:UsernameToken>
                <wsse:Username>{ISU_USERNAME}</wsse:Username>
                <wsse:Password>{ISU_USERNAME}</wsse:Password>
            </wsse:UsernameToken>
        </wsse:Security>
    </soapenv:Header>
    <soapenv:Body>
        <bsvc:Get_Workers_Request xmlns:bsvc="urn:com.workday/bsvc" bsvc:version="v40.1">
            <bsvc:Response_Filter>
                <bsvc:Count>10</bsvc:Count>
                <bsvc:Page>1</bsvc:Page>
            </bsvc:Response_Filter>
            <bsvc:Response_Group>
                <bsvc:Include_Reference>true</bsvc:Include_Reference>
                <bsvc:Include_Personal_Information>true</bsvc:Include_Personal_Information>
            </bsvc:Response_Group>
        </bsvc:Get_Workers_Request>
    </soapenv:Body>
</soapenv:Envelope>'‍

This is a simple GET request to the Get Workers endpoint.

‍Elaboration:

The URL points to the specific Workday endpoint for retrieving employees.We include our tenant name in the URL to point the API to our corresponding tenant.
We include the ISU Username and Password in the <wsse:Security> header in the SOAP envelope to authenticate our API call
The `Content-Type` header specifies we're sending xml data.
We include the Count and Page Number parameters in the request to paginate the results. This technique can be used to optimize the results so that we process a batch of data at once.

Response:

<?xml version='1.0' encoding='UTF-8'?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
    <env:Body>
        <wd:Get_Workers_Response xmlns:wd="urn:com.workday/bsvc" wd:version="v40.1">
            <wd:Response_Filter>
                <wd:Page>1</wd:Page>
                <wd:Count>1</wd:Count>
            </wd:Response_Filter>
            <wd:Response_Data>
                <wd:Worker>
                    <wd:Worker_Data>
                        <wd:Worker_ID>21001</wd:Worker_ID>
                        <wd:User_ID>lmcneil</wd:User_ID>
                        <wd:Personal_Data>
                            <wd:Name_Data>
                                <wd:Legal_Name_Data>
                                    <wd:Name_Detail_Data wd:Formatted_Name="Logan McNeil" wd:Reporting_Name="McNeil, Logan">
                                        <wd:Country_Reference>
                                            <wd:ID wd:type="WID">bc33aa3152ec42d4995f4791a106ed09</wd:ID>
                                            <wd:ID wd:type="ISO_3166-1_Alpha-2_Code">US</wd:ID>
                                            <wd:ID wd:type="ISO_3166-1_Alpha-3_Code">USA</wd:ID>
                                            <wd:ID wd:type="ISO_3166-1_Numeric-3_Code">840</wd:ID>
                                        </wd:Country_Reference>
                                        <wd:First_Name>Logan</wd:First_Name>
                                        <wd:Last_Name>McNeil</wd:Last_Name>
                                    </wd:Name_Detail_Data>
                                </wd:Legal_Name_Data>
                            </wd:Name_Data>
                            <wd:Contact_Data>
                                <wd:Address_Data wd:Effective_Date="2008-03-25" wd:Address_Format_Type="Basic" wd:Formatted_Address="42 Laurel Street&amp;#xa;San Francisco, CA 94118&amp;#xa;United States of America" wd:Defaulted_Business_Site_Address="0">
                                </wd:Address_Data>
                                <wd:Phone_Data wd:Area_Code="415" wd:Phone_Number_Without_Area_Code="441-7842" wd:E164_Formatted_Phone="+14154417842" wd:Workday_Traditional_Formatted_Phone="+1 (415) 441-7842" wd:National_Formatted_Phone="(415) 441-7842" wd:International_Formatted_Phone="+1 415-441-7842" wd:Tenant_Formatted_Phone="+1 (415) 441-7842">
                                </wd:Phone_Data>
                    </wd:Worker_Data>
                </wd:Worker>
            </wd:Response_Data>
        </wd:Get_Workers_Response>
    </env:Body>
</env:Envelope>

This JSON array gives you details of all your employees including details like the name, email, phone number and more.

Use a tool like Postman or curl to POST this XML to your Workday endpoint.

REST Example

If you used REST instead, the same “Get Workers” request would look much simpler:

curl --location 'https://{host}.workday.com/ccx/api/v1/{tenant}/workers' \
--header 'Authorization: Bearer {ACCESS_TOKEN}'

Here, you don’t need XML or SOAP envelopes.
You just pass your OAuth token in the Authorization header.
The response will be in JSON, making it easier to parse in modern applications.

STEP 6: Test your integration in a Workday Sandbox

Before moving your integration to production, it’s always safer to test everything in a sandbox environment. A sandbox is like a practice environment; it contains test data and behaves like production but without the risk of breaking live systems.

Here’s how to use a sandbox effectively:

1. Request a Sandbox

Ask your Workday admin to provide you with a sandbox environment. Specify the type of sandbox you need (development, test, or preview). If you are a Knit customer on the Scale or Enterprise plan, Knit will provide you access to a Workday sandbox for integration testing.

2. Prepare Your Sandbox

Log in to your sandbox and configure it so it looks like your production environment. Add sample company data, roles, and permissions that match your real setup.

3. Create a Test ISU (Integration System User)

Just like in production, create a dedicated ISU account in the sandbox. Assign it the necessary permissions to access the required APIs.

4. Register Your App for Secure Calls

Register your application inside the sandbox to get client credentials (Client ID & Secret). These credentials will be used for secure API calls in your test environment.

5. Run Tests

Use tools like Postman or cURL to send test requests to the sandbox. Test different scenarios (e.g., creating a worker, fetching employees, updating job info). Identify and fix errors before deploying to production.

6. Monitor and Debug

Use Workday’s built-in logs to track API requests and responses. Look for failures, permission issues, or incorrect payloads. Fix issues in your code or configuration until everything runs smoothly.

STEP 7: Move your integration to Workday production

Once your integration has been thoroughly tested in the sandbox and you’re confident that everything works smoothly, the next step is moving it to the production environment. To do this, you need to replace all sandbox details with production values. This means updating the URLs to point to your production Workday tenant and switching the ISU (Integration System User) credentials to the ones created for production use.

When your integration is live, it’s important to make sure you can track and troubleshoot it easily. Setting up detailed logging will help you capture every API request and response, making it much simpler to identify and fix issues when they occur. Alongside logging, monitoring plays a key role. By keeping track of performance metrics such as response times and error rates, you can ensure the integration continues to run smoothly and catch problems before they affect your workflows.

If you’re using Knit, you also get the advantage of built-in observability dashboards. These dashboards give you real-time visibility into your live integration, making debugging and ongoing maintenance far easier. With the right preparation and monitoring in place, moving from sandbox to production becomes a smooth and reliable process.

A note on PECI (Payroll Effective Change Interface)

PECI (Payroll Effective Change Interface) lets you transmit employee data changes (like new hires, raises, or terminations) directly to your payroll provider, slashing manual work and errors. Below you will find a brief comparison of PECI and Web Services and also the steps required to setup PECI in Workday

Feature: PECI

Data Flow: Outbound
Use Cases: READ
Country Scope: Some limit
Setup: Usually Advanced

Feature: Web Services

Data Flow: Inbound and Outbound
Use Cases: CREATE, UPDATE, DELETE
Country Scope: Global
Setup: Usually Programmatic, Flexible

PECI set up steps :-

Enable PECI: Talk to your Workday admin and get PECI activated for your tenant.
Set Up Your Payroll Provider: Configure your external payroll system within Workday, including details and data transfer protocols.
Define Your Data: Identify the specific data your payroll provider needs (think employee details, compensation, etc.).
Create an ISU: Just like other integrations, create a special user (ISU) with permissions to access and move payroll data.
Transform Your Data: Set up Workday to transform your data into the format your payroll provider expects. Think of it as translating languages!
Schedule Transfers: Automate the process! Set up a schedule to regularly send payroll changes to your provider (e.g., daily or after each payroll run).
Test It Out: Before going live, use the Workday sandbox to thoroughly test the PECI integration. Make sure all changes get sent correctly.
Monitor & Maintain: Keep an eye on things! Regularly monitor the integration and use Workday's reports to track data transfers and fix any errors.

Webhooks in Workday

Workday does not natively support real-time webhooks. This means you can’t automatically get notified whenever an event happens in Workday (like a new employee being hired or someone’s role being updated). Instead, most integrations rely on polling, where your system repeatedly checks Workday for updates. While this works, it can be inefficient and slow compared to event-driven updates.

How Knit Helps with Virtual Webhooks

This is exactly where Knit Virtual Webhooks step in. Knit simulates webhook functionality for systems like Workday that don’t offer it out of the box.

Knit continuously monitors changes in Workday (such as employee updates, terminations, or payroll changes). When a change is detected, it instantly triggers a virtual webhook event to your application. This gives you real-time updates without having to build complex polling logic.

For example: If a new hire is added in Workday, Knit can send a webhook event to your product immediately, allowing you to provision access or update records in real time — just like native webhooks.

Things to keep in mind for Workday Integration security

Craft Security Groups: In Workday Security, create a security group specifically tailored for your integration. Think of it as a club with specific access rules.
Set Up Security Policies: Define security policies to control how data can be accessed and modified. Assign these policies to your security group for an extra layer of protection.
Assign Permissions Wisely: Adopt a least privilege policy. Add the necessary permissions to your security group. Make sure your ISU has access to everything it needs, but nothing it doesn't.
Activate & Audit: Activate your newly defined security policies and regularly review their effectiveness. Conduct security audits to ensure everything is running smoothly.
Store Secrets Safely: Keep sensitive info like client secrets in environment variables, not in your code.
Encryption is Key: Encrypting credentials for added protection is a must for integration.
Rotate Regularly: Keep changing credentials periodically to reduce risk.

Troubleshooting common issues with Workday Integration

Getting stuck with errors can be frustrating and time-consuming. Although many times we face errors that someone else has already faced, and to avoid giving in hours to handle such errors, we have put some common errors below and solutions to how you can handle them.‍

Authentication Woes:
- Error Message: "Invalid client ID or secret."
- Possible Solution: Double-check your OAuth setup. Are your client ID, secret, and redirect URLs all correct? Ensure your tokens aren't expired!
Permission Denied:
- Error Message: "Access denied!"
- Possible Solution: Verify your ISU has the right permissions. Check security group settings and policies. It might not have the key to the data vault!
Data Mismatch Blues:
- Error Message: "Incorrect or missing data fields."
- Possible Solution: Ensure your data mappings are on point and match Workday's data model. Validate your input data before making those API calls. Garbage in, garbage out!
Rate Limiting Roadblock:
- Error Message: "Whoa there! Too many requests!"
- Possible Solution: Implement throttling and retry logic in your integration. Respect Workday's API rate limits – don't be a data hog!

Tips for Integrating with Workday’s API

Integrating with Workday can unlock huge value for your business, but it also comes with challenges. Here are some important best practices to keep in mind as you build and maintain your integration.

1. Choose the Right Authentication Method

Workday supports two main authentication methods: ISU (Integration System User) and OAuth 2.0. The choice between them depends on your security needs and integration goals.

ISU (Integration System User):
This method allows you to create a dedicated system account with specific permissions. It’s great when you want granular access control based on Workday roles. Every action is tied to this system user, making activity easy to track.
OAuth 2.0:
OAuth is more flexible and widely used across platforms. It lets you define scopes (what the integration can and cannot do), which reduces risk by limiting access. OAuth is especially useful for REST APIs and when you need user-specific permissions or dynamic access. It’s also an industry standard, making it easier to integrate with other systems.

2. Plan Your Go-to-Market Strategy

If your integration is customer-facing, don’t just focus on building it , think about how you’ll launch it. A Workday integration can be a major selling point, and many customers will expect it.

Before going live, align on:

How it will be priced (part of the product or an add-on).
How it will be supported (customer support and documentation).
How it will be marketed (website, sales demos, case studies).
How it will be demoed (showing real-life workflows).

This ensures your team is ready to deliver value from day one and can even help close deals faster.

3. Consider Outsourcing for Reliability

Building and maintaining a Workday integration completely in-house can be very time-consuming. Your developers may spend months just scoping, coding, and testing the integration. And once it’s live, maintenance can become a headache.

For example, even a small change , like Workday returning a value in a different format (string instead of number) , could break your integration. Keeping up with these edge cases pulls your engineers away from core product work.

A third-party integration platform like Knit can solve this problem. These platforms handle the heavy lifting , scoping, development, testing, and maintenance , while also giving you features like observability dashboards, virtual webhooks, and broader HRIS coverage. This saves engineering time, speeds up your launch, and ensures your integration stays reliable over time.

How can Knit help you with Workday API Integration?

We know you're here to conquer Workday integrations, and at Knit (rated #1 for ease of use as of 2025!), we're here to help! Knit offers a unified API platform which lets you connect your application to multiple HRIS, CRM, Accounting, Payroll, ATS, ERP, and more tools in one go.‍

Advantages of Knit for Workday Integrations

Unified APIs: Interact with multiple HRIS systems (including Workday) via a single REST interface.
Developer-Friendly: Clear documentation, fewer complexities.
Scalability: Designed to handle high-volume data flows.
Support & Reliability: Helpful support team, robust error handling.

Getting Started with Knit

Sign Up for a Knit account.
Connect Workday: Provide your Workday tenant details.
Leverage Unified API: Perform typical Workday operations without dealing directly with SOAP.

REST Unified API Approach with Knit

Freed from SOAP complexities.
Straightforward JSON requests.
Centralized platform to manage data from multiple HRIS solutions.‍

‍

Stop building. Start shipping.

Connect your product to Workday in days, not months.

Knit's Unified API abstracts the complexity of Workday SOAP, REST, and RaaS endpoints — your team ships the integration once, and Knit handles auth, versioning, and webhooks.

Book a Demo See Workday Integration

‍

Workday API integration FAQs

Q. What is a Workday integration?

A Workday integration is a connection built between Workday and another system (like payroll, CRM, or ATS) that allows data to flow seamlessly between them. These integrations can be created using APIs, files (CSV/XML), databases, or scripts , depending on the use case and system design.

Q. What is a Workday API integration?

A Workday API integration is a type of integration where you use Workday’s APIs (SOAP or REST) to connect Workday with other applications. This lets you securely access, read, and update Workday data in real time.

Internal integrations: Your company connects Workday with tools you already use (e.g., syncing payroll or performance data).
Customer-facing integrations: Your product connects directly with your customers’ Workday systems (e.g., provisioning employees into your SaaS).

Q. Do Workday integrations require coding?

It depends on your approach.

Custom-built integrations usually require coding, especially when using SOAP or REST directly. Your developers will need to handle authentication, endpoints, and error handling.
Using an iPaaS (Integration Platform as a Service) or an embedded iPaaS/unified API platform like Knit can reduce or even eliminate coding by providing pre-built Workday connectors and simplified endpoints.

Q. What types of APIs does Workday provide?

Workday offers:

SOAP APIs: Traditional, XML-based APIs with strict schemas. Often used for payroll, benefits, and complex workflows.
REST APIs: Modern, lightweight APIs using JSON. Easier to use and more common for real-time SaaS integrations.

Q. What are Workday’s API rate limits?

Workday doesn’t publish all rate limits publicly. Most details are available only to customers or partners. However, some endpoints have documented limits , for example, the Strategic Sourcing Projects API allows up to 5 requests per second. Always design your integration with pagination, retry logic, and throttling to avoid issues. The safest approach is to implement exponential backoff on all retry logic, paginate all list operations regardless of expected result size, and avoid polling intervals shorter than 5 minutes for background sync jobs. If you're consuming Workday data through Knit, rate limit management is handled automatically — Knit spaces requests and retries within Workday's thresholds so your application never hits limits directly.

Q. What are the benefits of integrating with Workday’s API?

Internal integrations: Save time, reduce manual errors, improve employee experience, and boost productivity.
Customer-facing integrations: Help you win more deals, improve customer retention, and expand into new markets (e.g., selling to larger enterprises who expect Workday support).

Q. How do I access a Workday sandbox account?

Workday provides sandbox environments to its customers for development and testing. If you’re a software vendor (not a Workday customer), you typically need a partnership agreement with Workday to get access. Some third-party platforms like Knit also provide sandbox access for integration testing.

Q. How do you authenticate with Workday’s API?

Workday supports two main methods:

Integration System User (ISU): Username and password for a dedicated system account. Easier to manage for non-sensitive integrations.
OAuth 2.0: Modern authentication using tokens. More secure, supports SSO, and enforces least-privilege access. Recommended for most cases, especially customer-facing integrations.

Q. Does Workday offer APIs?

Yes. Workday provides both SOAP and REST APIs, covering a wide range of data domains, HR, recruiting, payroll, compensation, time tracking, and more. REST APIs are typically preferred because they are easier to implement, faster, and more developer-friendly.

Q. Does Workday support API integrations?

Yes. If you are a Workday customer or have a formal partnership, you can build integrations with their APIs. Without access, you won’t be able to authenticate or use Workday’s endpoints.

Q. Does Workday support webhooks?

No, Workday does not natively support outbound webhooks - there is no mechanism to push real-time change events to an external endpoint when an employee record is created, updated, or terminated. The standard alternative is polling: querying Workday's APIs on a schedule (typically every 15–60 minutes) to detect changes. Knit solves this with virtual webhooks — when you connect Workday through Knit, you receive real-time event notifications via webhook whenever data changes in Workday, without needing to build or maintain any polling infrastructure. This is particularly valuable for use cases that require fast response to Workday events, such as automated onboarding workflows triggered by new hires or access revocation triggered by terminations.

Q. How long does it take to build a Workday integration?

A custom Workday integration built directly against Workday Web Services typically takes 4–12 weeks for a single integration, factoring in ISU setup, OAuth configuration, SOAP/REST endpoint selection, data model mapping, error handling, and testing in sandbox before production. That timeline doesn't include ongoing maintenance as Workday releases new API versions. Using Knit's unified API, teams can go from zero to a production Workday integration in 1–3 days - Knit handles authentication, data normalization, rate limiting, and webhook delivery, so your engineering team only needs to integrate once against Knit's normalized API rather than Workday's raw endpoints directly. See https://developers.getknit.dev for implementation guides.

Q: What is a Workday API?

Workday API is a programmatic interface that allows external applications to read and write data in Workday - including employee records, payroll data, org structures, benefits, and time tracking. Workday offers two API types: SOAP-based Web Services (the older, more comprehensive set using XML) and REST APIs (modern, JSON-based, covering a growing set of domains). Both require formal authentication through an Integration System User (ISU) or OAuth 2.0 client. For SaaS products that need to access Workday data on behalf of their customers, Knit provides a unified API that normalizes Workday's data into a consistent schema alongside 100+ other HRIS platforms.

Q: What is the difference between Workday REST API and SOAP API?

Workday's SOAP API (Web Services) is the older, more comprehensive set - it covers virtually every Workday domain including payroll, benefits, and complex HR transactions, uses XML, and requires constructing SOAP envelopes with WS-Security headers. Workday's REST API is newer, uses JSON, supports OAuth 2.0, and is simpler to implement - but it has narrower domain coverage than the full SOAP Web Services suite. For most new integrations, start with the REST API; fall back to SOAP for payroll, compliance-critical operations, or endpoints not yet exposed via REST. Knit abstracts both API types behind a single normalized endpoint, so you don't need to choose or maintain separate implementations.

Q: How much does Workday API integration cost?

Building a Workday integration directly has no per-call API cost from Workday itself - access to the API is included with Workday licenses. The real cost is engineering time: a custom integration typically takes 4–12 weeks of developer time to build and requires ongoing maintenance as Workday updates its API. Third-party tools vary: iPaaS platforms like Workato charge per task or connection; unified APIs like Knit charge per active connection per month, with pricing that covers authentication, data normalization, rate limiting, and webhook delivery. For SaaS teams building customer-facing Workday integrations at scale, unified API pricing is typically more predictable than task-based pricing as connection volume grows.

‍

Q. What’s the difference between PECI and Workday Web Services?

PECI (Payroll Effective Change Interface): Outbound-only, sends payroll-related changes (like hires, raises, terminations) to payroll providers.
‍Workday Web Services (APIs): Inbound + outbound, supports create, update, and delete operations across HR, payroll, recruiting, and more.

Appendix

A. Key Terms

API: Lets applications talk to Workday (RESTful or SOAP).
Authentication: Verifies you're who you say you are (login).
Authorization: Grants access to specific Workday data (permissions).
Client ID & Secret: Uniquely identify your application (secure handshake).
Data Model: Structure of Workday data (like fields in a form).
Endpoint: Specific URL to access Workday functions (like a door to a room).
ISU: Special user for integrations (low access, high security).
OAuth 2.0: Secure way to get temporary access tokens (like a one-time pass).
REST API: Flexible API using regular commands (GET, POST, PUT, DELETE).
Sandbox: Test environment with dummy data (safe zone for experimentation).
SOAP API: Structured API using XML (more complex, more secure).
Token: Temporary permission to access Workday (like a short-term pass).
Workday Tenant: Your company's secure space within Workday (separate for dev, test, production).‍

B. Sample Code

Adapted from Workday API documentation. Remember to replace placeholders like "your_workday_tenant", "isu_username", “isu_password” with your actual details. For comprehensive API reference and code samples, visit the Workday Developer Center

‍

Tutorials

Resources to get you started on your integrations journey

Tutorials

Jul 23, 2026

Use Cases

Learn how to build your specific integrations use case with Knit

Use Cases

Jul 1, 2026

How Interview Scheduling Companies Can Scale ATS Integrations 10X Faster

Interview scheduling companies play an integral role in helping their partner organizations hire the right talent by streamlining the candidate communication and end-to-end interview process.

The first step towards smooth interviews is getting a pool of candidates to choose from. Here, most companies rely on ATS or Application Tracking Systems to pull in candidate and job data.

While building and maintaining all the ATS integrations is a tedious and resource-intensive process, it can be made simpler and faster with unified ATS APIs. We will get to that, first let’s look at all the use cases you can enable with ATS integrations.

‍

• ATS integration in interview scheduling workflow

• ATS integration challenges

• How interview scheduling companies can 10X their growth with unified ATS API

• What else do you get with Knit Unified API?

• FAQs

ATS integration in interview scheduling workflow

Let’s quickly look at how ATS APIs can streamline the interview scheduling workflow.

Step I: Integration setup

Essentially, the first step is to get the ATS integration in place leveraging popular ATS APIs. As an interview scheduling company, you can choose the appropriate approach to ATS integration via in-house integration building, embedded iPaaS, unified API or workflow automation tools.

Read: Build vs Buy: Best way to build product integrations

Step II: Data synchronization

Once the integration setup is complete, data synchronization regarding the job requisition, interview schedule, candidate information can be commenced.

This will ensure that whenever data from a new candidate is entered in the ATS, the interview scheduling company gets an automated alert to initiate the next steps to set up the interview and following processes.

The right ATS integration approach will ensure that the interview scheduling company receives new candidate alerts automatically, without pushing for updates.

Read:How Candidate Screening Tools Can Build 30+ ATS Integrations in Two Days

Step III: Calendar and interview slot coordination

ATS APIs can help interview scheduling companies with real-time calendar and interview slot coordination. Once the applicant profile screening is complete and the profile has been shortlisted in the ATS, the interview scheduling company can automatically capture this update directly from the ATS app and identify potential slots for the interview based on the calendar availability for the candidate and the interviewer.

Step IV: Candidate communication

Once the interview slot has been decided, the interview scheduling company can extract ATS API data to automate interview invitations and reminders and even personalize candidate communication as per the role, position and context.

The same information about the communication will be automatically updated in the ATS to ensure that the hiring organization using the API has a clear picture of the candidate status.

Step V: Real time candidate status update

As soon as the interview is complete, the ATS API enables the interview scheduling company to update candidate status in real time.

For instance, Knit WRITE APIs enable you to update candidate status about whether or not the candidate appeared for the interview, status in the interview process (selected, rejected, moved to next round, add notes etc.). See docs

This information is then reflected in real time in the ATS to help the HR and hiring managers understand where they stand for that particular position and whether they need to source more applications.

Step VI: Interview feedback and evaluation

In addition to the status update, the ATS integration also enables the interview scheduling company to provide a detailed feedback and evaluation of the interview which can be captured directly in the ATS.

In case the hiring organization prefers, they can share it with the candidate or keep it in their ATS records for future reference.

Step VII: HR analytics

Finally, the ATS integration can help interview scheduling companies capture key hiring metrics and facilitate HR analytics.

For instance, the integration can help capture the metrics including Application-to-Interview Conversion Rate, Interview Scheduling Efficiency, Interview-to-Hire Ratio, Time-to-Fill (TTF), Time-to-Hire (TTH), Offer Acceptance Rate, etc.

Data from these metrics can help identify the gaps in the hiring process and facilitate better outcomes.

ATS integration challenges

While scaling ATS integrations is crucial for any interview scheduling companies to close more deals, building and maintaining ATS integrations is not easy. Here’s why most companies struggle with scaling their integration efforts:

1. Data compatibility issues

First, different ATS applications use different data fields, models and nuances, which may or may not be compatible with other ATS or even with the data models being used by the interview scheduling company.

This can lead to data compatibility issues leading to larger bandwidth requirements to understand and use different ATS APIs, with the danger of data corruption as well.

2. Candidate data sensitivity during transfer

Second, since both sides of the data transfer contain sensitive candidate information, the ATS integration must have robust security measures for authorization and authentication as well as others like rate limiting etc. to prevent unauthorized access or DDoS attacks, among others.

With policies like GDPR and most recently the Digital Personal Data Protection (DPDP) law (in India), any data misuse can lead to serious repercussions, especially because ATS and hiring processes use a lot of personal candidate data.

3. Engineering and maintenance costs with increasing number of ATS being used

Third, as you scale and onboard more customers, you will be bound to further ATS integrations to their preferred ATS application.

The engineering and maintenance costs associated with adding more ATS applications scale with each new platform you support — every additional ATS means another authentication flow, data model, and set of API quirks to build and maintain in-house. For a team supporting dozens of ATS platforms across customers, this overhead compounds quickly.

This can dilute your engineering team's bandwidth from focusing on the core product. Scalability with the growing number of ATS applications to be added can pose a resource and cost challenge.

4. Vendor (ATS) coordination and cooperation

In addition to the engineering costs, scaling ATS integrations also comes with additional coordination and cooperation with the ATS vendors.

When you are building and managing ATS integrations in-house you have to take care of coordinating with every ATS vendor in case of any error or challenge in data transfer, security, etc. This can be highly time consuming and counter productive.

5. Limited real time update capabilities

Next, if you use a polling infrastructure to power your ATS integration, you will need to take care of the heavy lifting of polling data from ATS applications, dealing with different API calls and rate limits.

Invariably, this will prevent you from accessing data in real time as soon as there is any update in candidate information or a new candidate is onboarded to the system. This can lead to delays in interview scheduling and missed opportunities.

How interview scheduling companies can 10X their growth with unified ATS API

While there are certain operational challenges to using ATS integrations, unified APIs like Knit, can help address all such challenges and even achieve 10X growth.

Centralized data management with one data model

Knit periodically pulls data from all connected ATS platforms and processes the data coming from different platforms in different formats to convert them to one unified data model.

The heavy lifting of pulling data from various ATS apps, dealing with different API calls, rate limits, formats etc are completely taken care of by Knit.

Real-time data sync for higher productivity

Depending on the infrastructure used, your data sync frequencies can be set. A webhook driven architecture will facilitate real time data sync without requiring you to initiate polling.

For instance, Knit, having a 100% event-driven webhook architecture, refreshes data in real time by periodically pulling data from all connected ATS platforms and processes the data coming from different platforms in different formats to convert them to our unified model. As a result, you won’t have to manage any polling infrastructure on your end or worry about missing any critical data update.

Faster time to market with quick deployment

Adding an ATS integration can take anywhere from a few weeks to several months. But, with a unified API, you can add multiple ATS integrations in as little as one day.

This quick deployment ensures that you are able to leverage the benefits of ATS integration faster.

Easy scalability to integrate with multiple ATS APIs in one go

Not only is deployment faster with unified API, it also supports accelerated and unlimited scalability. You can connect with various ATS applications in one go.

For example, as an interview scheduling company, you can simply embed the Knit’s UI component in your frontend to get access to the full catalog of 30+ ATS applications, regardless of the auth type, credentials, nuances for the application.

All credential management, verification, token generations become the responsibility of Knit in this case.

Not only that, each time a new app is integrated to the Knit’s ATS API category, you get immediate access and sync capabilities with the new app without writing a single line of code. Get your Knit unified ATS API key now! (Start for free)

Better reporting and analytics to manage integrations seamlessly

Reporting and analytics with a unified API like Knit can help facilitate high customer satisfaction.

For instance, Knit allows interview scheduling companies to monitor and manage the health of all ATS integrations for each connected customer using a detailed Logs, Issues, Integrated Accounts and Syncs page.

Companies can keep track of all API calls, data syncs and requests made by users as well as status of each webhook registered on a single dashboard.

Enhanced security

A unified API helps interview scheduling companies facilitate better security and data privacy.

For instance, Knit fosters double encryption for data—when it is at rest as well as when it is in transit.

At the same time, most unified APIs comply with the key security protocols such as HIPAA, SOC2, GDPR etc and ensure constant monitoring with top intrusion detection systems. A unified API generally supports all forms of authentication like OAuth, API key or a username-password based authentication.

Note: As a unified API, Knit goes a step further to promote end user security. Knit is the only unified API which considers your data sacrosanct and doesn’t store a copy of your data. The syncs happen over a 100% webhook-based architecture for enhanced data security. Furthermore, an additional layer of application security protects and prevents all PII from any security vulnerabilities. Learn more

Expand market reach and serve more customers

By providing instant ATS integration with multiple ATS applications, interview scheduling companies can leverage unified APIs to expand their market reach and acquire new customers.

They no longer have to worry about missed opportunities or make their prospects wait till they are able to build new ATS integrations.

This allows interview scheduling companies to close deals faster and serve a higher number of customers, leading to increased revenue and greater profitability.

What else do you get with Knit Unified API?

Interview scheduling companies using Knit as their unified API for ATS integration automatically retrieve new applications from all connected ATS platforms.

Knit pulls the data and sends the relevant data to the interview scheduling tool, reducing the need for making API calls or manually starting data syncs. Owing to the webhooks architecture, Knit ensures high scalability and delivery, irrespective of the data load.

You control when data syncs happen

While Knit supports real time data sync, it also allows users to control when syncs happen, which can be set by the CX team directly from the dashboard, without involving engineering resources.

Furthermore, filters can be set on the information being retrieved from the source system to only consume the relevant data to save network cost and storage cost.

Get started with ATS APIs

Staying on top of ATS integrations can be overwhelming and time consuming due to the sheer number of the ATS APIs available in the market today.

Knit helps you integrate with 30+ ATS and HR applications with a single unified API. Plus, we have built Knit with a developer friendly setup which requires minimal coding and maximum onboarding support.

If you want to know more about Knit, talk to one of our experts or try our unified ATS API yourself, today. (Getting started is completely free)

‍

FAQs

What is ATS integration?

ATS integration is the process of connecting an Applicant Tracking System with other software — such as interview scheduling tools, sourcing platforms, or HRIS systems — so candidate, job, and application data flows between them automatically. Knit provides a unified ATS API that connects to 30+ ATS platforms through one integration, so an interview scheduling product can pull candidate and interview-stage data from whichever ATS a customer uses, and push scheduling updates back, without building a separate connection per platform. Without integration, this data has to be entered or updated manually in each system, which is slow and error-prone at scale.

What does ATS stand for?

ATS stands for ApplicantTracking System — software that recruiting teams use to post jobs, collectapplications, move candidates through interview stages, and manage offers.Examples include Greenhouse, Lever, Workday, and BambooHR. For an interview schedulingcompany, the ATS is the system of record for candidate and interview data —it's where interview stages, interviewer panels, and scheduling statustypically live. Knit's unified ATS API connects to 30+ of these platformsthrough a single integration, normalizing each one's data model into aconsistent format so a scheduling product doesn't need separate logic per ATS.

How much does it cost to build an ATS integration?

Building and maintaining a direct integration with a single ATS typically involves implementing OAuth, mapping that ATS's specific data model, and handling its rate limits and webhook support (or lack of it) — work that scales linearly with each additional ATS a product needs to support. Knit's unified ATS API removes most of this per-platform work: one integration gives an interview scheduling product access to 30+ ATS platforms through a single data model and authentication flow, with Knit handling token refresh and platform-specific quirks. The ongoing maintenance burden — adapting to each ATS's API changes — also shifts from your team to Knit's integration layer.

What ATS platforms are most commonly used by interview scheduling tools?

Interview scheduling tools most often need to integrate with the ATS platforms their customers already use for hiring — commonly Greenhouse, Lever, Workday, BambooHR, JazzHR, and Jobvite, alongside enterprise systems like SAP SuccessFactors and Oracle Taleo. Because customer bases are rarely standardized on one ATS, scheduling products typically need broad coverage rather than a single integration. Knit's unified ATS API covers 30+ of these platforms — including Greenhouse, Lever, Workday, BambooHR, and Jobvite — through one set of endpoints, so a scheduling tool can support whichever ATS a given customer runs without building platform-specific code for each one.

How does ATS integration improve interview scheduling?

ATS integration lets aninterview scheduling tool automatically pull candidate details, jobrequisitions, and interview stage information directly from the ATS, instead ofrecruiters re-entering this data manually. Knit's unified ATS API delivers thisdata in real time via webhooks, so when a candidate moves to an interview stagein the ATS, the scheduling tool is notified immediately and can triggeravailability checks and calendar invites. Scheduling outcomes — confirmedinterview times, interviewer assignments, feedback — can then be written backto the ATS through Knit's write APIs, keeping the recruiter's view of thepipeline current.

Is candidate data secure when it's synced between an ATS and a scheduling tool?

Knit encrypts candidate data both at rest (AES-256) and in transit (TLS 1.3), with an additional layer of application-level encryption applied specifically to personally identifiable information. Knit is SOC 2, GDPR, and ISO 27001 compliant, and uses a pass-through architecture that avoids storing a persistent copy of customer data. For interview scheduling tools, this matters because syncing candidate names, contact details, and interview feedback between systems involves personal data subject to regulations like GDPR — so the integration layer connecting your scheduling tool to a customer's ATS needs its own verifiable security posture.

Can a scheduling tool get real-time updates when an interview stage changes in the ATS?

Yes — this is one of the main benefits of an event-driven ATS integration. Knit's unified ATS API runs on a webhook-based architecture, so when a candidate's stage changes in the ATS —moved to "Interview", rejected, or advanced to offer — your scheduling tool receives that event in near real time instead of polling the ATS on a schedule. For ATS platforms that don't natively support outbound webhooks, Knit provides virtual webhooks that replicate the same event-driven experience, so your scheduling product doesn't need different logic depending on which ATS a customer connects.

How long does it take to add ATS integration to an interview scheduling product?

With Knit's unified ATS API, an interview scheduling product can get a working integration connected to a given ATS in as little as a day for straightforward setups, since Knit handles authentication, data normalization, and webhook delivery for 30+ ATS platforms out of the box. The exact timeline depends on how deeply the integration needs to map into your scheduling logic — for example, two-way sync of interview feedback or custom field mapping adds development work on your side. Knit's documentation at developers.getknit.dev covers the unified data models and read/write endpoints needed to plan that scope.

‍

Use Cases

Jul 1, 2026

How Candidate Screening Tools Can Build 30+ ATS Integrations in Two Days

If you want to unlock 30+ ATS integrations with a single API key, check out Knit API

With the rise of data-driven recruitment, it is imperative for each recruitment tool, including candidate sourcing and screening tools, to integrate with Applicant Tracking Systems(ATS) for enabling centralized data management for end users.

However, there are hundreds of ATS applications available in the market today. To integrate with each one of these applications with different ATS APIs is next to impossible.

That is why more and more recruitment tools are looking for a better (and faster) way to scale their ATS integrations. Unified ATS APIs are one such cost-effective solution that can cut down your integration building and maintenance time by 80%.

Before moving on to how companies can leverage unified ATS API to streamline candidate sourcing and screening, let's look at the workflow and how ATS API helps.

‍

• Candidate sourcing and screening workflow

• How ATS API helps streamline candidate sourcing andscreening

• Addressing challenges of ATS API integration withUnified API

• Other benefits of using a Unified ATS API

• How to improve your screening workflow with Knitunified ATS API

• FAQs

‍

Candidate sourcing and screening workflow

Here’s a quick snapshot of the candidate sourcing and screening workflow:

1) Job posting/ data entry from job boards

Posting job requirements/ details about open positions to create widespread outreach about the roles you are hiring for.

2) Candidate sourcing from different platforms/ referrals

Collecting and fetching candidate profiles/ resumes from different platforms—job sites, social media, referrals—to create a pool of potential candidates for the open positions.

3) Resume parsing

Taking out all relevant data—skills, relevant experience, expected salary, etc. —from a candidate’s resume and updating it based on the company’s requirement in a specific format.

4) Profile screening

Eliminating profiles which are not relevant for the role by mapping profiles to the job requirements.

5) Background checks

Conducting a preliminary check to ensure there are no immediate red flags.

6) Assessment, testing, interviews

Setting up and administering assessments, setting up interviews to ensure role suitability and collating evaluation for final decision making.

7) Selection

Sharing feedback and evaluation, communicating decisions to the candidates and continuing the process in case the position doesn’t close.

How ATS API helps streamline candidate sourcing and screening

Here are some of the top use cases of how ATS API can help streamline candidate sourcing and screening.

Centralized data management and communication

All candidate details from all job boards and portals can be automatically collected and stored at one centralized place for communication and processing and future leverage.

Automated profile import

ATS APIs ensure real time, automated candidate profile import, reducing manual data entry errors and risk of duplication.

Customize screening workflows

ATS APIs can help automate screening workflows by automating resume parsing and screening as well as ensuring that once a step like background checks is complete, assessments and then interview set up are triggered automatically.

Automated candidate updates within the ATS in real time

ATS APIs facilitate real time data sync and event-based triggers between different applications to ensure that all candidate information available with the company is always up to date and all application updates are captured ASAP.

Read:How to Automate Recruitment Workflows with ATS APIs and Hire Smarter

Candidate engagement data, insights and patterns using ATS data

ATS APIs help analyze and draw insights from ATS engagement data — like application rate, response to job postings, interview scheduling — to finetune future screening.

Integrations with assessment, interview scheduling and onboarding applications

ATS API can further integrate with other assessment, interview scheduling and onboarding applications enabling faster movement of candidates across different recruitment stages.

Personalized outreach based on historical ATS data

Undoubtedly, using ATS API integration can effectively streamline the candidate sourcing and screening process by automating several parts of the way. However, there are several roadblocks to integrating ATS APIs at scale, which is why many companies hold off on building this out themselves.

In the next section, we'll look at how a unified ATS API solves these common roadblocks for SaaS products looking to scale their ATS integration strategy.

‍

Undoubtedly, using ATS API integration can effectively streamline the candidate sourcing and screening process by automating several parts of the way. However, there are several roadblocks to integrating ATS APIs at scale because of which companies refrain from leveraging the benefits that come along. Try our ROI calculator to see how much building integrations in-house can he.

In the next section we will discuss how to solve the common challenges for SaaS products trying to scale and accelerate their ATS integration strategy.

Addressing challenges of ATS API integration with Unified API

Let's discuss how the roadblocks can be removed with unified ATS API: just one API for all ATS integrations. Learn more about unified APIs here

Challenge 1: Loss of data during data transformation

When data is being exchanged between different ATS applications and your system, it needs to be normalized and transformed. Since the same details from different applications can have different fields and nuances, chances are if not normalized well, you will end up losing critical data which may not be mapped to specific fields between systems.

This will hamper centralized data storage, initiate duplication and require manual mapping not to mention screening workflow disruption. At the same time, normalizing each data field from each different API requires developers to understand the nuances of each API. This is a time and resource intensive process and can take months of developer time.

How unified ATS API solves this: One data model to prevent data loss

Unified APIs like Knit help companies normalize different ATS data by mapping different data schemas from different applications into a single, unified data model for all ATS APIs. Data normalization takes place in real time and is almost 10X faster, enabling companies to save tech bandwidth and skip the complex processes that might lead to data loss due to poor mapping.

Bonus: Knit also offers an custom data fields for data that is not included in the unified model, but you may need for your specific use case. It also allows you to request data directly from the source app via its Passthrough Request feature. Learn more

Challenge 2: Delayed recruitment due to inability of real-time sync and bulk transfers

Second, some ATS API integration has a polling infrastructure which requires recruiters to manually request candidate data from time to time. This lack of automated data updation in real time can lead to delayed sourcing and screening of applicants, delaying the entire recruitment process. This can negatively impact the efficiency that is expected from ATS integration.

Furthermore, Most ATS platforms receive 1000s of applications in a matter of a few minutes. The data load for transfer can be exceptionally high at times, especially when a new role is posted or there is any update.

As your number of integrated platforms increases, managing such bulk data transfers efficiently as well as eliminating delays becomes a huge challenge for engineering teams with limited bandwidth

How unified ATS API solves this: Sync data in real-time irrespective of data load/ volume

Knit as a unified ATS API ensures that you don’t lose out on even one candidate application or be delayed in receiving them. To achieve this, Knit works on a webhooks based system with event-based triggers. As soon as an event happens, data syncs automatically via webhooks.

Read: How webhooks work and how to register one?

Knit manages all the heavy lifting of polling data from ATS apps, dealing with different API calls, rate limits, formats etc. It automatically retrieves new applications from all connected ATS platforms, eliminating the need to make API calls or manual data syncs for candidate sourcing and screening.

At the same time, Knit comes with retry and resiliency guarantees to ensure that no application is missed irrespective of the data load. Thus, handling data at scale.

This ensures that recruiters get access to all candidate data in real time to fill positions faster with automated alerts as and when new applications are retrieved for screening.

Challenge 3: Compliance and candidate privacy concerns

Since the ATS and other connected platforms have access to sensitive data, protecting candidate data from attacks, ensuring constant monitoring and right permission/ access is crucial yet challenging to put in practice.

How unified ATS API solves this: Secure candidate data effectively

Knit unified ATS API enables companies to effectively secure the sensitive candidate data they have access to in multiple ways.

First, all data is doubly encrypted, both at rest and in transit. At the same time, all PII and user credentials are encrypted with an additional layer of application security.

Second, having an events-driven webhooks architecture, Knit is the only unified ATS API which does not store any copy of the customer data in its server. Thus, reducing changes of data misuse further.

Third, Knit is GDPR, SOC II and ISO27001 compliant to make sure all industry security standards are met. So, there’s one less thing for you to worry about.

Challenge 4: Long deployment duration and resource intensive maintenance

Finally, ATS API integration can be a long drawn process. It can take 2 weeks to 3 months and thousands of dollars to build integration with just a single ATS provider.

With different end points, data models, nuances, documentation etc. ATS API integration can be a long deployment project, diverting away engineering resources from core functions.

It’s not uncommon for companies to lose valuable deals due to this delay in setting up customer requested ATS integrations.

Furthermore, the maintenance, documentation, monitoring as well as error handling further drains engineering bandwidth and resources. This can be a major deterrent for smaller companies that need to scale their integration stack to remain competitive.

How unified ATS API solves this: Instant scalability

A unified ATS API like Knit allows you to connect with 30+ ATS platforms in one go helping you expand your integration stack overnight.

All you have to do is embed Knit’s UI component into your frontend once. All heavy lifting of auth, endpoints, credential management, verification, token generations, etc. is then taken care of by Knit.

Other benefits of using a Unified ATS API

Fortunately, companies can easily address the challenges mentioned above and streamline their candidate sourcing and screening process with a unified ATS API. Here are some of the top benefits you get with a unified ATS API:

Effective monitoring and logging for all APIs

Once you have scaled your integrations, it can be difficult to monitor the health of each integration and stay on top of user data and security threats. Unified API like Knit provides a detailed Logs and Issues dashboard i.e. a one page overview of all your integrations, webhooks and API calls. With smart filtering options for Logs and Issues, Knit helps you get a quick glimpse of the API's status, extract historical data and take necessary action as needed.

Extensive range of Read and Write APIs

Along with Read APIs, Knit also provides a range of Write APIs for ATS integrations so that you can not only fetch data from the apps, you can also update the changes — updating candidate’s stage, rejecting an application etc. - directly into the ATS application's system. See docs

Save countless developer hours and cost

For an average SaaS company, each new integration can take anywhere from six weeks to three months to build and deploy, with ongoing maintenance typically requiring a minimum of 10 developer hours per week per integration. Multiply that across 30+ ATS platforms - or 200, if your customer base needs it - and the in-house build-and-maintain workload adds up quickly, both in direct engineering time and in opportunity cost.

A unified ATS API like Knit absorbs most of this cost by maintaining the connections to its full catalog of ATS platforms centrally - you integrate once and get access to all of them, with Knit handling ongoing maintenance as each ATS updates its own API.

In short, an API aggregator is non negotiable if you want to scale your ATS integration stack without compromising valuable in-house engineering bandwidth.

‍

How to improve your screening workflow with Knit unified ATS API

Get Job details from different job boards

Fetch job IDs from your users Applicant Tracking Systems (ATS) using Knit’s job data models along with other necessary job information such as departments, offices, hiring managers etc.

Get applicant details

Use the job ID to fetch all and individual applicant details associated with the job posting. This would give you information about the candidate such as contact details, experience, links, location, experience, current stage etc. These data fields will help you screen the candidates in one easy step.

Complete screening activities

Next is where you take care of screening activities on your end after getting required candidate and job details. Based on your use case, you parse CVs, conduct background checks and/or administer assessment procedures.

Push back results into the ATS

Once you have your results, you can progmmatically push data back directly within the ATS system of your users using Knit’s write APIs to ensure a centralized, seamless user experience. For example, based on screening results, you can —

Update candidate stage using <update stage> API See docs
Match scores for CV parsing or add a quick tag to your applicant See docs
Reject an application See docs and much more

Thus, Knit ensures that your entire screening process is smooth and requires minimum intervention.

‍

Get started with Unified ATS API

If you are looking to quickly connect with 30+ ATS applications — including Greenhouse, Lever, Jobvite and more — get your Knit API keys today.

You may talk to our one of our experts to help you build a customized solution for your ATS API use case.

The best part? You can also make a specific ATS integration request. We would be happy to prioritize your request.

‍

Related reading: How to Automate Recruitment Workflows with ATS APIs and Hire Smarter · How Interview Scheduling Companies Can Scale ATS Integrations 10X Faster · ATS Integration Guide

‍

FAQs

What is an ATS API?

An ATS API is the interface that an Applicant Tracking System exposes so other software can read and write recruiting data — things like job postings, candidate profiles, resumes, and application status. Knit provides a unified ATS API that sits on top of 30+ individual ATS APIs, so a candidate screening tool can pull job and applicant data through one consistent endpoint instead of learning each platform's API separately. Most ATS APIs use REST endpoints with OAuth-based authentication, and data models vary significantly between providers — a Greenhouse candidate object, for example, doesn't look like a Workday one, which is exactly the normalization problem a unified API is built to solve.

What are ATS integrations?

ATS integrations are connections that let an Applicant Tracking System share candidate, job, and application data with other tools — sourcing platforms, assessment providers, interview schedulers, HRIS systems, and screening software. For a candidate screening tool, this typically means pulling new applicant profiles and job requisitions from the ATS, and pushing screening results (stage updates, tags, rejections) back. Knit's unified ATS API handles this two-way sync for 30+ ATS platforms through a single integration, including authentication, data normalization, and real-time updates via webhooks, so screening tools don't have to build and maintain a separate connection for every ATS their customers use.

What is the difference between an ATS and a CRM?

An ATS (Applicant Tracking System) manages the hiring pipeline for open roles — job postings, applications, resume screening, interview stages, and offers. A CRM (Candidate Relationship Management or, in sales contexts, Customer Relationship Management) is built for ongoing relationship management, such as nurturing a talent pool of passive candidates before a role even opens, or managing sales leads. In recruiting, some platforms blend both: an ATS handles active requisitions while a recruiting CRM manages the broader talent pipeline. For a candidate screening tool, the ATS is usually the primary data source, and Knit's ATS API connects to 30+ of these platforms to retrieve that data in one normalized format.

What ATS platforms are most commonly used?

Widely used ATS platforms span from enterprise systems like Workday, Oracle Taleo, SAP SuccessFactors, and iCIMS to recruiting-focused tools like Greenhouse, Lever, JazzHR, and Workable, plus regional platforms like BambooHR, Zoho Recruit, and JobAdder. Which ATS a company uses often depends on its size, industry, and region — there's no single dominant platform across all markets. This fragmentation is the core challenge for candidate screening tools that need to support multiple customers, each potentially on a different ATS. Knit's unified ATS API currently covers 30+ of these platforms — including Greenhouse, Lever, Workday, BambooHR, and Jobvite — through one integration.

How does an ATS API improve candidate screening accuracy?

Knit's ATS API improves screening accuracy by replacing manual data entry with automated, real-time sync — candidate profiles, resumes, and job requirements flow directly from the ATS into the screening tool in a consistent format, removing the copy-paste errors and missed updates that come with manual handoffs. Because Knit normalizes data from every connected ATS into one schema, a screening tool's matching logic works against the same fields regardless of which ATS a customer uses, rather than handling 30+ different data structures. Screening results — stage updates, tags, scores — can then be written straight back into the ATS via Knit's write APIs, keeping recruiters' view of candidates current.

Is candidate data secure when synced through an ATS API?

Knit encrypts candidate data both at rest (AES-256) and in transit (TLS 1.3), with an additional layer of application-level encryption for PII specifically. Knit is SOC 2, GDPR, and ISO 27001 compliant, and operates on a pass-through architecture — it doesn't store a persistent copy of customer data on its servers, syncing instead via a webhook-based model. For candidate screening tools, this matters because applicant data (resumes, contact details, background check results) is sensitive personal data under regulations like GDPR, so the security posture of any integration layer between your tool and your customers' ATS platforms is a real due-diligence question.

Can a screening tool connect to multiple ATS platforms with one integration?

Yes — this is the core use case for a unified ATS API. Instead of building and maintaining 30 separate integrations, one per ATS your customers use, a candidate screening tool can embed Knit's unified API once and get access to 30+ ATS platforms — including Greenhouse, Lever, Workday, BambooHR, and Jobvite — through a single set of endpoints and one data model. Knit handles the authentication flow, credential storage, and data normalization differences for each platform, and new ATS platforms added to Knit's catalog become available to your tool automatically, without additional engineering work on your side.

Does Knit support real-time candidate updates from the ATS?

Yes. Knit runs on a 100% event-driven, webhook-based architecture, so when a new candidate applies or an application status changes in a connected ATS, your screening tool receives that update in near real time without polling. This matters for screening workflows because delays in picking up new applicants directly translate to slower time-to-screen. For ATS platforms that don't natively support outbound webhooks, Knit provides virtual webhooks — it handles the underlying polling and delivers the same event-driven experience, so your integration code doesn't need to know which ATS platforms support webhooks natively and which don't.

How do I get started with Knit's ATS API?

You can sign up for a Knit account and get an API key for free to start testing against Knit's unified ATS API, which covers 30+ ATS platforms through one set of endpoints. Knit's documentation at developers.getknit.dev covers authentication, the unified data models for jobs, candidates, and applications, and both read and write endpoints — so you can fetch candidate and job data and push screening results back into the ATS. If you need a specific ATS that isn't yet in Knit's catalog, you can request it, and the Knit team can also walk through your specific screening workflow on a call.

‍

Use Cases

Jun 13, 2026

How Can Marketing Automation Tools Build More CRM Integrations in 80% Less Time

Marketing automation tools are like superchargers for marketers, propelling their campaigns to new heights. Yet, there's a secret ingredient that can take this power to the next level: the right audience data.

What better than an organization's CRM to power it?

The good news is that many marketing automation tools are embracing CRM API integrations to drive greater adoption and results. However, with the increasing number of CRM systems in play, building and managing CRM integrations is becoming a huge challenge.

Fortunately, the rise of unified CRM APIs is bridging this gap, making CRM integration seamless for marketing automation tools. Before looking at the specific ways marketing automation tools can put CRM data to work, here's a quick look at what CRM API integration actually means.

What is CRM API integration?

A CRM API is a set of endpoints that a Customer Relationship Management platform exposes so external applications can read and write its data — contacts, deals, companies, activities, and custom fields — programmatically, instead of through the CRM's own interface.

CRM API integration is the process of connecting an external application, such as a marketing automation tool, to one or more CRM systems through these APIs so that data and triggers can flow between them automatically. For a marketing automation platform, that usually means pulling contact and deal data from the CRM to power segmentation and personalization, and pushing engagement data — email opens, campaign responses, lead scores — back into the CRM so sales has an up-to-date view of each lead.

Because every CRM structures this data differently, building and maintaining direct integrations with multiple CRMs is a significant engineering investment. A unified CRM API like Knit addresses this by normalizing these differences into a single data model and a single integration covering Knit's full catalog of CRM applications — the approach this post explores in more detail below.

10 ways marketing automation tools can maximize results with CRM API integration

Here's a quick snapshot of how CRM APIs can bring out the best of marketing automation tools, making the most of the audience data for customers.

1. Customer segmentation and content personalization

Personalized messaging consistently outperforms generic, one-size-fits-all campaigns, and CRM integration with marketing automation tools gives users the segmentation data needed to build that personalization at scale.

Users can segment customers based on their likelihood of conversion and personalize content for each campaign. Slicing and dicing customer data — including demographics, preferences, and interactions — can further help in customizing content with higher chances of consumption and engagement. Customer segmentation powered by CRM API data can help create content that customers resonate with.

2. Enhanced lead nurturing for higher conversion

CRM integration provides the marketing automation tool with every tiny detail of every lead to adjust and customize communication and campaigns that facilitate better nurturing. At the same time, real-time updates from the CRM can help with timely marketing follow-ups for better chances of closure.

3. Churn prediction and customer retention

As customer data from the CRM and marketing automation tools is synced in real time, early signs of churn — like reduced engagement or changed consumer behavior — can be captured.

Real-time alerts can also be automatically updated in the CRM for sales action. At the same time, marketing automation tools can leverage CRM data to predict which customers are more likely to churn and create specific campaigns to facilitate retention.

4. Upsell and cross-sell campaigns

Users can leverage customer preferences from CRM data to design campaigns with specific recommendations, and even identify opportunities for upselling and cross-selling.

For instance, customers with high engagement might be interested in upgrading their relationships, and marketing automation tools can use this information together with CRM details on historical trends to propose the best options for upselling.

Similarly, when details of customer transactions are captured in the CRM, they can be used to identify opportunities for complementary selling with dedicated campaigns — leading to a clear increase in revenue.

5. Automated campaign workflow to reduce operational overheads

In most marketing campaigns, as the status of a lead changes, a new set of communication and campaigns takes over. With CRM API integration, marketing automation tools can automate the campaign workflow in real time as soon as there's a status change in the CRM — ensuring greater engagement with the lead right when their status changes.

6. Event-triggered campaigns for faster TAT

Marketing communication after events is an important part of the sales process. With CRM integration in marketing automation tools, automated post-event communication or campaigns can be triggered based on a lead's status for attendance and participation in the event.

This facilitates a faster turnaround time for engaging customers right after the event, without delays from manual follow-ups.

7. Lead source automation

CRM integration can help automatically map the source of a lead from different marketing activities — webinars, social media posts, newsletters, and more — in your CRM, helping you understand where your target audience engagement is highest.

At the same time, it can facilitate tagging leads to the right teams or individuals for follow-ups and closures. With automated lead source tracking, users can track the ROI of different marketing activities.

8. Tailored social media campaigns and multi-channel marketing

With CRM API integration, users can access customer preference insights to define their social media campaigns and audience. They can also customize scheduling based on a customer's geographic location from the CRM, to maximize efficiency.

9. Data enrichment for enhancing lead profiles

With bi-directional sync, CRM API integration with marketing automation tools can enhance lead profiles. As more lead data comes in across both platforms, users get a richer, more comprehensive view of their customers — updated in real time across the CRM and the marketing tool.

10. Customer reporting and analytics for decision-making

Data insights from a CRM integrated with marketing automation tools can help teams build reports that analyze and track customer behavior.

This helps teams understand consumer trends, identify top-performing marketing channels, improve customer segmentation, and refine the marketing strategy for stronger engagement overall.

Put together, these ten capabilities support marketing automation across the full customer lifecycle — from a first touch captured in the CRM, through segmentation, nurturing, and lifecycle campaigns, to churn prevention and retention. The more of this data flows automatically between the CRM and the marketing automation tool, the less manual work is needed to keep campaigns aligned with where each customer actually is in their journey.

Real-world struggles of CRM integration in marketing automation

While the benefits of CRM API integration with marketing automation tools are many, there are also roadblocks along the way. Since each CRM API is different, and your customers might be using different CRM systems, building and maintaining a plethora of CRM integrations can be challenging due to:

Data transformation inconsistency and campaign blunders

When data is exchanged between two applications, it needs to be transformed so it's normalized, with data fields compatible across both. Since each CRM API has its own data models, syntax, and nuances, inconsistency during data transfer is a big challenge.

If data isn't correctly normalized or transformed, it can get corrupted or lost, leading to gaps in the integration. Inconsistency in data transformation and sync can also lead to sending incorrect campaigns and triggers to customers, compromising their experience.

Delays in campaigns

While inconsistent data transformation is one challenge, a related concern is delays or limited real-time sync capabilities.

If data sync between the CRM and the marketing automation tool isn't happening in real time across all CRMs being used, communication with end customers can be delayed — leading to loss of interest and lower engagement.

Customer data privacy and security concerns

A CRM is a hub of sensitive customer data, often governed by GDPR and other compliance regulations. Integration and data transfer are always vulnerable to security threats like man-in-the-middle attacks and DDoS, which can compromise privacy and create monetary and reputational risk.

Scalability

With the increasing number of CRM applications, scalability becomes a major integration challenge. Building a direct integration with a single CRM's API is itself a meaningful engineering investment — handling that CRM's authentication, data model, rate limits, and edge cases. The challenge is that this effort doesn't scale linearly: supporting a second or third CRM means repeating much of that work against a completely different API, which either means compromising on the CRM integrations you can offer or pulling engineering bandwidth away from your core product.

Moreover, as the number of integrated CRM systems grows, the volume of API calls and data exchange grows with it — leading to delays in data sync and real-time updates as load increases. Scalability inevitably becomes a challenge.

Integration management

Managing and maintaining integrations is a challenge in itself. When end customers are using integrations, issues that require immediate action are likely to come up.

At the same time, maintaining detailed logs and manually tracking API calls and syncs is tedious — and any lag here can affect the entire integration system.

Vendor management

Finally, when integrating with different CRM APIs, managing the CRM vendors themselves is a challenge. Understanding API updates, managing different endpoints, ensuring zero downtime, handling errors, and coordinating with each vendor's response team is highly operational and time-consuming.

How a unified CRM API ensures maximum integration ROI

Don't let the challenges above stop you from realizing the benefits described earlier in this post. A unified CRM API like Knit's can help you access those benefits without the operational overhead.

If you want to understand the technical details of how a unified API works, this will help.

Integrate in minutes with multiple CRM APIs

A unified CRM API makes it possible to integrate with marketing automation tools within minutes rather than the weeks or months that direct integrations typically take.

At the same time, it enables connecting with multiple CRM applications in one go. With Knit, marketing automation tools simply embed Knit's UI component in their frontend to get access to Knit's full catalog of CRM applications.

Build CRM-to-marketing-automation workflows without code

Beyond the unified API itself, Knit's Integrations Agent lets you build CRM-to-marketing-automation workflows by describing them in plain English — no integration code required. It supports two kinds of workflows: data sync (keeping records aligned between a CRM and a marketing automation tool) and orchestration (multi-step automations triggered by an event).

In a marketing context, this could look like:

"When a lead's stage changes to 'Customer' in [CRM], add them to the onboarding email sequence in [marketing automation tool]."
"If a deal is marked 'Closed Lost' in [CRM], remove the contact from active nurture campaigns and tag them for a win-back sequence in 90 days."
"Notify our marketing team on Slack whenever a high-value lead's engagement score crosses a threshold in [CRM]."

These workflows run on the same normalized CRM data model described throughout this post, so they work the same way across Knit's full catalog of CRM applications — for marketing teams who'd rather configure an automation than wait on an integration backlog.

Consistent data transfer guaranteed with normalized data models

A unified CRM API can address data transformation and normalization challenges easily. With Knit, different data models, nuances, and schemas across CRM applications are mapped into a single, unified data model — enabling data normalization in real time.

At the same time, Knit lets you map custom data fields to access non-standard data.

Real-time campaigns and data exchange

The right unified CRM API can help you sync data in real time, without your team having to build and maintain polling logic for every CRM.

Knit syncs data via event-based webhooks rather than scheduled polling — when a record changes in a CRM, Knit detects the update and pushes it to the marketing automation tool in real time, already normalized into a single data model. For CRM platforms that don't natively support webhooks, Knit provides virtual webhooks that replicate this real-time behavior, so the marketing automation tool doesn't need to know which CRMs support webhooks natively and which don't — or build any polling, rate-limit handling, or normalization logic itself.

This ensures that as soon as a customer's details are updated in the CRM, the associated campaigns or triggers are automatically set in motion.

Never miss a data update

There can be multiple CRM updates within a few minutes, and as data load increases, a unified CRM API helps ensure guaranteed data sync in real time. With Knit, built-in retry mechanisms add resilience so marketing automation tools don't miss CRM updates even at scale — since every lead matters.

You can also configure sync frequency to suit your needs.

Scale as you go

With a unified CRM API, you only need to integrate once. Once you embed the UI component, every time a new CRM application is added to Knit's catalog, you can access it automatically — with sync capabilities — without spending any engineering capacity from your team.

This lets you scale in the most resource-light and efficient way, without diverting engineering productivity from your core product. From a data sync perspective too, a unified CRM API ensures guaranteed scalability, regardless of data load.

Security at scale

One of the biggest concerns around security and vulnerability to cyberattacks can be addressed with a unified CRM API. Here's how Knit approaches it:

Knit encrypts data with AES-256 at rest and TLS 1.3 in transit, with an additional layer of application-level encryption for PII and credentials.
Knit is the only unified API in the market that doesn't store a copy of your end users' data — it operates as a pass-through proxy, processing data on its servers and sending it directly to your application via webhooks. Protecting end-user data this way also helps you build customer confidence during sales conversations.
Knit supports OAuth, API key, and username/password-based authentication, so whatever authorization protocol a given CRM uses, Knit can integrate with it.
Knit is also SOC2, GDPR, and ISO27001 certified, with continuously monitored infrastructure and 24/7 support.

Catch potential errors early on

Finally, integration management — making sure all your CRM APIs are healthy — is well taken care of by a unified CRM API.

A unified CRM API like Knit provides access to a detailed Logs, Issues, Integrated Accounts, and Syncs page for all integrations, so you can monitor and track them along with possible root causes and fixes. This lets your CX team resolve customer issues immediately without involving the tech team.
It also lets you track every API call and data sync, as well as the status of registered webhooks, for real-time visibility into errors — helping you stay on top of your data and catch issues before they affect customers.

Constant monitoring and on-demand customer support

Finally, when you're using a unified API, you don't have to deal with multiple vendors, endpoints, and so on — the heavy lifting is handled by the unified CRM API provider.

With Knit, you get access to 24/7 support to securely manage your integrations, along with detailed documentation, guides, and product walkthroughs for your developers and end users.

FAQs

What is CRM API integration?

CRM API integration is the process of connecting an external application — such as a marketing automation tool — to one or more CRM systems through their APIs, so that records like contacts, deals, and activities can flow between the two systems automatically. Knit provides a unified CRM API that normalizes this connection across its full catalog of CRM platforms, so a marketing automation tool integrates once instead of building a separate connection for each CRM. In practice, this means pulling CRM data into the marketing tool for segmentation and personalization, and pushing engagement data back into the CRM so sales has an up-to-date view of each lead.

What is a CRM API?

A CRM API is a set of endpoints that a Customer Relationship Management platform exposes so other applications can read and write its data — contacts, companies, deals, activities, and custom fields — without going through the CRM's own interface. Knit's unified CRM API sits on top of these individual CRM APIs and normalizes their differences into a single data model and a single integration. Most CRM APIs support core objects like contacts and deals, use OAuth, API key, or username/password authentication, and increasingly offer webhooks for real-time updates — though support varies significantly by provider.

What's an example of CRM API integration in marketing automation?

A common example is lead-stage syncing: when a lead's status changes in the CRM — say from "Qualified" to "Customer" — a CRM API integration can automatically move that contact into a different marketing automation segment, stop one email sequence, and start another, such as an onboarding campaign. With Knit's unified CRM API, this kind of integration is built once against a single normalized data model and works the same way across every CRM in Knit's catalog, rather than being rebuilt for each CRM a marketing automation platform's customers might use. Knit's Integrations Agent can also build this kind of workflow directly from a plain-English description, without integration code.

Does Knit support integrating with multiple CRM platforms through one API?

Yes — Knit's unified CRM API connects to its full catalog of CRM platforms through a single integration, normalizing each provider's data model (contacts, companies, deals, activities) into one consistent format. Instead of building and maintaining separate integrations for each CRM your customers use — each with its own authentication, data structure, and rate limits — you integrate once against Knit's API and gain access to every supported CRM, with new platforms added over time. Custom fields are preserved for CRM-specific data that doesn't fit the standard model. This is particularly useful for marketing automation, sales engagement, and martech platforms whose customers each use a different CRM.

How does a unified CRM API keep marketing automation tools in sync with CRM data in real time?

Knit keeps CRM and marketing automation data in sync through event-based webhooks rather than scheduled polling — when a record changes in the CRM, Knit detects the update and pushes it to the marketing automation tool in real time, already normalized into a single data model. For CRM platforms that don't natively support webhooks, Knit provides virtual webhooks that replicate this real-time behavior, so the marketing automation tool doesn't need to build or maintain any polling logic itself. This is what allows a status change in the CRM — say, a lead becoming a customer — to trigger a campaign change in the marketing tool within moments rather than on the next sync cycle.

Is Knit free to get started with for CRM integrations?

Yes — getting started with Knit's unified CRM API is free. You can sign up, get API keys, and start testing integrations with CRM platforms in Knit's catalog without any upfront cost. This lets a marketing automation team or product team validate that Knit's data model and sync behavior fit their use case before committing to a paid plan for production usage at scale. For teams evaluating whether to build direct CRM integrations or use a unified API, this makes it straightforward to prototype a CRM-to-marketing-automation workflow — including ones built through Knit's Integrations Agent — before any commercial discussion.

How secure is customer data when using a unified CRM API like Knit?

Knit is the only unified API in the market that doesn't store a copy of your end users' CRM data — it operates as a pass-through proxy, processing data on its servers and sending it directly to your application via webhooks. All data Knit processes is encrypted with AES-256 at rest and TLS 1.3 in transit, with an additional layer of application-level encryption for PII and credentials. Knit is also SOC2, GDPR, and ISO27001 certified, with continuously monitored infrastructure and 24/7 support. For marketing automation platforms handling customer contact and engagement data, this means that data isn't sitting in a second database you also have to secure.

Can marketing teams build CRM workflow automations without writing integration code?

Yes — Knit's Integrations Agent lets you build CRM-to-marketing-automation workflows by describing them in plain English; it connects the relevant tools, configures the workflow, and makes it live without requiring integration code. It supports both data-sync workflows (for example, keeping contact records aligned between a CRM and a marketing automation tool) and orchestration workflows (for example, when a lead's stage changes to "Customer" in the CRM, automatically add them to an onboarding sequence and notify the marketing team on Slack). The Agent runs on the same normalized CRM data model as Knit's Unified API, so it works consistently across every CRM in Knit's catalog.

Get started with a unified CRM API

If you're looking to integrate multiple CRM APIs with your product, get your Knit API keys and see the unified API in action — getting started with Knit is completely free.

You can also talk to one of our experts to see how Knit can be customized to solve your specific integration challenges.

‍

Developers

Developer resources on APIs and integrations

Developers

Jul 23, 2026

How to Evaluate API Security of a Third Party API Provider

Note: This is a part of our API Security series where we solve common developer queries in detail with how-to guides, common examples, code snippets and a ready to use security checklist. Feel free to check other articles on topics such as authentication methods, rate limiting, API monitoring and more.

‍

Using third-party APIs - unified API providers, workflow automation tools, and integration platforms - is standard practice for B2B SaaS products. But every third-party API you integrate becomes part of your security perimeter. A provider's breach can be your breach. Their compliance failures can be your audit findings.

This guide covers the specific security criteria to evaluate before integrating any third-party API provider, the questions to ask, and the risk mitigation practices to implement once you do.

Third-Party API Security Evaluation Checklist

Before walking through each criterion in detail, here is the full checklist for quick reference. Use this when evaluating any new API provider.

Category	What to Check	Questions to Ask
Authentication	OAuth 2.0, API keys, JWT support	Does the API support token scoping? Do keys expire?
Encryption	HTTPS/TLS for transit, AES-256 at rest	What TLS version? Are tokens encrypted at rest?
Compliance certifications	SOC2, GDPR, ISO27001	Type I or Type II SOC2? When was the last audit?
Data handling	Where data goes, how long it is stored	Is data stored between API calls? In what region?
Access control	Least-privilege scoping, RBAC	Can I scope API keys to specific resources?
Penetration testing	Frequency, third-party or internal	When was the last pen test? Is the report available?
Incident response	Disclosure policy, SLA for breach notification	How quickly do they notify customers of security incidents?
Rate limiting	DDoS protection, abuse prevention	What rate limits apply? Are they configurable?
Documentation	Security documentation completeness	Is auth, encryption, and compliance documented in detail?
Vulnerability management	CVE monitoring, patch SLA	How quickly are known vulnerabilities patched?

How to evaluate third-party APIs

Before integrating a third-party API into your system; you should ensure they're trustworthy and won't compromise your security. Here’s what you need to ensure:

1. Research the Provider's Security Track Record

Start with publicly available information. Search for the provider's name alongside "security breach", "data incident", or "CVE". Review their security page, trust centre, or compliance documentation. Check whether they have disclosed past incidents and, if so, how they handled them — the quality of incident response matters as much as the absence of incidents.

Specific things to look for:

A dedicated /security page with verifiable details (not just marketing language)
Published SOC2 or ISO27001 audit reports (or summaries) from the last 12 months
Named security contacts or a responsible disclosure program
A bug bounty program - providers that run one take external security feedback seriously

Note: Knit is one of the only unified API in the market today that does not store a copy of your end user’s data thus ensuring the maximum security while fetching and syncing data. Learn more

2. Audit the Security Documentation

A provider with serious security practices documents them thoroughly. Look for:

Authentication methods supported (OAuth 2.0, API key, JWT — and whether each can be scoped)
Explicit TLS version (TLS 1.2 minimum; TLS 1.3 preferred)
Encryption standards for data at rest (AES-256 is the current standard)
Data retention and deletion policies — how long does the provider keep your API request/response data?
Whether their documentation is up to date, version-controlled, and reflects the current API

Red flags: vague claims like "we use industry-standard encryption" without specifics, or security documentation that has not been updated in over a year.

‍

3. Run Security Testing Before Production

Do not wait until after integration to assess security. Before going live:

OWASP API Security Top 10: Use the OWASP API Security Top 10 (updated 2023) as a baseline. The top risks - Broken Object Level Authorization, Broken Authentication, Unrestricted Resource Consumption, and others - apply to any API you consume as well as ones you build. Verify the provider has addressed the common categories.
Penetration testing: If you handle sensitive data (employee records, financial data, health records), require that the provider shares results of their most recent third-party pen test. At minimum, ask when the last test was performed and by which firm.
Vulnerability assessment: Run automated scanning against the API's test/sandbox environment before production integration. Tools like OWASP ZAP can surface common issues.

‍

4. Check compliance

Compliance certifications are evidence of third-party audited security controls. The certifications that matter for B2B SaaS integrations:

SOC2 Type II: The most important certification for US B2B vendors. Type II means auditors tested controls over a period of time (typically 6–12 months) - not just a point-in-time snapshot. Always ask for Type II, not Type I.
ISO27001: International information security management standard. Required or expected by many enterprise customers outside the US.
GDPR compliance (Article 28): If you process EU personal data, your provider must be a compliant data processor under Article 28. Ask for their Data Processing Agreement (DPA).
PCI DSS: Required if payment card data flows through the API.
HIPAA: Required if protected health information (PHI) flows through the API. Not all providers offer this - verify explicitly.

Ask for the actual certificates, not just a checkbox on a webpage. Certificates include issuance dates and scope - both matter.

‍

5. Assess authentication and authorization protocols

Weak authentication in a third-party API is a direct attack surface. Evaluate:

Supported auth methods: OAuth 2.0 with short-lived tokens is the most secure standard for third-party integrations. Long-lived static API keys with no expiry are a risk.
Token scoping: Can you issue an API key scoped to only the specific resources you need (read-only employee data, specific CRM objects)? Least-privilege access at the token level limits blast radius if a key is compromised.
Key rotation: Does the provider support — or enforce — key rotation? Keys that cannot be rotated without re-configuration are a maintenance risk.
MFA for the admin console: Even if your integration uses API keys, does the provider's dashboard require MFA? A compromised admin account can regenerate all your keys.

‍

6. Check data encryption methods

Verify both channels of encryption:

In transit: HTTPS using TLS 1.2 minimum, TLS 1.3 preferred. Ask which TLS version is used and whether older versions (TLS 1.0/1.1) are disabled.
At rest: AES-256 is the current standard for data stored by the provider. Ask explicitly what is stored and for how long — some providers store API request and response payloads for logging purposes; understand what that includes.
Key management: Where are encryption keys stored? Are they rotated? Is there hardware security module (HSM) usage for sensitive operations?

7. Consider rate limiting practices

Rate limiting protects both you and the provider from abuse and denial-of-service conditions. Ask:

What rate limits apply to your tier and specific endpoints?
Are limits enforced per API key, per IP, or per account?
What happens when a limit is hit — does the provider return a 429 with a Retry-After header? (This is standard and allows graceful handling.)
Does the provider have DDoS mitigation at the infrastructure level?

If a provider has no rate limiting at all, that is a reliability and security risk — it means a bug in your integration code could spike your spend and potentially affect other customers on shared infrastructure.

8. Review incident response plan

A security incident with your provider is a matter of when, not if. Before integrating:

Ask for their incident response procedure in writing
Understand the breach notification timeline - how quickly are customers notified after a confirmed incident? GDPR requires notification within 72 hours for EU data breaches
Understand what forensic information they retain and can share post-incident
Verify they have a named security contact or a security disclosure email address

‍

Risk Mitigation After Integration

Even after a thorough evaluation, implement these controls on your side:

API gateway as intermediary: Route all third-party API calls through an internal API gateway or proxy. This lets you add request logging, rate limiting, and authentication enforcement that supplements the provider's own controls.

Credential management: Store API keys in a secrets manager (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager) — never in code or environment variables in plaintext. Implement automated rotation wherever the provider supports it.

Data validation on ingress: Validate and sanitize all data received from third-party APIs before processing it. Do not assume that data from a trusted provider is free of injection payloads or malformed structures.

Continuous monitoring: Log all outbound API calls to third-party providers — endpoint, request size, response code, response time. Alert on anomalous patterns: unexpected data volumes, unusual error rates, calls to endpoints your integration does not normally use.

Dependency and supply chain monitoring: Use software composition analysis (SCA) tools to track the provider's client SDK if you use one. Known vulnerabilities in third-party SDKs (CVEs) can become your vulnerabilities if you do not update.

Fallback and graceful degradation: Plan for provider outages. Implement circuit breakers and fallback logic so that a third-party API failure degrades gracefully rather than propagating as an error through your product.

Regular access reviews: Audit which API keys are active quarterly. Revoke any key that is no longer in use.

How Knit Approaches Third-Party API Security

If you are evaluating Knit as a unified API provider, here is the relevant security posture:

Pass-through architecture: Knit does not store or copy your end users' data. When your application calls Knit to fetch employee records, CRM contacts, or financial data, the request flows through Knit to the source system and the response flows directly back. No data is persisted in Knit's infrastructure between API calls.

Encryption: All data in transit is encrypted with TLS 1.3. Data at rest uses AES-256. PII fields receive additional app-level encryption.

Certifications: Knit is SOC2 Type II certified, GDPR compliant (with a Data Processing Agreement available), and ISO27001 certified.

Access scoping: Knit MCP Servers and API credentials can be scoped to specific apps and specific tools — your integration only accesses what you explicitly configure.

Take your API security to the next level

If you are looking for a unified API provider that takes API and data security seriously, you can try Knit. It doesn’t store any of your user data and uses the latest tools to stay on top of any potential issues while complying with security standards such as SOC2, GDPR, and ISO27001.

Get your API keys or talk to our experts to discuss your customization needs

‍

FAQs

What are the most important certifications to require from a third-party API provider?

Knit holds SOC2 Type II, GDPR (Article 28), and ISO27001 certifications — the three most commonly required by enterprise buyers for B2B SaaS integrations. For US customers, SOC2 Type II is the baseline. For EU data processing, a GDPR-compliant DPA is required. For international enterprise deals, ISO27001 is often expected. Always verify Type II for SOC2 — Type I only verifies controls exist at a point in time, not that they work continuously. Ask for the actual certificate with issuance date, not a checkbox.

What is the OWASP API Security Top 10 and why does it matter for evaluating providers?

The OWASP API Security Top 10 is the industry-standard framework for API security risks, maintained by the Open Web Application Security Project and updated in 2023. The top risks include Broken Object Level Authorization (BOLA), Broken Authentication, Broken Object Property Level Authorization, Unrestricted Resource Consumption, and Broken Function Level Authorization. When evaluating a provider, asking whether their security practices address the OWASP Top 10 is a fast way to assess maturity — providers with serious security programs will know the framework and can explain their controls.

How do I check if a third-party API is using strong encryption?

Check for HTTPS enforcement on all endpoints (HTTP should redirect to HTTPS, not just work alongside it). Ask explicitly which TLS version is used — TLS 1.3 is the current standard; TLS 1.0 and 1.1 have known vulnerabilities and should be disabled. For data at rest, AES-256 is the current standard. Ask what is stored and for how long — providers that log API request and response payloads indefinitely have a larger encryption surface area than those that do not store payload data.

What should I look for in a provider's incident response plan?

Key elements: a documented notification timeline (GDPR requires 72 hours for EU data breaches; many enterprise contracts require 24–48 hours), a named security contact or security@domain.com address, a responsible disclosure program for external researchers, and a record of how past incidents were handled. Ask whether the provider has experienced a breach — and if so, how they notified customers. The quality of disclosure often matters more than the incident itself.

Should I require penetration testing results from my API provider?

For any integration that handles personal data, financial data, or sensitive business records, yes. Ask when the last third-party penetration test was conducted and by which firm. Annual pen tests by an accredited third party are the minimum bar for enterprise-grade providers. Some providers publish pen test executive summaries or will share them under NDA. If a provider cannot confirm they have had a third-party pen test in the last 12 months, treat that as a significant risk signal.

What are the three pillars of API security?

The three pillars of API security are governance, testing, and continuous validation. Governance covers defining security policies, access controls, and compliance requirements. Testing covers penetration testing, vulnerability assessments, and running API calls against the OWASP Top 10 attack patterns. Continuous validation covers runtime monitoring, anomaly detection, and alerting on unexpected API behavior in production. When evaluating a third-party provider, you are assessing all three pillars — not just whether they have certifications, but whether they test continuously and have operational controls in place.

What is the difference between SOC2 Type I and SOC2 Type II?

SOC2 Type I is a point-in-time assessment: auditors verify that the right security controls exist on a specific date. SOC2 Type II is an audit over a period (typically 6–12 months): auditors verify that the controls are operating effectively over time. Type II is substantially stronger evidence. When a provider says "we're SOC2 compliant," always ask which type. Most enterprise procurement checklists and enterprise contracts require Type II. Ask for the certificate, which shows the audit period covered.

How does Knit's pass-through architecture reduce third-party API security risk?

Knit uses a pass-through architecture — your end users' data is not stored or copied within Knit's infrastructure. When your application calls Knit to fetch an employee record or CRM contact, the data flows from the source system through Knit directly to your application and is not persisted between calls. This significantly reduces the data breach exposure surface compared to providers that store normalized copies of your customers' data. Knit is SOC2 Type II certified, GDPR compliant with a Data Processing Agreement, and ISO27001 certified. All data in transit uses TLS 1.3; data at rest uses AES-256.

‍

Developers

Jul 23, 2026

How to determine the appropriate page size for a paginated API

‍Note: This is a part of our series on API Pagination where we solve common developer queries in detail with common examples and code snippets. Please read the full guide here where we discuss page size, error handling, pagination stability, caching strategies and more.

‍

Page size — the number of records returned per API request - is one of the most consequential configuration decisions in a paginated API. Too small, and consumers make hundreds of unnecessary requests to retrieve a full dataset. Too large, and you risk timeout errors, memory pressure on your server, and slow response times that break client-side rendering.

There is no universal right answer, but there are clear frameworks for finding the right answer for your specific case.

‍

What "Page Size" Means

In a paginated API, page size (also called limit, per_page, or size depending on the API) controls how many records are returned per request. The consumer increments a page or cursor to retrieve subsequent batches.

GET /employees?page=1&per_page=50
GET /employees?page=2&per_page=50

Your job as the API designer is to pick a sensible default, enforce a safe maximum, and let consumers override the default within that ceiling.

1. Understand the data characteristics

The size and structure of individual records is the first variable to nail down.

Small, flat records (IDs, names, status fields — 1–5 KB each): you can safely return 100–200 per page without straining response payload sizes.

Typical business records (employee profiles, CRM contacts, support tickets — 5–20 KB each, with some nesting): 25–100 per page is the practical range for most APIs.

Complex or deeply nested records (job applications with embedded assessments, financial transactions with line items — 20–50+ KB each): keep page size at 10–25 to avoid response payloads exceeding 1–2 MB.

Media metadata or documents (large embedded blobs, rich-text fields): 5–20 per page, and consider whether the heavy fields should be excluded from list endpoints entirely and fetched only on individual record calls.

A fast check: multiply your average record size by your intended page size. If the math produces a payload above 2 MB, reduce the page size.

2. Factor In Network Latency and Bandwidth

Network conditions vary significantly across your consumer base:

Browser clients on average connections: target response times under 500ms. Test your API under realistic page sizes and check P95 response times — if a page of 100 records takes 800ms on your test environment, your production P95 will likely be worse.
Mobile clients on cellular: smaller pages (25–50) improve perceived responsiveness and reduce the impact of dropped connections mid-response.
Server-to-server batch sync jobs: no user is waiting for each response, so larger page sizes (200–500) are appropriate to minimize the number of round trips for large dataset pulls.

‍

3. Evaluate Server-Side Performance

Larger pages put more load on your database and API server per request. Key considerations:

Database query cost: a LIMIT 500 query scans and returns 10x more rows than LIMIT 50. For indexed queries on normalized tables this is often acceptable; for complex joins or aggregations, the cost multiplies fast.

Memory allocation: each in-flight large-page request holds the full result set in memory until serialization completes. Under concurrent load, this can spike memory usage substantially.

Timeout risk: if a consumer requests a very large page on a slow query, the request may time out partway through. Set your max page size conservatively and enforce it server-side - do not trust the consumer to be reasonable.

Test at realistic data volumes, not dev-environment datasets with 500 rows. A query that runs in 50ms against 500 rows may take 4 seconds against 5 million.

4. Consider the Consumer Experience

Always allow consumers to specify page size. A fixed page size optimized for browser pagination is wrong for a batch sync job, and vice versa. Expose a parameter:

GET /contacts?page=2&per_page=100

Enforce a ceiling. Even with consumer control, set a maximum the server will honor. A request for per_page=10000 should either be rejected with a 400 or silently capped at your maximum.

Return pagination metadata. Consumers should not have to guess whether there are more pages:

{
  "data": [ ... ],
  "pagination": {
    "page": 2,
    "per_page": 50,
    "total_records": 1247,
    "total_pages": 25,
    "next_page": 3,
    "next_cursor": "eyJpZCI6MTAwfQ"
  }
}

total_records and total_pages let consumers pre-allocate storage and report progress. next_cursor supports cursor-based consumers even alongside page-based navigation.

5. Recommended Page Size Ranges by Use Case

Based on common API design patterns and real-world benchmarks:

Use Case	Recommended Default	Suggested Max
Simple flat records (IDs, names, status)	100–200	500–1000
Typical business records (employees, contacts, tickets)	25–100	200–500
Complex nested documents	10–25	50–100
Heavy payloads (media metadata, rich text)	5–20	50
Interactive UI pagination	10–25	100
Batch sync / ETL jobs	100–500	1000

How major APIs set page size in practice:

GitHub REST API: default 30, maximum 100
Stripe: default 10, maximum 100
HubSpot: maximum 100 per endpoint (varies by object type)
Salesforce: default 2000 maximum (very high - Salesforce optimizes for bulk data access)
Jira: default 50, maximum 100
Zendesk: default 100, maximum 100 (fixed)

The range across real-world APIs is wide. Your defaults should reflect your specific query patterns, not what another API does.

6. Test Before You Fix a Default

Don't pick a page size based on intuition alone. Before shipping:

Load test your API at multiple page sizes (10, 25, 50, 100, 200) under concurrent request load
Measure P95 response time at each size — not just average
Monitor server memory during the test; look for spikes under simultaneous large-page requests
Ask early consumers what sizes they're actually requesting — they will tell you where the pain is

A common finding: developers set a conservative default of 25 and discover their largest consumer is using ?per_page=25& in a loop making 400 requests to sync 10,000 records. A default of 200 with a max of 1000 would have served them better.

When You're Consuming (Not Building) a Paginated API

If you are integrating with third-party APIs — HRIS platforms, CRMs, ATS systems, accounting software — you are on the other side of the equation. You do not control the page size. You adapt to whatever the upstream API enforces.

The problem: every platform is different.

BambooHR might cap at 50 records per page
Workday might allow 200
Salesforce might return 2000
Each platform uses different parameter names (page, offset, cursor, pageToken, next)
Some platforms don't return a total count, so you don't know how many pages to expect

When you are building integrations across multiple platforms, you end up maintaining separate pagination logic for each - correctly handling each platform's parameters, response format, and edge cases (missing total counts, inconsistent last-page detection, cursor invalidation).

Knit's unified API abstracts this. When your application calls Knit to fetch employee data, Knit handles pagination internally against whatever HRIS platform the customer has connected — Workday, BambooHR, Darwinbox, ADP, HiBob, and 150+ others. Your code makes a single normalized request; Knit handles per-platform pagination and returns a complete, consistent dataset.

FAQs

What is a good default page size for a REST API?

Knit's unified API uses 25–100 records per page as a default for most business data endpoints — a range that works well for typical employee, contact, or ticket records. For your own API, 25–50 is a safe starting default for business records: small enough to keep response times under 500ms in most configurations, large enough to be useful for consumers who need moderate data volumes. Adjust up or down based on your actual record sizes and database query performance at those sizes.

What is the difference between limit/offset and cursor-based pagination?

Limit/offset pagination uses numeric page and size parameters (?page=2&per_page=50) and is easy to implement and understand. Its weakness: if records are added or deleted between requests, the offset shifts and consumers may see duplicate or skipped records. Cursor-based pagination returns an opaque token pointing to the position after the last returned record; the next request passes the token instead of a page number. Cursors are stable under inserts and deletes and are the standard choice for real-time feeds or frequently updated datasets. Knit uses cursor-based pagination internally when connecting to platforms that support it, falling back to offset where cursors are unavailable.

Should I let API consumers set their own page size?

Yes — always allow consumers to specify a page size via a parameter. Different consumers have legitimately different needs: a batch sync job benefits from large pages (200–500), while a UI component loading records for display benefits from smaller pages (10–25). Enforcing a fixed page size that fits your average case will be wrong for your edge cases. Set a maximum ceiling the server enforces, and document both the default and the maximum clearly.

What happens if I set my API page size too large?

Large page sizes increase response payload size, server memory allocation per request, and database query execution time. Under concurrent load, multiple simultaneous large-page requests can spike memory usage and trigger timeout errors. Consumers who receive very large responses may hit client-side memory limits or parsing timeouts, especially in mobile environments. If your API has no max ceiling, a single malicious or misconfigured consumer can send ?per_page=100000 and effectively run a denial-of-service attack against your database. Always enforce a server-side maximum.

How do I paginate through all records in a REST API?

The standard pattern: start at page 1, request your target page size, and loop until the response contains fewer records than the page size (or a next cursor/link is absent). In Python:

all_records = []
page = 1
per_page = 100

while True:
    response = requests.get(
        "https://api.example.com/employees",
        params={"page": page, "per_page": per_page},
        headers={"Authorization": f"Bearer {token}"}
    )
    batch = response.json().get("data", [])
    all_records.extend(batch)

    if len(batch) < per_page:
        break  # Last page reached
    page += 1

When integrating with multiple third-party platforms, Knit handles this pagination loop for you — your application calls a single Knit endpoint and receives the full, normalized dataset without implementing per-platform pagination logic.

What is cursor-based pagination and when should I use it?

Cursor-based pagination replaces the page number with a pointer (cursor or token) to the position after the last returned record. Instead of ?page=3&per_page=50, the consumer sends ?cursor=eyJpZCI6MTUwfQ&per_page=50. The server returns the next batch starting after that position. Use cursor-based pagination when your dataset is updated frequently (new records inserted, existing records deleted) — offset-based pagination is unstable under these conditions and will produce duplicate or missed records between page requests. For static or infrequently updated datasets, offset is simpler and perfectly adequate.

How do major APIs like GitHub and Stripe set their page sizes?

GitHub's REST API defaults to 30 records per page with a maximum of 100. Stripe defaults to 10 with a maximum of 100. Zendesk fixes page size at 100 with no consumer override. Salesforce allows up to 2000 records per query — tuned for bulk data access rather than interactive pagination. HubSpot caps at 100 per endpoint. The wide variance reflects each platform's data model, typical use case, and database architecture. When you integrate with multiple of these APIs (as most B2B products do), you need pagination logic customized for each. Knit normalizes this across 150+ platforms so your integration code handles none of it directly.

How does Knit handle pagination when fetching data from third-party HRIS or CRM platforms?

Knit handles all pagination internally against the upstream SaaS platform — including per-platform page size limits, cursor management, offset handling, and last-page detection. When your application calls Knit's unified API to fetch employee records from Workday, BambooHR, or any of 150+ connected platforms, Knit iterates through all pages of the upstream API response and returns the complete, normalized dataset. Your integration code does not need to implement or maintain platform-specific pagination logic.

Try Knit for Third-Party API Integrations

If your application integrates with HRIS, CRM, ATS, or accounting platforms, Knit handles pagination, authentication, rate limiting, and data normalization across 150+ business apps — so you do not manage any of it per-platform.

Get started with Knit or book a demo.

Developers

Jul 2, 2026

How to Build AI Agents in n8n with Knit MCP Servers (Step-by-Step Tutorial)

AI agents are only as useful as the business systems they can touch. An agent that can reason about your data but cannot update a CRM record, create a support ticket, or sync an employee record has limited real-world value.

Combining n8n's native MCP Client nodes with Knit MCP Servers solves this directly. Your agents get secure, pre-authenticated access to 150+ business apps — Salesforce, HubSpot, BambooHR, QuickBooks, Zendesk — ithout you managing OAuth flows, API versioning, or rate limit handling for each one.

‍

What You'll Learn

This tutorial covers everything you need to build functional AI agents that integrate with your existing business stack:

Understanding MCP implementation in n8n workflows
Setting up Knit MCP Servers for enterprise integrations
Creating your first AI agent with real CRM connections
Production-ready examples for sales, support, and HR teams
Performance optimization and security best practices

By following this guide, you'll build an agent that can search your CRM, update contact records, and automatically post summaries to Slack.

Understanding MCP in n8n Workflows

The Model Context Protocol (MCP) creates a standardized way for AI models to interact with external tools and data sources. It's like having a universal adapter that connects any AI model to any business application.

n8n'sbuilt-in AI Agent node includes native MCP support through two node types, availablefrom the node panel without any additional packages:

MCP Client Tool Node: Connects your AI Agent to external MCP servers, enabling actions like "search contacts in Salesforce" or "create ticket in Zendesk"

MCP Server Trigger Node: Exposes your n8n workflows as MCP endpoints that other systems can call

This architecture means your AI agents can perform real business actions instead of just generating responses.

n8n also works in reverse: the MCP Server Trigger node lets you expose any n8n workflow asan MCP endpoint that other AI clients can call — turning your automations into callabletools for Claude Desktop, Cursor, or any other MCP-compatible host.

This guide covers the most common use case: using n8n as the MCP client, with Knit as the MCP server for your business app integrations.

‍

Why Choose Knit MCP Servers Over Custom / Open Source Solutions

Building your own MCP server sounds appealing until you face the reality:

OAuth flows that break when providers update their APIs
You need to scale up hundreds of instances dynamically
Rate limiting and error handling across dozens of services
Ongoing maintenance as each SaaS platform evolves
Security compliance requirements (SOC2, GDPR, ISO27001)

Knit MCP Servers eliminate this complexity:

✅ Ready-to-use integrations for 150+ business applications

✅ Bidirectional operations – read data and write updates

✅ Enterprise security with compliance certifications

✅ Instant deployment using server URLs and API keys

✅ Automatic updates when SaaS providers change their APIs

Step-by-Step: Creating Your First Knit MCP Server

1. Access the Knit Dashboard

Log into your Knit account and navigate to the MCP Hub. This centralizes all your MCP server configurations.

2. Configure Your MCP Server

Click "Create New MCP Server" and select your apps :

‍

CRM: Salesforce, HubSpot, Pipedrive operations
Support: Zendesk, Freshdesk, ServiceNow workflows
HR: BambooHR, Workday, ADP integrations
Finance: QuickBooks, Xero, NetSuite connections

3. Select Specific Tools

Choose the exact capabilities your agent needs:

Search existing contacts
Create new deals or opportunities
Update account information
Generate support tickets
Send notification emails

4. Deploy and Retrieve Credentials

Click "Deploy" to activate your server. Copy the generated Server URL - – you'll need this for the n8n integration.

‍

Building Your AI Agent in n8n

Setting Up the Core Workflow

Create a new n8n workflow and add these essential nodes:

AI Agent Node – The reasoning engine that decides which tools to use
MCP Client Tool Node – Connects to your Knit MCP server
Additional nodes for Slack, email, or database operations

Configuring the MCP Connection

In your MCP Client Tool node:

Server URL: Paste your Knit MCP endpoint
Authentication: Add your API key as a Bearer token in headers
Tool Selection: n8n automatically discovers available tools from your MCP server

Writing Effective Agent Prompts

Your system prompt determines how the agent behaves. Here's a production example:

You are a lead qualification assistant for our sales team. 

When given a company domain:
1. Search our CRM for existing contacts at that company
2. If no contacts exist, create a new contact with available information  
3. Create a follow-up task assigned to the appropriate sales rep
4. Post a summary to our #sales-leads Slack channel

Always search before creating to avoid duplicates. Include confidence scores in your Slack summaries.

‍

Testing Your Agent

Run the workflow with sample data to verify:

CRM searches return expected results
New records are created correctly
Slack notifications contain relevant information
Error handling works for invalid inputs

Real-World Implementation Examples

Sales Lead Processing Agent

Trigger: New form submission or website visitActions:

Check if company exists in CRM
Create or update contact record
Generate qualified lead score
Assign to appropriate sales rep
Send Slack notification with lead details

Support Ticket Triage Agent

Trigger: New support ticket createdActions:

Analyze ticket content and priority
Check customer's subscription tier in CRM
Create corresponding Jira issue if needed
Route to specialized support queue
Update customer with estimated response time

HR Onboarding Automation Agent

Trigger: New employee added to HRISActions:

Create IT equipment requests
Generate office access requests
Schedule manager check-ins
Add to appropriate Slack channels
Create training task assignments

Financial Operations Agent

Trigger: Invoice status updates

‍

‍Actions:

Check payment status in accounting system
Update CRM with payment information
Send payment reminders for overdue accounts
Generate financial reports for management
Flag accounts requiring collection actions

Performance Optimization Strategies

Limit Tool Complexity

Start with 3-5 essential tools rather than overwhelming your agent with every possible action. You can always expand capabilities later.

Design Efficient Tool Chains

Structure your prompts to accomplish tasks in fewer API calls:

"Search first, then create" prevents duplicates
Batch similar operations when possible
Use conditional logic to skip unnecessary steps

Implement Proper Error Handling

Add fallback logic for common failure scenarios:

API rate limits or timeouts
Invalid data formats
Missing required fields
Authentication issues

Security and Compliance Best Practices

Credential Management

Store all API keys and tokens in n8n's secure credential system, never in workflow prompts or comments.

Access Control

Limit MCP server tools to only what each agent actually needs:

Read-only tools for analysis agents
Create permissions for lead generation
Update access only where business logic requires it

Audit Logging

Enable comprehensive logging to track:

Which agents performed what actions
When changes were made to business data
Error patterns that might indicate security issues

Common Troubleshooting Solutions

Agent Performance Issues

Problem: Agent errors out even when MCP server tool call is succesful

Solutions:

Try a different llm model as sometimes the model not be able to read or understand certain response strcutures
Check if the issue is with the schema or the tool being called under the error logs and then retry with just the necessary tools
For the workflow nodes enable retries for upto 3-5 times

Authentication Problems

Error: 401/403 responses from MCP server

Solutions:

Regenerate API key in Knit dashboard
Verify Bearer token format in headers
Check MCP server deployment status+

MCP Server Tools Not Loading

Problem: The AI Agent connects but reports no tools available, or shows an error discovering tools from the MCP server.

‍

Solutions

- Verify the server URL ends with the correct path - Knit server URLs follow the pattern: https://mcp.getknit.dev/server/{your-server-id}

- Confirm theAPI key is in the Authorization header as "Bearer {your-api-key}" -not as a query parameter or basic authcredential

- Check thatthe MCP server is deployed (green status) in your Knit MCP Hub

- If tools recently changed, refresh the MCP Client Tool node's tool list by re-saving the node configuration

‍

Advanced MCP Server Configurations

Creating Custom MCP Endpoints

Use n8n's MCP Server Trigger node to expose your own workflows as MCP tools. This works well for:

Company-specific business processes
Internal system integrations
Custom data transformations

However, for standard SaaS integrations, Knit MCP Servers provide better reliability and maintenance.

Multi-Server Agent Architectures

Connect multiple MCP servers to single agents by adding multiple MCP Client Tool nodes. This enables complex workflows spanning different business systems.

Frequently Asked Questions

Q: How do Iset up an n8n MCP server connection to Knit?

A: Knit MCP Servers provide the simplest setup path for n8n. Deploy a server from mcphub.getknit.dev, copy the generated Server URL and API key. In your n8n workflow, add an MCP Client Tool node to your AI Agent, paste the Server URL as the endpoint, and add the API key as a Bearer token in the Authorization header. n8n automatically discovers all available tools from the Knit server — no manual toolconfiguration required. The full setup takes under five minutes.

Q: Can I use n8n to build an MCP server?

A: Yes —n8n's MCP Server Trigger node lets you expose any n8n workflow as an MCP endpoint that AI clients like Claude Desktop or Cursor can call. Knit MCP Servers complement this: if your n8n-based MCP server needs to read or write data from Salesforce, BambooHR, QuickBooks, or 150+ other business apps, Knit handles those API connections so you do not need to build individual integrations into your n8n workflow .Use n8n for business logic orchestration, Knit for data access.

Q: How do I use the MCP Client Tool node in n8n?

A: Add an MCP Client Tool node as a sub-node attached to your AI Agent node in n8n. Knit MCP Servers expose named tools such as "search_contacts", "create_ticket", or "get_employee_by_id" - the node discovers these automatically from the server URL. Once connected, the AI Agent decides which tool to call based on the task in its system prompt. You do not wire tools manually; the agent handles tool selection and sequencing based on the prompt instructions you write.

Q: Does n8n have a native MCP server?

A: n8n supports MCP in two directions: as a client (using the MCP Client Tool node to connect to servers like Knit) and as a server (using the MCP Server Trigger node to expose n8n workflows as callable tools). Knit MCP Servers give n8n's client mode instant access to 150+ enterprise apps — HRIS, CRM, ATS, and accounting platforms — without building individual API integrations. For the reverse direction, n8n's own MCP Server capability is natively built into recent n8n versions.

Q: Can n8n act as an MCP server?

A: Yes. The MCP Server Trigger node in n8n lets you define any workflow as a tool that MCP-compatible AI clients can discover and call. Knit is complementary: use n8n to expose your custom business logic as MCP tools, and pair it with Knit MCP Servers when those tools need to read or write data from third-party SaaS apps. This hybrid pattern — n8n as orchestrator, Knit as data access layer — is the most common production architecture for enterprise AI agents.

Q: Can n8n connect to a remote MCP server?

A: Yes —n8n's MCP Client Tool node connects to any remote MCP server via HTTP+SSE transport.Knit MCP Servers are fully remote, cloud-hosted endpoints. You connect by pastingthe server URL and adding your API key as a Bearer token in the node settings. No local server installation or ngrok tunneling required — Knit handles the hosting,scaling, and uptime of the server infrastructure.

Q: Do I need coding skills to use n8n with MCP servers?

A: No codingis required for standard MCP workflows in n8n. Knit MCP Servers provide pre-configured tool definitions that the MCP Client Tool node discovers automatically— you do not write tool schemas or API handlers. The entire setup uses n8n'svisual canvas: drag-and-drop nodes, paste the Knit server URL, and write plain-English system prompts for the AI Agent. Custom business logic can be added visuallyusing n8n's other node types without any JavaScript or Python.

Q: How much does it cost to use Knit MCP Servers with n8n?

A: Knit MCP Server pricing scales by the number of servers and integrations — see getknit.dev/pricing for current rates. n8n offers a free self-hosted tier for developmentuse, with cloud plans starting around $20-50/month depending on workflowvolume and team size. For most B2B automation use cases, the combined cost issubstantially lower than the engineering time required to build and maintain direct APIintegrations to each platform individually.

‍

Getting Started With Your First Agent

The combination of n8n and Knit MCP Servers transforms AI from a conversation tool into a business automation platform. Your agents can now:

Read and write data across your entire business stack
Make decisions based on real-time information
Take actions that directly impact your operations
Scale across departments and use cases

Instead of spending months building custom API integrations, you can:

Deploy a Knit MCP server in minutes
Connect it to n8n with simple configuration
Give your AI agents real business capabilities

Ready to build agents that actually work? Start with Knit MCP Servers and see what's possible when AI meets your business applications.

Product

Deep dives into the Knit product and APIs

Product

Jun 11, 2026

Understanding Merge.dev Pricing: What It Actually Costs at Scale (2026 Guide)

Merge.dev — now marketed simply as Merge — is a unified API platform that lets B2B SaaS products connect to 250+ third-party tools through a single endpoint. Its catalog covers HRIS, ATS, CRM, accounting, ticketing, file storage, and knowledge base categories. In 2025 Merge added a second product, Merge Agent Handler, which gives AI agents secure access to these same tools so they can read data and take actions across your customers' SaaS stacks. This guide covers how Merge's pricing model works, what each plan actually includes, and how it compares to alternatives including Knit.

The most important thing to understand about Merge pricing before anything else: Merge charges per linked account, where one linked account equals one customer's connection to one integration. A customer using your product with Salesforce and Workday connected counts as two linked accounts. At 10 customers, that's manageable. At 100 customers using two integrations each, you're looking at $13,000 per month on the self-serve Launch plan. This guide shows you exactly where the costs go and when it makes sense to look at alternatives.

The short version: Merge bills a flat $65/month per linked account above its 10-account base. That cost climbs in a straight line as you add customers — $1,950/month at 30 accounts, $3,250+/month at 50. Knit's account-based pricing scales on a declining curve instead, and adds a zero-storage architecture and dedicated support earlier in the plan ladder.

How Merge.dev Pricing Works

Merge.dev Pricing Plans

Plan	Price	Linked Accounts Included	Support	Key Features
Launch (self-serve)	First 3 linked accounts free, then $650/month	Up to 10 production linked accounts; $65/month per additional account	Email	Core unified API access, basic sync, standard integrations
Professional (contract)	Custom — typically $30,000–$55,000/year platform fee plus ~$65/connected account	Negotiated	Email + chat	Custom fields, field-level scopes, custom sync frequencies, sandboxes, go-live support
Enterprise (contract)	Custom — Vendr transaction data shows $100,000–$250,000+ annually depending on scope	Negotiated with volume discounts	Email + chat, dedicated account manager, shared Slack channel (first 90 days), support SLA	Security audits, SSO, audit trails, unlimited sandboxes, white-glove support

Billing note: Merge's Launch plan is free for your first 3 production linked accounts. Once you scale beyond 3 (up to 10 total), the $650/month base plan applies, with $65/month for each additional linked account beyond 10. Merge charges based on the net-average daily count of active linked accounts during the prior month, billed on the first of each month. You are not charged for accounts connected and then disconnected within the billing period.

What Merge.dev Actually Costs at Your Customer Count

Merge charges a flat $65 per linked account per month above the 10-account base. Knit's pricing also scales with connected accounts, but on a significantly gentler curve — and Knit additionally offers API calls-based pricing for teams that prefer usage-based billing over account-based tiers. The table below shows the cost difference at comparable account counts:

Linked Accounts	Merge.dev Launch Cost/Month	Knit Cost/Month	Monthly Saving with Knit
10	$650 (base)	$499 (Start Up)	$151
20	$650 + (10 × $65) = $1,300	~$800 (Start Up)	~$500
30	$650 + (20 × $65) = $1,950	~$1,000 (Start Up)	~$950
50+	$650 + (40 × $65) = $3,250+	Start Up continues to scale by account volume, or Scale Up from $1,500/month if you need custom field mapping, white-labeled auth, or configurable sync	Significant; contact getknit.dev/pricing for an exact quote
100+	Enterprise contract ($6,500+/month on Launch)	Enterprise — custom	Custom

Note: Knit's Start Up plan price scales with connected account volume regardless of feature needs. Scale Up is a separate feature upgrade — custom field mapping, white-labeled authentication, configurable sync frequencies, and priority connector requests — that starts at $1,500/month and isn't strictly tied to account count.

Knit's Start Up plan cost decreases on a per-account basis as volume increases — about $50/account at 10 accounts, dropping to roughly $33/account at 30 — while Merge's rate stays fixed at $65/account throughout the self-serve Launch plan. For teams building integrations that will reach 20–50+ connected customers, the savings add up fast. If your needs grow beyond Start Up's scope, Knit's Scale Up plan starts at $1,500/month — still well below Merge's Professional contract pricing. Knit also offers API calls-based pricing as an alternative to account-based tiers for teams with variable usage patterns.

What Is Included in Each Merge.dev Plan

Several features that integration teams often assume are standard require Professional or Enterprise plans on Merge:

Feature	Launch	Professional	Enterprise
Core unified API access (read)	Yes	Yes	Yes
Write / create / update operations	Limited	Yes	Yes
Custom fields and field mapping	No	Yes	Yes
Field-level scopes (limit data access per customer)	No	Yes	Yes
Custom sync frequencies	No	Yes (configurable)	Yes (configurable)
Sandbox environments	No	Yes	Unlimited
Go-live support / implementation help	No	Yes	Yes
SSO / SAML	No	No	Yes
Audit trails and logs	No	No	Yes
SLA guarantees	No	No	Yes
Dedicated account manager	No	No	Yes

For most production integrations serving enterprise buyers, custom field mapping, configurable sync frequencies, and sandbox environments aren't optional extras — they're table stakes. On Merge, all three sit behind the Professional plan, so teams typically hit this upgrade well before account-based billing becomes the bigger cost factor.

Merge Agent Handler: Merge's AI-Focused Product

In 2025, Merge launched Merge Agent Handler alongside their existing unified API. Where the unified API normalizes data reads and writes across SaaS categories, Agent Handler is designed for AI agent use cases — giving LLMs and AI agents the ability to access tools, read structured data, and take actions across your customers' connected SaaS applications.

Merge now positions itself as "the infrastructure layer for production AI" — a shift from the pure unified API positioning it held until 2024. If you are building AI agents into your product and need those agents to access customer data across multiple SaaS tools, Merge Agent Handler is worth evaluating separately from the standard unified API pricing. Agent Handler pricing is contract-based and not publicly listed.

Knit's Answer: MCP Servers and the AI Integrations Agent

Knit's closest equivalent to Merge Agent Handler is its managed MCP hub: 150+ pre-built MCP servers spanning HRIS, ATS, CRM, accounting, and ticketing, deployed serverlessly so agents get tool access without your team standing up or patching infrastructure. Knit handles authentication (OAuth, SAML, service accounts, token refresh), supports hot-swapping tools at runtime so agents see new capabilities without a restart, and uses semantic tool search to surface only the relevant tools for a given task — which keeps token costs down and improves accuracy. Like the rest of Knit's platform, the MCP servers run on a zero-storage architecture, so agent calls pass through to the source system rather than hitting a cached copy.

Behind the catalog sits Knit's AI Integrations Agent — the technology that reads and interprets a SaaS provider's API documentation, then builds and maintains a tailored connector automatically, including endpoints that fall outside a standard unified schema. This is also what lets Knit extend into the custom, enterprise-specific workflows and orchestrations that off-the-shelf unified models often can't reach: Knit can typically add a missing app to its catalog in about 2 days, versus the 2–6 weeks common for unified API vendors, as long as the provider's API documentation is available.

	Merge Agent Handler	Knit MCP Servers + Integrations Agent
What it does	Gives AI agents access to tools, structured data, and actions across connected SaaS apps	150+ managed MCP servers give agents tool access out of the box; the Integrations Agent builds custom connectors by reading a provider's API docs
Data handling	Same caching model as Merge's unified API — data is stored on Merge's servers	Zero-storage — agent calls pass through to the source system in real time
Non-standard endpoints / custom workflows	Handled through custom contract work	Integrations Agent can build a tailored connector, typically within ~2 days given API docs
Pricing	Contract-based, not publicly listed	MCP servers available via mcphub.getknit.dev; Integrations Agent scoping through the Knit team

Merge.dev: Where It Excels and Where It Falls Short

Merge.dev strengths

Broadest integration catalog in the unified API category — 250+ integrations across HRIS, ATS, CRM, accounting, ticketing, file storage, and more
Normalized data models that abstract away provider-specific quirks — your product code stays stable when Salesforce or Workday changes their API
Established enterprise track record — used by Drata, Ramp, and AngelList among others; $75M+ in funding and strong G2/Gartner reviews
Merge Webhooks provide near-real-time sync for providers that support them; other providers use configurable polling intervals
Strong documentation and developer experience for initial integration

Merge.dev limitations worth knowing

Cost scales with linked accounts — at 100 customers using 2 integrations each, you're paying $13,000/month on the self-serve plan, and that's before custom fields or configurable sync are even available
Data storage model: Merge caches a copy of your customers' data on its servers. For customers in regulated industries or with strict data residency requirements, this adds a compliance conversation to every enterprise sales cycle
Batch sync for providers without webhook support — delta sync frequencies depend on your plan; daily sync is the default on lower tiers
Write operation coverage is narrower than reads — not all integrations support full CRUD operations via the unified API
Customer support below Professional tier is email-only — no dedicated account manager until Enterprise

Knit: Where It Has the Edge as an Alternative

Knit strengths

✓

Zero-storage architecture

Knit never caches or retains customer data on its servers — data passes through in real time. This removes a recurring item from security reviews and data residency conversations that Merge's data-caching model often raises with enterprise buyers.

✓

Managed sync, not provider-dependent webhooks

Knit handles sync scheduling, retries, and failure recovery centrally across its catalog, so reliability doesn't hinge on whether an individual provider supports webhooks well. On Merge, sync quality varies by provider — webhooks where supported, daily batch polling where they aren't.

✓

Genuinely configurable sync frequencies

On Scale Up and above, Knit lets you set sync frequency per integration to match your actual use case, rather than choosing from a fixed set of preset intervals.

✓

Dedicated support earlier in the pricing ladder

Knit includes dedicated Slack support starting at Scale Up ($1,500/month). On Merge, a shared Slack channel doesn't appear until Enterprise, where annual contracts typically start around $100,000.

✓

165+ integrations with a fast path to new connectors

Knit's catalog spans HRIS, payroll, ATS, CRM, accounting, ticketing, and e-signature, including Salesforce, Workday, NetSuite, and SAP SuccessFactors. If a connector you need isn't yet supported, Scale Up includes the ability to request new integrations, so catalog gaps can often be addressed without waiting on a public roadmap.

Merge.dev vs. Knit: Full Pricing Comparison

	Merge.dev Launch	Merge.dev Professional	Knit Start Up	Knit Enterprise
Price	First 3 linked accounts free, then $650/month (10 linked accounts)	~$30–55K/year platform fee + ~$65/connected account	$499/month (10 accounts), scaling to ~$1,000/month at 30	Custom
Free trial	3 production linked accounts free	N/A	30-day full-feature trial	N/A
Pricing model	Per linked account — scales with customer count	Per connected account + platform fee	Start Up: tiered by connected accounts, from $499/month for 10 (~$800 for 20, ~$1,000 for 30). Scale Up: feature-based upgrade from $1,500/month, independent of account count. API calls-based pricing also available.	Custom
Data storage	Merge caches customer data on its servers	Merge caches customer data on its servers	Zero storage — data passes through in real time, nothing retained	Zero storage
Sync model	Webhooks where supported; polling otherwise	Webhooks + configurable polling	Fixed 24-hour sync on Start Up; configurable/real-time sync on Scale Up and above	Webhook-first, configurable
Write operations	Limited on Launch	Full CRUD on most integrations	Full CRUD on supported integrations	Full CRUD
Custom field mapping	No	Yes	No on Start Up — included from Scale Up	Yes
Support	Email	Email + chat	Email on Start Up; dedicated Slack support from Scale Up onwards	Dedicated account manager + Slack support
Best for	Small teams evaluating Merge with few customers	Mid-market teams needing full features	Growing SaaS teams starting with core integrations on a budget	Enterprise with compliance requirements

When Merge.dev is the right choice

You need broad category coverage from day one — Merge's 250+ integrations means you can ship integrations with any tool your customers use without waiting for a provider to add it
Your customers are large enterprises with strict compliance and audit requirements — Merge's Enterprise plan includes SSO, audit trails, and security audits that are non-negotiable for some buyers
You have relatively few high-value customers — at 10–20 linked accounts, Merge's $650/month (after 3 free) is competitive and the feature depth is hard to match
Your integration roadmap includes file storage or knowledge base tools — these are categories in Merge's catalog that currently fall outside Knit's core focus areas (HRIS, payroll, ATS, CRM, accounting, ticketing, and e-signature)

When Knit is the better choice

Your integration count is growing and per-account cost is starting to show up in your unit economics — Knit's Start Up plan cost decreases as volume increases (from ~$50/account at 10 to ~$33/account at 30), compared to Merge's fixed $65/account throughout. Knit also offers API calls-based pricing as an alternative if usage-based billing better fits your model.
Your customers are sensitive about third-party data storage — Knit operates on a zero-storage model where customer data passes through in real time and is never retained on Knit's servers, removing the data residency objection from your enterprise sales cycle
You're comfortable starting lean and upgrading as you grow — Knit's Start Up plan ($499/month) covers core integrations with a fixed 24-hour sync and Knit's branding on the auth flow; if you later need custom field mapping, white-labeled auth, or configurable sync, Scale Up starts at $1,500/month as a flat feature fee — independent of account count, unlike Merge's per-account pricing, which keeps climbing as you add customers
You need predictable unit economics as you scale — Merge's per-linked-account model means integration costs grow as a direct function of customer growth, which compresses margins

Ready to see Knit's pricing and zero-storage architecture for yourself?

Try Knit free for 30 days — no credit card required →

Other Merge.dev Alternatives Worth Evaluating

Alternative	Pricing Model	Best For	Key Difference vs. Merge
Knit	Start Up from $499/month (10 accounts), scaling to ~$1,000/month at 30; Scale Up from $1,500/month adds custom field mapping and white-labeled auth. API calls-based pricing also available. 30-day free trial.	SaaS teams where integration count scales with customers	Zero-storage architecture, declining per-account cost at scale, API calls-based pricing option, transparent upgrade path
Nango (open source)	Usage-based / self-hosted option available	Teams that want open-source flexibility or to self-host	Open source core; can run on your own infrastructure
Apideck	Per-linked-account (similar to Merge)	Teams needing API management + unified API in one	Broader API management features beyond unified API
Unified.to	Starting from $750/month API calls based	Cost-sensitive teams or those needing simple CRM/HRIS integrations	Narrower catalog but lower cost at scale
Truto	Usage-based from $0/month (open source)	Teams comfortable with self-hosted or usage-based pricing	Open source option;

Frequently Asked Questions

How much does Merge.dev cost?

Merge.dev's self-serve Launch plan includes your first 3 production linked accounts free, then costs $650/month for up to 10, with each additional linked account billed at $65/month. Knit's Start Up plan starts at $499/month for 10 connected accounts, scaling to approximately $800/month at 20 accounts and $1,000/month at 30 accounts — a significantly gentler curve than Merge's fixed $65/account rate. If you need custom field mapping, white-labeled authentication, or configurable sync, Knit's Scale Up plan starts at $1,500/month. Knit also offers API calls-based pricing as an alternative billing model. Merge's Professional and Enterprise plans are contract-based; Vendr transaction data shows annual contracts typically ranging from $30,000 for Professional to $250,000+ for large Enterprise deployments, depending on linked accounts, integration categories, and feature requirements.

What is a linked account in Merge.dev?

A linked account is Merge's billing unit — it represents one customer's authenticated connection to one integration. If your product connects 50 customers to Salesforce and 30 of those same customers also connect to Workday, that is 80 linked accounts. Merge charges a fixed $65/month per linked account above the 10-account base (after the first 3, which are free). Knit's Start Up plan also prices by connected account but on a declining-rate curve: ~$50/account at 10, ~$40/account at 20, ~$33/account at 30. Knit additionally offers API calls-based pricing for teams that prefer usage-based billing, and a Scale Up plan from $1,500/month for teams that need custom field mapping, white-labeled authentication, or configurable sync regardless of account count. If you're evaluating Merge, model your expected linked account count 12–18 months out before committing — the monthly figure changes significantly as customers add integrations.

What does Merge.dev do?

Merge.dev is a unified API platform that lets B2B SaaS products integrate with 250+ third-party tools — HRIS, ATS, CRM, accounting, ticketing, file storage — through a single API endpoint instead of building each integration separately. Knit provides a similar unified API capability with a zero-storage architecture and tiered pricing that scales more gradually than Merge's fixed per-account rate. Merge has recently expanded into AI infrastructure with Merge Agent Handler, which gives AI agents access to and the ability to act across these same integrated tools.

How much is Merge.dev enterprise pricing?

Merge's Enterprise contracts are custom-priced and not publicly listed. Based on Vendr transaction data from actual buyer contracts, annual deals typically range from around $100,000 for smaller Enterprise deployments (under 50 linked accounts, 1–2 integration categories) to $250,000+ for large-scale enterprise deployments. Knit's Enterprise plan is also custom-priced and includes zero-storage architecture, dedicated support, custom SLAs, and role-based access controls. For teams that need more than Knit's Start Up plan but aren't yet at Enterprise scale, Knit's Scale Up plan (from $1,500/month) covers custom field mapping, white-labeled authentication, and configurable sync. For either platform, the main cost drivers are linked account volume, number of integration categories, and required support tier.

Is Merge.dev worth it?

Merge.dev is worth it if you need broad integration coverage across multiple SaaS categories and have a relatively small number of high-value customers. Where Knit and alternatives become more cost-effective is at scale: if your customer base is growing and each new customer adds linked accounts, Merge's per-account cost adds up quickly. Teams with 50+ customers using 2–3 integrations each should model the total cost before committing to Merge's pricing structure. The decision usually comes down to integration breadth needed versus total cost at your expected customer count.

Does Merge.dev store my customers' data?

Yes — Merge caches a copy of your customers' data on its servers to serve your API requests. This is central to how Merge's architecture works: it syncs from source systems on a schedule and stores the normalized copy for fast reads. Knit operates differently with a zero-storage model where data flows through in real time and is never retained on Knit's servers. For teams selling to enterprises with strict data residency requirements or GDPR obligations, the data storage difference is often a deciding factor.

What are the best alternatives to Merge.dev?

The most commonly evaluated alternatives to Merge.dev are Knit (Start Up plan from $499/month for 10 accounts scaling to ~$1,000/month at 30, with a Scale Up plan from $1,500/month for custom field mapping and white-labeled auth; zero-storage architecture, API calls-based pricing also available, 30-day free trial), Nango (open-source option with self-hosting available), Apideck (broader API management features), Unified.to (flat-rate from $250/month, narrower catalog), and Truto (open-source core, usage-based pricing). Knit's free 30-day trial covers the full Unified API feature set and is a practical way to compare without committing.

Is there a free version of Merge.dev?

Merge.dev's Launch plan includes 3 free production linked accounts — enough for small-scale prototyping but not for a production deployment with real customers. Knit offers a 30-day free trial covering the Start Up plan's feature set (starting at $499/month for 10 connected accounts after the trial), giving you time to build and test a real integration before committing. For teams evaluating unified API options, Knit's 30-day full-feature trial is a more useful comparison baseline than Merge's 3-linked-account limit.

Is Merge.dev an iPaaS?

No — Merge.dev is a unified API, not a general-purpose iPaaS like Zapier or Workato. Knit sits in the same category: rather than letting you build arbitrary workflows between any two apps, both platforms normalize a fixed set of categories — HRIS, ATS, CRM, accounting, ticketing — into a single API your product calls directly. The distinction matters when you're scoping a project. An iPaaS is built for internal automation between tools your team already uses internally. A unified API like Merge or Knit is built to power customer-facing integrations inside the product you sell — your customers connect their HR or CRM systems through your app, not through a separate automation tool. If your goal is to ship "Connect your Workday account" inside your product, you're in unified API territory, not iPaaS.

Product

Mar 29, 2026

Top 5 Nango Alternatives

5 Best Nango Alternatives for Streamlined API Integration

Are you in the market for Nango alternatives that can power your API integration solutions? In this article, we’ll explore five top platforms—Knit, Merge.dev, Apideck, Paragon, and Tray Embedded—and dive into their standout features, pros, and cons. Discover why Knit has become the go-to option for B2B SaaS integrations, helping companies simplify and secure their customer-facing data flows.

‍

TL;DR

‍
Nango is an open-source embedded integration platform that helps B2B SaaS companies quickly connect various applications via a single interface. Its streamlined setup and developer-friendly approach can accelerate time-to-market for customer-facing integrations. However, coverage is somewhat limited compared to broader unified API platforms—particularly those offering deeper category focus and event-driven architectures.

Nango also relies heavily on open source communities for adding new connectors which makes connector scaling less predictable fo complex or niche use cases.

Pros (Why Choose Nango):

Straightforward Setup: Shortens integration development cycles with a simplified approach.
Developer-Centric: Offers documentation and workflows that cater to engineering teams.
Embedded Integration Model: Helps you provide native integrations directly within your product.

Cons (Challenges & Limitations):

Limited Coverage Beyond Core Apps: May not support the full depth of specialized or industry-specific APIs.
Standardized Data Models: With Nango you have to create your own standard data models which requires some learning curve and isn't as straightforward as prebuilt unified APIs like Knit or Merge
Opaque Pricing: While Nango has a free to build and low initial pricing there is very limited support provided initially and if you need support you may have to take their enterprise plans

Now let’s look at a few Nango alternatives you can consider for scaling your B2B SaaS integrations, each with its own unique blend of coverage, security, and customization capabilities.

1. Knit

Knit - How it compares as a nango alternative

Overview
Knit is a unified API platform specifically tailored for B2B SaaS integrations. By consolidating multiple applications—ranging from CRM to HRIS, Recruitment, Communication, and Accounting—via a single API, Knit helps businesses reduce the complexity of API integration solutions while improving efficiency. See how Knit compares directly to Nango →

Key Features

Bi-Directional Sync: Offers both reading and writing capabilities for continuous data flow.
Secure - Event-Driven Architecture: Real-time, webhook-based updates ensure no end-user data is stored, boosting privacy and compliance.
Developer-Friendly: Streamlined setup and comprehensive documentation shorten development cycles.

Pros

Simplified Integration Process: Minimizes the need for multiple APIs, saving development time and maintenance costs.
Enhanced Security: Event-driven design eliminates data-storage risks, reinforcing privacy measures.
New integrations Support : Knit enables you to build your own APIs in minutes or builds new integrations in a couple of days to ensure you can scale with confidence

2. Merge.dev

Overview
Merge.dev delivers unified APIs for crucial categories like HR, payroll, accounting, CRM, and ticketing systems—making it a direct contender among top Nango alternatives.

Key Features

Extensive Pre-Built Integrations: Quickly connect to a wide range of platforms.
Unified Data Model: Ensures consistent and simplified data handling across multiple services.

Pros

Time-Saving: Unified APIs cut down deployment time for new integrations.
Simplified Maintenance: Standardized data models make updates easier to manage.

Cons

Limited Customization: The one-size-fits-all data model may not accommodate every specialized requirement.
Data Constraints: Large-scale data needs may exceed the platform’s current capacity.
Pricing : Merge's platform fee might be steep for mid sized businesses

3. Apideck

Overview
Apideck offers a suite of API integration solutions that give developers access to multiple services through a single integration layer. It’s well-suited for categories like HRIS and ATS.

Key Features

Unified API Layer: Simplifies data exchange and management.
Integration Marketplace: Quickly browse available integrations for faster adoption.

Pros

Broad Coverage: A diverse range of APIs ensures flexibility in integration options.
User-Friendly: Caters to both developers and non-developers, reducing the learning curve.

Cons

Limited Depth in Categories: May lack the robust granularity needed for certain specialized use cases.

‍

4. Paragon

‍

Overview
Paragon is an embedded integration platform geared toward building and managing customer-facing integrations for SaaS businesses. It stands out with its visual workflow builder, enabling lower-code solutions.

Key Features

Low-Code Workflow Builder: Drag-and-drop functionality speeds up integration creation.
Pre-Built Connectors: Quickly access popular services without extensive coding.

Pros

Accessibility: Allows team members of varying technical backgrounds to design workflows.
Scalability: Flexible infrastructure accommodates growing businesses.

Cons

May Not Support Complex Integrations: Highly specialized needs might require additional coding outside the low-code environment.

5. Tray Embedded

‍

Overview
Tray Embedded is another formidable competitor in the B2B SaaS integrations space. It leverages a visual workflow builder to enable embedded, native integrations that clients can use directly within their SaaS platforms.

Key Features

Visual Workflow Editor: Allows for intuitive, drag-and-drop integration design.
Extensive Connector Library: Facilitates quick setup across numerous third-party services.

Pros

Flexibility: The visual editor and extensive connectors make it easy to tailor integrations to unique business requirements.
Speed: Pre-built connectors and templates significantly reduce setup time.

Cons

Complexity for Advanced Use Cases: Handling highly custom scenarios may require development beyond the platform’s built-in capabilities.

Conclusion: Why Knit Is a Leading Nango Alternative

When searching for Nango alternatives that offer a streamlined, secure, and B2B SaaS-focused integration experience, Knit stands out. Its unified API approach and event-driven architecture protect end-user data while accelerating the development process. For businesses seeking API integration solutions that minimize complexity, boost security, and enhance scalability, Knit is a compelling choice.

Interested in trying Knit? - Contact us for a personalized demo and see how Knit can simplify your B2B SaaS integrations

Product

Mar 29, 2026

Finch API Vs Knit API - What Unified HR API is Right for You?

Whether you are a SaaS founder/ BD/ CX/ tech person, you know how crucial data safety is to close important deals. If your customer senses even the slightest risk to their internal data, it could be the end of all potential or existing collaboration with you.

But ensuring complete data safety — especially when you need to integrate with multiple 3rd party applications to ensure smooth functionality of your product — can be really challenging.

While a unified API makes it easier to build integrations faster, not all unified APIs work the same way.

In this article, we will explore different data sync strategies adopted by different unified APIs with the examples of Finch API and Knit — their mechanisms, differences and what you should go for if you are looking for a unified API solution.

Let’s dive deeper.

But before that, let us first revisit the primary components of a unified API and how exactly they make building integration easier.

How does a unified API work?

As we have mentioned in our detailed guide on Unified APIs,

“A unified API aggregates several APIs within a specific category of software into a single API and normalizes data exchange. Unified APIs add an additional abstraction layer to ensure that all data models are normalized into a common data model of the unified API which has several direct benefits to your bottom line”.

The mechanism of a unified API can be broken down into 4 primary elements —

Authentication and authorization
Connectors (1:Many)
Data syncs
Ongoing integration management

1.Authentication and authorization

Every unified API — whether its Finch API, Merge API or Knit API — follows certain protocols (such as OAuth) to guide your end users authenticate and authorize access to the 3rd party apps they already use to your SaaS application.

2. Connectors

Not all apps within a single category of software applications have the same data models. As a result, SaaS developers often spend a great deal of time and effort into understanding and building upon each specific data model.

A unified API standardizes all these different data models into a single common data model (also called a 1:many connector) so SaaS developers only need to understand the nuances of one connector provided by the unified API and integrate with multiple third party applications in half the time.

3. Data Sync

The primary aim of all integration is to ensure smooth and consistent data flow — from the source (3rd party app) to your app and back — at all moments.

We will discuss different data sync models adopted by Finch API and Knit API in the next section.

4. Ongoing integration Management

Every SaaS company knows that maintaining existing integrations takes more time and engineering bandwidth than the monumental task of building integrations itself. Which is why most SaaS companies today are looking for unified API solutions with an integration management dashboards — a central place with the health of all live integrations, any issues thereon and possible resolution with RCA. This enables the customer success teams to fix any integration issues then and there without the aid of engineering team.

finch API alterative — how a unified API works

How data sync happens in Unified APIs?

For any unified API, data sync is a two-fold process —

Data sync between the source (3rd party app) and the unified API provider
Data sync between the unified API and your app

Between the third party app and unified API

First of all, to make any data exchange happen, the unified API needs to read data from the source app (in this case the 3rd party app your customer already uses).

However, this initial data syncing also involves two specific steps — initial data sync and subsequent delta syncs.

Initial data sync between source app and unified API

Initial data sync is what happens when your customer authenticates and authorizes the unified API platform (let’s say Finch API in this case) to access their data from the third party app while onboarding Finch.

Now, upon getting the initial access, for ease of use, Finch API copies and stores this data in their server. Most unified APIs out there use this process of copying and storing customer data from the source app into their own databases to be able to run the integrations smoothly.

While this is the common practice for even the top unified APIs out there, this practice poses multiple challenges to customer data safety (we’ll discuss this later in this article). Before that, let’s have a look at delta syncs.

What are delta syncs?

Delta syncs, as the name suggests, includes every data sync that happens post initial sync as a result of changes in customer data in the source app.

For example, if a customer of Finch API is using a payroll app, every time a payroll data changes — such as changes in salary, new investment, additional deductions etc — delta syncs inform Finch API of the specific change in the source app.

There are two ways to handle delta syncs — webhooks and polling.

In both the cases, Finch API serves via its stored copy of data (explained below)

In the case of webhooks, the source app sends all delta event information directly to Finch API as and when it happens. As a result of that “change notification” via the webhook, Finch changes its copy of stored data to reflect the new information it received.

Now, if the third party app does not support webhooks, Finch API needs to set regular intervals during which it polls the entire data of the source application to create a fresh copy. Thus, making sure any changes made to the data since the last polling is reflected in its database. Polling frequency can be every 24 hours or less.

This data storage model could pose several challenges for your sales and CS team where customers are worried about how the data is being handled (which in some cases is stored in a server outside of customer geography). Convincing them otherwise is not so easy. Moreover, this friction could result in additional paperwork delaying the time to close a deal.

Data syncs between unified API and your app

The next step in data sync strategy is to use the user data sourced from the third party app to run your business logic. The two most popular approaches for syncing data between unified API and SaaS app are — pull vs push.

What is Pull architecture?

Pull model is a request-driven architecture: where the client sends the data request and then the server sends the data. If your unified API is using a pull-based approach, you need to make API calls to the data providers using a polling infrastructure. For a limited number of data, a classic pull approach still works. But maintaining polling infra and/making regular API calls for large amounts of data is almost impossible.

What is Push architecture?

On the contrary, the push model works primarily via webhooks — where you subscribe to certain events by registering a webhook i.e. a destination URL where data is to be sent. If and when the event takes place, it informs you with relevant payload. In the case of push architecture, no polling infrastructure is to be maintained at your end.

How does Finch API send you data?

There are 3 ways Finch API can interact with your SaaS application.

First, for each connected user, you are required to maintain a polling infrastructure at your end and periodically poll the Finch copy of the customer data. This approach only works when you have a limited number of connected users.
You can write your own sync functions for more frequency data syncs or for specific data syncing needs at your end. This ad-hoc sync is easier than regular polling, but this method still requires you to maintain polling infrastructure at your end for each connected customer.
Finch API also uses webhooks to send data to your SaaS app. Based on your preference, it can either send you notification via webhooks to start polling at your end, or it can send you appropriate payload whenever an event happens.

How does Knit API send data?

Knit is the only unified API that does NOT store any customer data at our end.

Yes, you read that right.

In our previous HR tech venture, we faced customer dissatisfaction over data storage model (discussed above) firsthand. So, when we set out to build Knit Unified API, we knew that we must find a way so SaaS businesses will no longer need to convince their customers of security. The unified API architecture will speak for itself. We built a 100% events-driven webhook architecture. We deliver both the initial and delta syncs to your application via webhooks and events only.

The benefits of a completely event-driven webhook architecture for you is threefold —

It saves you hours of engineering resources that you otherwise would spend in building, maintaining and executing on polling infrastructure.
It ensures on-time data regardless of the payload. So, you can scale as you wish.
It supports real time use cases which a polling-based architecture doesn’t support.

Finch API vs Knit API

For a full feature-by-feature comparison, see our Knit vs Finch comparison page →

Let’s look at the other components of the unified API (discussed above) and what Knit API and Finch API offers.

1. Authorization & authentication

Knit’s auth component offers a Javascript SDK which is highly flexible and has a wider range of use cases than Reach/iFrame used by the Finch API for front-end. This in turn offers you more customization capability on the auth component that your customers interact with while using Knit API.

2. Ongoing integration Management

The Knit API integration dashboard doesn’t only provide RCA and resolution, we go the extra mile and proactively identify and fix any integration issues before your customers raises a request.

Knit provides deep RCA and resolution including ability to identify which records were synced, ability to rerun syncs etc. It also proactively identifies and fixes any integration issues itself.

In comparison, the Finch API customer dashboard doesn’t offer as much deeper analysis, requiring more work at your end.

Final thoughts

Wrapping up, Knit API is the only unified API that does not store customer data at our end, and offers a scalable, secure, event-driven push data sync architecture for smaller as well as larger data loads.

By now, if you are convinced that Knit API is worth giving a try, please click here to get your API keys. Or if you want to learn more, see our docs

Insights

Our detailed guides on the integrations space

Insights

Aug 14, 2026

Knit Unified API Review 2026: Architecture, Products, and When it Wins

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.

Tier	Price	Connectors	Sync Frequency	Key Limits
Launchpad	Free	Limited	—	100 API calls/month, 5 MCP servers, no credit card
Individual	$29/month	Limited	—	5,000 API calls/month
Start Up	$499/month	All 150+	24-hour fixed	3-day log retention, email support only
Scale Up	Custom	All 150+	Flexible	Whitelabel auth, 30-day logs, priority support
Enterprise	Custom	All 150+	Flexible	Multi-data-center, 90-day logs, SAML SSO, dedicated AM

The critical constraint at Start Up is the 24-hour sync frequency cap. Teams with deprovisioning, payroll trigger, or real-time event workflows need Scale Up. Launchpad is a real evaluation path — no credit card, immediate access to MCP Hub and the core API.

‍

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.

Insights

Aug 13, 2026

A Detailed Evaluation of Nango as an Integration Platform (2026)

Nango is a well-engineered integration infrastructure platform for engineering teams who want code-level ownership of their entire integration layer. If your team includes dedicated integration engineers, writes TypeScript natively, and values the ability to read, modify, and own every line of sync logic - Nango is the most developer-controlled option in this category. Its 10,700+ GitHub stars, 194 releases, and growing AI agent compatibility reflect sustained, genuine development momentum.

The evaluation changes for teams without integration engineering bandwidth. Nango provides the runtime for integrations - not the integrations themselves. When a vendor says "900+ APIs supported," that means authentication and proxying infrastructure for 900+ APIs, not 900 pre-built, maintained, normalized data connectors. Teams expecting the latter will find Nango more demanding than anticipated. Both realities are covered in full below.

What Nango Does

Nango is best understood as an integration infrastructure platform - a layer between your application and external APIs that handles operational concerns so your team can focus on business logic. The platform is built around three core primitives:

Auth - Managed OAuth 1.0/2.0, API key handling, and automatic token refresh for 800+ APIs. Authentication is handled at the platform level: no per-provider OAuth implementation, no token storage logic, no refresh scheduling.
Proxy - An authenticated request layer that resolves the provider, injects credentials, normalizes rate-limit responses, and handles retries. Your application sends requests to Nango's proxy; Nango handles the provider-specific complexity.
Functions - A TypeScript-based runtime where teams deploy custom integration logic. Functions run in Nango's cloud infrastructure (or your own) with built-in observability, per-tenant isolation, scheduled execution, and persistent storage.

What Nango does not provide by default: opinionated, pre-built data schemas. There is no out-of-the-box "Employee" object that normalizes differences between BambooHR, Workday, and HiBob into a single API surface. Your team writes the TypeScript that defines what normalization means for your specific use case. Nango provides the infrastructure; your engineers provide the logic.

This is a defensible architectural decision - it gives teams flexibility that managed platforms cannot match - but it requires clear expectations at evaluation time.

Architecture Deep Dive

Understanding how Nango is architected reveals why it excels for some teams and creates friction for others.

The Code-First Runtime Model

Teams using Nango author integration logic as TypeScript "sync scripts" - functions that run on Nango's distributed runner infrastructure on a schedule or in response to triggers. These scripts pull data from external APIs, transform it, and write it to Nango's storage layer, where your application consumes it via Nango's REST API or MCP server.

Nango ships approximately 250+ TypeScript script templates as starting points across common APIs. These are community-maintained starting points - useful scaffolding, but not production-ready connectors. Real-world implementations require field mapping, pagination handling, error boundary logic, and tenant-specific customization. The templates accelerate the starting point; your engineering team owns the finishing line.

This architecture is fundamentally different from managed unified API platforms, where the vendor maintains connector logic and your team calls normalized endpoints.

Self-Hosted vs. Cloud

Nango Cloud - Fully managed infrastructure with usage-based billing. Nango handles scaling, uptime, and security. Synced record data is cached in Nango's Postgres infrastructure for up to 60 days. SOC 2 Type II, GDPR, and HIPAA certifications apply to this deployment model.

Self-Hosted - You provision and operate Nango on your own infrastructure. The minimum production-grade setup requires:

Five Node.js services (Server, Persist, Runner, Jobs, Orchestrator) - 1 CPU and 2 GB RAM each
Postgres - 2 CPU, 8 GB RAM, 128 GB storage
Redis - 128 MB
Elasticsearch - 2 vCPU, 1 GB RAM, 30 GB storage
Object storage - less than 500 MB

This is a non-trivial infrastructure footprint. Critically, production self-hosting - including Functions, Webhooks, and the MCP server - requires an Enterprise plan subscription. The "free self-hosted" option available to teams covers only a subset of platform capabilities. Engineers evaluating Nango for $0 total cost should validate which specific features their production use case requires against the feature matrix before committing.

Licensing Reality

Nango is released under the Elastic License 2.0, not MIT or Apache 2.0. This is an important distinction for procurement teams: the Elastic License permits internal use, self-hosting for your own organization, and modification. It prohibits reselling Nango as a hosted service to external customers without a commercial agreement. For the vast majority of SaaS teams using Nango internally, this restriction does not apply - but it should be reviewed for platform engineering use cases.

How It Differs from Unified APIs

A schema-normalized unified API (Merge, Knit, Apideck) presents a consistent API surface across multiple underlying providers. Your code calls /hris/employees and receives a normalized response regardless of whether the customer runs Workday, BambooHR, or Personio. The vendor maintains that normalization layer.

Nango gives you the infrastructure to build that normalization layer yourself. If you need custom schemas that precisely fit your data model - common in vertical SaaS or multi-category products - Nango's approach is architecturally superior. If your requirements are standard HRIS or CRM sync patterns, rebuilding normalization from scratch means duplicating work that managed platforms have already done and continuously maintain.

Integration Coverage

Nango's catalog covers 800-900+ APIs at the authentication and proxy layer, with TypeScript sync script templates for approximately 250+ of those. The breadth is genuine: the list extends well beyond the HRIS/ATS/CRM verticals that dominate managed unified API catalogs, including developer tooling, vertical SaaS, marketing platforms, and consumer APIs that managed platforms rarely prioritize.

What "Coverage" Actually Means

The critical distinction for evaluation purposes:

Authentication coverage (800-900+ APIs): Nango can authenticate your application against these APIs. This is fully managed and production-ready.
Proxy coverage (800-900+ APIs): Nango's proxy layer handles rate limiting, retries, and credential injection for these APIs.
Sync script templates (~250+ APIs): Nango ships starting-point TypeScript logic for data syncing. These require customization for production deployment.

A managed unified API platform listing 100 connectors has typically invested significantly more engineering effort per connector - including edge case handling, pagination normalization, schema maintenance, and ongoing updates when APIs change. Comparing API count between code-first and managed platforms conflates infrastructure coverage with connector maturity.

AI Agent Integration Capabilities

One of Nango's most distinctive recent developments is native support for AI coding agents as integration builders. The platform integrates with 18+ coding agents - including Claude Code, Cursor, Codex, and Gemini CLI - enabling these agents to research an API, write a TypeScript integration function, and deploy it to Nango's runtime, all within a single session without requiring a local project.

The built-in MCP server at https://api.nango.dev/mcp exposes every deployed action as a deterministic tool call over both REST and MCP protocols. This makes Nango distinctly interesting for AI-native engineering teams: rather than maintaining a catalog of pre-built integrations, teams can provision integrations on demand through agent-driven development.

In practice, coding agents writing TypeScript sync scripts still benefit from human review before production deployment. The value is acceleration and reduction of boilerplate - not elimination of engineering oversight. But for teams already running AI-assisted development workflows, Nango's agent compatibility creates real productivity leverage.

Pricing

Nango's current pricing structure (verify at nango.dev for the most current rates):

Plan	Price	Key Inclusions	Limitations
Free	$0/month	Basic auth management, limited integrations	Integration count cap; not suitable for production
Starter	~$50/month	Unlimited connections, usage-based metering, SOC 2 Type II	No HIPAA; no OpenTelemetry export; standard support
Growth	~$500/month	OpenTelemetry log export, custom auth UI branding, priority support	No HIPAA BAA; custom usage limits not available
Enterprise	Custom	HIPAA with BAA, custom usage limits, full self-hosting features	Required for production self-hosting (Functions, Webhooks, MCP)

Pricing approximate as of mid-2026 — verify current rates at nango.dev. The Starter-to-Growth jump is significant in absolute terms but competitive relative to managed alternatives (Merge entry pricing ~$650/month). Engineering time for integration development is not included in subscription cost and should be modeled separately.

The free tier provides a functional evaluation environment with meaningful limitations on integration count. The Starter-to-Growth gap is substantial in absolute terms but competitive relative to the managed alternatives landscape - Merge's entry pricing is typically reported at $650/month for comparable team-level access.

Total Cost of Ownership: The Full Picture

Cloud subscription cost is only one component of Nango's total cost of ownership. For honest evaluation, engineering teams should model:

Initial integration development: Writing, testing, and deploying TypeScript sync scripts for each integration your customers require. For a typical B2B SaaS product supporting 10-15 integrations, this represents weeks to months of engineering time.
Ongoing maintenance: API providers deprecate fields, change pagination, introduce breaking schema changes. Every change requires a sync script update. At scale - 30, 50, or more provider integrations - this maintenance burden is significant.
Self-hosting infrastructure: For data residency requirements, the DevOps overhead of operating Nango's five-service stack adds ongoing operational cost beyond the Enterprise subscription.

Teams that compute engineering time at market rates frequently find that Nango's total cost of ownership converges with or exceeds managed alternatives for standard integration categories. The calculus reverses for non-standard, high-customization scenarios where managed platforms cannot serve the use case.

Developer Experience

The developer experience on Nango is strong within its design constraints - and appropriately demanding outside them.

Where Nango Shines

Authentication is a solved problem. This is Nango's clearest strength. OAuth implementation, token storage, refresh scheduling, and multi-tenant credential isolation are handled correctly, transparently, and at scale. The engineering time this saves is real.

Full code ownership and auditability. Integration logic lives in your repository, reviewed in your PRs, versioned in your git history, and deployed through your existing CI/CD pipeline. For teams with strong engineering culture around code ownership, this is a real advantage.

Deep observability in every plan. Unlike platforms that reserve logging and tracing for Enterprise tiers, Nango includes full request/response observability in all paid plans, with OpenTelemetry export available from the Growth tier. This is a better default than competitors.

Active development and community. With 10,700+ GitHub stars, 1,100+ forks, and a sustained release cadence averaging multiple releases per month through mid-2026, Nango is actively maintained. The open codebase means issues can be diagnosed and contributed to by the community.

Coding agent compatibility. For teams using AI coding assistants as primary development tools, Nango's native agent integrations are a useful accelerator. The engineering interface is designed for agent-assisted development, not bolted on.

Where It Becomes a Burden

Maintenance at scale compounds over time. Managing 20, 30, or 50 TypeScript sync scripts - each with provider-specific quirks around pagination, rate limits, and field naming - grows from "acceptable overhead" to "significant operational burden" as the integration catalog expands.

Custom tenant requirements require code changes. When an enterprise customer requires a custom field mapping or tenant-specific data transformation, Nango requires a code change and deployment rather than a configuration update. For high-volume, highly customized enterprise SaaS, this creates deployment pressure.

Webhook reliability constraints. Nango's webhook processing system has a 20-second timeout and a maximum of two retry attempts. For event-driven pipelines where event delivery guarantees matter, teams must implement compensating idempotency logic and evaluate whether these constraints fit their reliability requirements.

Self-hosting is operationally demanding. Teams that select self-hosting for data sovereignty reasons frequently underestimate the ongoing DevOps investment. Auto-scaling is not provided out of the box; capacity planning requires understanding Nango's architecture deeply enough to tune Runner scaling and Postgres performance independently.

Compliance and Security

Nango's compliance posture is credible for enterprise evaluation.

Certifications (cloud): SOC 2 Type II, GDPR compliance, and HIPAA with BAA available on Enterprise plans. These credentials support regulated industry deployment and enterprise security review.

Self-hosted data sovereignty: In self-hosted deployments, customer API credentials remain in the organization's own Postgres database, encrypted with an encryption key that Nango never holds. Authentication tokens never leave the organization's infrastructure. For teams with strict data residency requirements - healthcare, financial services, government - this is a real control worth evaluating.

Source auditability: Nango publishes its full platform source under the Elastic License 2.0. Security teams can audit credential storage, encryption implementation, token refresh logic, and runner isolation without relying on vendor attestations. This transparency became more notable following the May 2026 Composio breach, which demonstrated the risks inherent to centralized, opaque credential storage in closed-source platforms.

Cloud data handling: In Nango-managed cloud deployments, synced record data is cached in Nango's Postgres infrastructure. Teams with zero-tolerance for third-party data storage should evaluate the proxy-only deployment mode or self-hosting, and should explicitly validate what data Nango persists versus passes through in their specific implementation.

Honest Limitations

These constraints are not disqualifiers for the right team. They are accurate conditions that must be understood before making a purchasing decision.

The "900 APIs" Distinction

Nango's API catalog breadth is frequently the first number cited in evaluations - and the most commonly misread. It is technically accurate. It does not indicate 900 pre-built, continuously maintained, schema-normalized data connectors.

To evaluate real connector depth for your use case: request a live demo against the specific providers your customers use. Examine the TypeScript sync script templates for those providers. Understand what customization they will require before production deployment. The answers to these questions determine whether Nango's catalog breadth translates into reduced integration engineering effort for your specific needs.

Engineering Overhead Is the Architecture, Not a Side Effect

The central architectural premise of Nango - that integration logic should be code your team owns - makes engineering overhead structural and permanent. Every new integration requires engineering investment. Every API change requires an engineering response. Teams that do not plan for this correctly at the outset will face a difficult recalibration once the integration backlog grows beyond a few providers.

Production Self-Hosting Requires Enterprise Subscription

Free self-hosting covers basic auth management. Production-grade self-hosting - including Functions, Webhooks, MCP server, RBAC, and advanced observability - requires an Enterprise plan. This is a legitimate business model, but teams selecting Nango specifically for $0 cost must verify the complete feature matrix against their production requirements.

No Normalized Unified Schema by Default

Nango is not a unified API in the sense that Merge, Knit, or Apideck are. It provides infrastructure to build one. For teams whose integration needs map cleanly onto standard categories (HRIS, ATS, CRM, Ticketing, Accounting), the question is whether building and maintaining your own normalization layer is the highest-value use of your engineering team's time.

Who Nango Is Best For

Engineering-led product teams with one or more dedicated integration engineers who are comfortable owning and maintaining TypeScript sync logic at scale.
Teams with non-standard integration requirements where managed platforms' fixed schemas do not accommodate the data model or the specific providers needed.
Open-source-preference organizations that require auditability, self-hosting capability, or the ability to contribute to and modify the platform itself.
AI-native engineering teams using coding agents as primary development tools, where Nango's agent-compatible integration model and built-in MCP server create real workflow advantages.
Companies building for vertical or niche APIs not covered by managed unified API catalogs - developer tools, regional SaaS, industry-specific platforms.

Who Should Evaluate Alternatives

Teams without dedicated integration engineers. Nango's operational model assumes integration engineering capacity. Without it, the platform creates a maintenance burden that cannot be sustainably managed.
Product teams expecting pre-built, managed connectors. If the expectation is a vendor-maintained connector library that your team configures rather than codes, Nango does not match that operational model.
Teams requiring zero third-party data storage. In cloud mode, Nango caches synced record data. Teams in regulated industries or with contractual zero-storage obligations need to evaluate carefully.
Teams needing normalized schemas across standard categories. For standard HRIS, ATS, CRM, Ticketing, or Accounting integration patterns, managed unified API platforms have already invested the engineering effort your team would need to replicate with Nango.
Fast-moving teams without integration engineering bandwidth. If integrations are a product requirement but not a core engineering investment area, the ongoing maintenance obligation Nango creates will compete with product roadmap priorities.

Alternatives Worth Considering

Platform	Model	Engineering Overhead	Data Handling	AI / MCP	Pricing
Nango	Code-first infrastructure	High	Caches in Nango Postgres (cloud)	MCP server (build)	Free / ~$50-$500/mo / Enterprise
Knit	Managed, zero-storage, 13+ categories	Minimal	Zero-storage (stateless)	MCP server (consume)	Flexible
Merge	Managed, broad standard categories	Minimal	Merge stores linked account data	Partial	From ~$650/mo
Apideck	Managed, developer-experience-first	Minimal	Apideck stores data	No	Per connection
Truto	Declarative / JSON-config driven	Medium	Configurable	No	Usage-based

Data accurate as of mid-2026. Nango and Knit are architecturally complementary, not competing: Nango is infrastructure for teams that want to build and own integration logic; Knit is a managed layer for teams that want to ship integrations without writing or maintaining sync code. Verify current pricing and connector counts with each vendor before procurement decisions.

On architectural differences: Knit and Nango serve opposite operational models. Nango provides infrastructure for teams to build and own their integration logic - high control, high engineering investment. Knit provides a fully managed, stateless integration layer where customer data is never cached: webhook-first delivery, 100+ pre-built connectors across 13 categories (HRIS, ATS, CRM, Accounting, Ticketing, and more), MCP server support, and an AI connector builder that ships new integrations within two days. Teams that want to write integrations should evaluate Nango. Teams that want to ship integrations without writing or maintaining sync code should evaluate Knit. These are different operational bets, not better-or-worse on an absolute scale.

FAQ

Is Nango truly open source?

Nango is source-available under the Elastic License 2.0. This permits internal use, self-hosting, and modification within a single organization. It does not qualify as OSI-approved open source, and it prohibits offering Nango as a hosted service to third parties. For most SaaS teams using Nango for their own product integrations, these restrictions do not apply. For platform engineering teams building multi-tenant hosted services, the license should be reviewed before committing.

How many pre-built, production-ready integrations does Nango provide?

Nango provides authentication and proxying infrastructure for 800-900+ APIs, and TypeScript sync script templates for approximately 250+ of those. These templates are starting points, not production-ready connectors. They commonly require field mapping customization, pagination handling, and edge-case logic before deploying to production. Evaluate the specific template for each API your customers use - the quality and completeness varies by provider.

What does it cost to self-host Nango in production?

Self-hosting Nango at production scale requires five Node.js services, Postgres (2 CPU/8 GB RAM/128 GB storage), Redis, Elasticsearch, and object storage. Full feature availability - including Functions, Webhooks, and the MCP server - requires an Enterprise plan subscription. DevOps overhead for maintaining this infrastructure should be factored explicitly into total cost of ownership alongside the subscription cost.

How does Nango support AI agent use cases?

Nango ships a built-in MCP server exposing every deployed action as a deterministic tool call over REST and MCP protocols. It integrates natively with 18+ coding agents including Claude Code, Cursor, and Codex. Coding agents can research an API, write the integration function, and deploy it to Nango's runtime. This positions Nango as infrastructure for building agentic integrations - teams write custom tool definitions and data syncs; Nango manages the runtime. For teams wanting to consume pre-built AI-ready integrations without writing code, managed platforms with native MCP support are a better fit.

What are Nango's webhook reliability constraints?

Nango's webhook processing system has a 20-second timeout per event and a maximum of two retry attempts. For high-throughput or high-reliability event pipelines, teams should implement idempotency guarantees in their own application layer and validate whether these constraints meet their SLA requirements. Applications that cannot tolerate missed webhook events need compensating architecture.

How does Nango compare to Knit for teams building AI-native SaaS?

Nango and Knit address AI-native integration from opposite architectural directions. Nango gives coding agents the tools to build custom integration logic on demand - a strong fit for teams that want code-level control and have the engineering capacity to sustain it. Knit provides a fully managed, stateless layer with pre-built connectors across 13 categories, MCP server support, and zero integration engineering overhead - a strong fit for teams that want to ship integrations quickly without maintaining sync code. The right choice depends on whether integration ownership is a core product investment for your team or an operational requirement to fulfill efficiently.

Pricing, feature availability, API counts, and certification status are current as of August 2026 and subject to change. Verify directly at nango.dev before making procurement decisions.

Knit is a unified API platform covering 13+ integration categories with a webhook-first, zero-storage architecture and MCP server support for AI agent workflows. SOC 2 Type II and ISO 27001 certified. G2 rating: 4.9/5 for Ease of Integration.‍

Insights

Aug 13, 2026

A Detailed Evaluation of Kombo as a Unified HR API Platform (2026)

Kombo is a technically credible, compliance-first unified HR API built for a specific audience: HR tech companies that need deep, reliable connectivity into European ATS and HRIS systems. For that use case, it is among the strongest options available in 2026. It earned a $25M Series A in February 2026 (bringing total funding to $30M), holds a 4.8/5 G2 rating across 87 reviews, and achieved the highest quality-of-support score (9.9/10) in the unified API category. But Kombo's strength is inseparable from its constraint: it covers four HR-adjacent categories and nothing else, uses a sync-and-store data model, and as of August 2026 has not shipped AI agent infrastructure. This evaluation breaks down where Kombo earns its reputation, where it creates architectural obligations you should understand before committing, and which teams should be looking at alternatives.

What Kombo Does

Kombo (kombo.dev) is a unified API platform founded in 2022 and headquartered in Berlin, Germany. Its core product lets software companies connect once to Kombo's API and gain immediate access to pre-built integrations across four HR-adjacent categories:

HRIS & Payroll - employee records, payroll data, org structures, absences, timesheets, documents, performance reviews
ATS (Applicant Tracking Systems) - candidates, applications, job postings, stages, offers, screening questions
Assessment & Background Check - third-party assessment platforms integrated into hiring workflows
LMS (Learning Management Systems) - learning and onboarding systems tied to workforce development

Instead of building and maintaining dozens of individual integrations as your customer base grows across different HR systems, you build one integration to Kombo and it handles the connectors, data normalization, and ongoing maintenance as upstream systems change.

What distinguishes Kombo from horizontal platforms like Merge or Apideck is a deliberate depth-over-breadth decision. Rather than spanning CRM, accounting, ticketing, email, and calendar alongside HR, Kombo concentrated its engineering investment within HR. That bet is most visible in its European system coverage and in the quality of its HR-specific data models.

As of mid-2026, Kombo works with 300+ companies, including Indeed, Paychex, HireVue, Edenred, Gem, Experian, Greenhouse, Factorial, and TestGorilla. The company raised $25M in Series A funding in February 2026 led by Volition Capital, with participation from Y Combinator, Acadian Ventures, and 468 Capital.

Architecture Deep Dive

Kombo's architecture is a sync-and-store model combined with regional deployment isolation. Understanding both is important before committing to the platform.

How Data Sync Works

Kombo pulls data from connected HRIS and ATS systems on a scheduled polling basis and stores a normalized copy in its own infrastructure. When your application calls Kombo's API, it reads from Kombo's locally cached copy rather than hitting the source system in real time. Kombo supplements polling with webhook notifications that alert you when sync events occur.

The trade-off: reads are fast and consistent because they are decoupled from source system latency and availability. The cost is inherent lag - the time between a change occurring in the source ATS or HRIS and that change appearing in Kombo's copy depends on the polling interval configured for each integration. Kombo does not publicly disclose default polling intervals per integration, so teams with strict freshness requirements should ask specifically during evaluation.

The more significant implication is data storage: this architecture means employee PII and candidate data is mirrored into Kombo's infrastructure, not merely proxied through it. Kombo manages this with strong security controls (detailed in the Compliance section below), but it is an architectural fact that has procurement consequences for enterprise buyers.

Regional Deployment Isolation

Kombo operates fully independent deployments across two regions:

EU region: api.kombo.dev
US region: api.us.kombo.dev

These are not logical separations within a shared system - they are independent deployments with separate databases, sync workers, and API layers. API keys created in one region cannot authenticate against the other. Data does not traverse regional boundaries.

For EU-based companies with GDPR data residency requirements, this architecture provides a harder guarantee than most platforms offer. The global dashboard frontend routes to the appropriate datacenter based on account region.

Passthrough API

For scenarios where Kombo's normalized data model does not expose what you need, the platform provides a passthrough API that lets you send requests directly to the underlying connected system using that system's native schema. A standard escape hatch in unified API design - it acknowledges that normalization is always incomplete for edge cases while preserving the unified abstraction for the majority of use cases.

Integration Coverage

ATS Coverage: 70+ Systems

Kombo's ATS coverage spans 70+ systems. Major platforms include Greenhouse, Ashby, Lever, SmartRecruiters, Oracle Recruiting Cloud, Workday Recruiting, SAP SuccessFactors Recruiting, Bullhorn, iCIMS, and Jobvite.

European-specific ATS systems where Kombo shows particular depth include Softgarden (widely used in the German market), Recruitee, Umantis, onlyfy (formerly XING Jobs), and several UK-market systems that US-first platforms tend to under-invest in. This EU-specific breadth is where the platform's German origins translate into a concrete advantage.

HRIS Coverage: 87+ Systems

HRIS coverage spans major global platforms - Workday, SAP SuccessFactors, UKG Pro, UKG Ready, Oracle HCM, BambooHR, ADP Workforce Now, Dayforce, Cornerstone OnDemand - alongside a notably strong set of European-specific systems: Personio, PayFit, AFAS Software, Sage HR, rexx systems, HR WORKS, Kenjo, HeavenHR, and Factorial. Several of these are unavailable or poorly mapped on US-primary unified APIs, and the field-level implementation quality (covering German-specific employment fields, Dutch HR data structures, UK payroll nuances) reflects accumulated domain expertise.

Assessment and LMS

Kombo claims distinction as the only unified HR API platform offering both Assessment and LMS categories. The depth of connector coverage in these two categories is less mature than its ATS and HRIS coverage - teams evaluating Kombo primarily for Assessment or LMS should verify specific system support and field coverage during the sales process rather than relying on category-level claims.

What Is Not Covered

Kombo explicitly does not cover CRM, accounting, ticketing, email, calendar, communication, e-signature, expense management, or subscription management. Kombo's own documentation notes that companies needing integrations outside HR will need to combine Kombo with other specialized solutions.

Pricing

Kombo uses a platform fee plus flat per-customer connection fee model with unlimited API calls. Specific pricing is not published publicly and requires a direct quote from the sales team.

The structure suits B2B HR software companies: your cost scales with the number of active customer connections, not with API call volume. For products with recurring, consistent usage patterns - which describes most HR integrations - this is easier to budget than per-call pricing.

Enterprise pricing, on-premises deployment (referenced in the Series A announcement as a future option), and custom SLA terms require direct negotiation. No self-serve tier with published pricing exists as of August 2026.

Early-stage teams should request pricing details before investing significant engineering time in evaluation - without published pricing it is impossible to model cost-per-customer without a sales conversation.

Developer Experience

Documentation and Onboarding

Kombo's documentation is consistently rated as clear and complete across G2 reviews, with multiple reviewers reporting working integrations within days of starting evaluation. Sandbox access is available for most connected systems, which meaningfully reduces the time needed to test against specific ATS or HRIS configurations before production deployment.

Core Developer Tooling

RESTful unified API with consistent endpoint structure across all connected systems
Webhook notifications for sync events
Custom field read/write capability (mapping custom fields from source systems to your unified schema)
Remote data access for system-specific fields not covered by the normalized model
Centralized dashboard with sync status tracking, authentication issue alerts, and searchable request logs
Pre-built UI components for the customer-facing connection flow

Support Model

Kombo's support model is its most consistent differentiator across independent reviews. Customers receive dedicated Slack channels with access to engineers who carry domain expertise in specific HR systems. On G2, Kombo's quality of support score is 9.9/10 - the highest in the unified API category across 87 verified reviews. Multiple reviewers describe getting meaningful technical help within hours, including for edge cases in specific EU HR systems.

Known Friction Points

G2 reviewers identify several recurring issues:

ATS sandbox approval delays: Accessing sandboxes for certain enterprise ATS systems is gated by approval processes controlled by the ATS vendors, not Kombo. iCIMS was cited with delays of three to six months - a real planning constraint for teams that need to validate against specific systems before committing.
Write-back depth: Several reviewers noted that sending data back to ATS systems is less complete than reading from them. Pressure-test specific write operations you depend on during evaluation.
Custom field mapping UX: The interface for configuring custom field mappings was noted as a usability gap - functional, but not as intuitive as the read-side experience.

Compliance and Security

What "GDPR-Native" Actually Means for Kombo

"GDPR compliant" appears on nearly every software vendor's marketing page. It is worth understanding precisely what Kombo's compliance architecture entails and where it goes further than a typical compliance checkbox.

Regional architectural isolation: Kombo's EU and US regions are fully independent deployments. Employee and candidate data for EU-region accounts never routes through US infrastructure - not as transit, not for analytics, not for replication. This is enforced at the infrastructure level, at the API key and database layer, not just through policy.

Deletion mirroring: Under GDPR, data subjects have the right to erasure. Kombo handles this by monitoring for deletions in the source system: when a record is removed from the connected HRIS or ATS, Kombo detects the deletion during the next sync and removes the mirrored record from its own database. The deletion is driven by the source system event, not by a separate API call from your application - though the timing is tied to the polling interval.

DSGVO certification: Kombo holds explicit DSGVO (Germany's implementation of GDPR) certification, reflecting the level of regulatory specificity expected by German enterprise procurement teams.

Security Certifications

SOC 2 Type II
ISO 27001
HIPAA
GDPR / DSGVO

Additional controls include encryption at rest, independent penetration testing, IP allowlisting for API keys, API key expiration policies, role-based dashboard access, and audit logging for sensitive operations.

For EU-based enterprise sales cycles - particularly in financial services, healthcare, and regulated industries where security questionnaires are a standard procurement step - this certification stack, combined with the architectural data residency guarantee, frequently shortens the compliance review period compared to vendors offering only logical separation or contractual commitments without architectural backing.

Honest Limitations

Geographic Concentration Within HR Coverage

Kombo's integration count across ATS and HRIS is competitive. But integration counts obscure something important: the completeness of field mapping and write operations for individual systems varies significantly. Kombo's depth in German, UK, French, Dutch, and Nordic HR systems - the implementation-level completeness of specific fields, edge-case workflows, and write operations - reflects years of European market focus. Its coverage of US regional payroll providers, mid-market US ATS platforms, and APAC HR systems is thinner.

For a US-primary or APAC-primary company, the high-level integration count can be misleading. Before committing, test the specific systems your customers use, including write operations, not just reads.

Category Scope Is Fixed at HR

Kombo does not cover and has not indicated plans to expand outside HR-adjacent categories. This enables depth within HR, but the constraint compounds over time for companies whose integration surface grows.

If your product today requires HR integrations and in 12 to 18 months will also need CRM, ticketing, accounting, or messaging integrations, building on Kombo means either adding a second unified API vendor or migrating platforms. Migrations between unified APIs are non-trivial: re-mapping data models, renegotiating pricing, rebuilding customer-facing connection flows.

Data Storage Is a Procurement Obligation

Kombo's sync-and-store model is standard architecture in the unified API category. But it is a fact that needs to surface in enterprise procurement processes. Employee records, candidate PII, salary data, and HR documents are stored in Kombo's infrastructure for as long as a connection is active. The security controls are strong, but "we store your customers' HR data in our infrastructure" is a statement that enterprise buyers require legal and security sign-off on, regardless of the certification stack.

No Native AI Agent Infrastructure

As of August 2026, Kombo does not offer a Model Context Protocol (MCP) server, AI agent framework, or structured interface for AI orchestration. Its AI Apply product (launched May 2026) uses browser agent automation to submit job applications through ATS interfaces that lack native APIs - an interesting approach to a specific problem, but distinct from exposing HR data to AI agents through a structured API.

The Series A announcement referenced future plans to enable AI agents through portable people data. That capability has not shipped. For companies building AI-native HR products - autonomous recruiting copilots, workforce planning AI, HR system chatbots - this gap means building your own orchestration layer on top of Kombo's existing API, without native tooling support.

Who Kombo Is Best For

European HR Tech Companies

If you are building an ATS, HRIS, hiring platform, or workforce tool primarily for European customers, Kombo's coverage of regional systems - Personio, PayFit, Softgarden, AFAS Software, rexx systems, Kenjo, HeavenHR - is a tangible advantage. These systems are underserved or unavailable on US-first platforms, and the implementation quality for EU-specific data fields and workflows reflects accumulated expertise, not just a connector checkbox.

ATS Platforms Expanding into European Recruitment Markets

US-based ATS vendors expanding into Europe who need to pull candidate data from or push offers into European employer HR systems benefit from Kombo's connector depth without having to build and maintain those integrations individually.

HR Tech Companies with Pure Hiring and Workforce Workflows

Assessment platform providers, background check vendors, LMS companies, and HR analytics tools that need structured, normalized access to ATS and HRIS data - and whose integration surface does not extend beyond HR - are well-served by Kombo's focused scope.

Companies Where GDPR Compliance Is a Sales Requirement, Not Just a Checkbox

Enterprise buyers in EU financial services, healthcare, and government procurement require verifiable data residency guarantees, not policy statements. Kombo's architectural isolation makes that verification auditable. For sales cycles where a data residency attestation accelerates procurement, this architectural approach has real commercial value.

Who Should Evaluate Alternatives

Global HR Tech Companies with Multi-Region Customers

Companies with significant US, APAC, and EU customer segments will encounter Kombo's European concentration as a practical constraint. The headline integration count looks balanced; the field-level completeness for US regional and APAC systems is where gaps appear. A platform with more geographically balanced investment may produce better aggregate outcomes for a globally distributed customer base.

Companies with Multi-Category Integration Needs

If your product's integration surface extends beyond HR - customers expect to connect CRM, ticketing, accounting, email, or calendar alongside their HRIS - Kombo cannot serve those needs. Operating two separate unified API vendors is workable but adds operational overhead: two vendor relationships, two monitoring setups, two data models, two pricing negotiations.

AI-Native Product Builders

Teams building AI agent-powered HR products - autonomous recruiting workflows, workforce planning copilots, HR chatbots - need infrastructure that exposes structured HR data to AI agents through defined interfaces. Kombo does not provide this natively. Until MCP server support or equivalent tooling ships, teams building in this space will need to construct their own orchestration layer.

Early-Stage Teams That Need Pricing Certainty Before Committing Engineering Resources

The absence of published pricing creates evaluation friction for early-stage teams operating under budget constraints. If a vendor's pricing model is a prerequisite for a build-vs-buy decision, not knowing Kombo's rates until after a sales cycle adds friction. Evaluate pricing early.

Category	Connector Count	Notable Systems	EU Depth
HRIS & Payroll	87+	Workday, SAP SuccessFactors, UKG Pro, BambooHR, ADP, Personio, PayFit, AFAS Software, Factorial, Kenjo	Strong
ATS	70+	Greenhouse, Ashby, Lever, SmartRecruiters, Oracle Recruiting, Workday Recruiting, Softgarden, Recruitee, Bullhorn, iCIMS	Strong
Assessment & Background Check	Multiple	Third-party assessment platforms used in hiring workflows	Moderate (verify)
LMS	Multiple	Learning and onboarding systems tied to workforce development	Moderate (verify)

250+ total integrations across 4 HR-adjacent categories as of mid-2026. HRIS and ATS coverage is the most mature. Assessment and LMS categories are less mature — verify specific system support during evaluation. Kombo does not cover CRM, accounting, ticketing, email, calendar, or communication platforms.

Knit

Knit takes a different architectural position: it operates as a stateless, zero-storage platform that does not persist customer data in its infrastructure. Data is pushed to your registered webhook endpoint in real time rather than polled and cached. For teams where GDPR's data minimization principle extends to third-party storage - meaning the preferred state is no third-party copy of employee PII - this architecture addresses that requirement structurally.

Knit covers 13+ integration categories (HRIS, ATS, CRM, Accounting, Ticketing, Email, Calendar, Communication, Meetings, E-Sign, Assessment, Expense Management, Subscription Management) with 160+ connectors, EU and global market coverage, and a native MCP server for AI agent workflows. For EU-only HR teams with no multi-category needs and a preference for Kombo's specific EU system depth, that trade-off may favor Kombo. For teams with multi-category requirements, a zero-storage preference, or AI agent workloads, the comparison shifts. Knit does offer hosting in Sweden for EU customers apart from other options for its global customers

Merge

Merge covers seven integration categories with strong US coverage and moderate EU depth. Its normalized data model is mature. It is the more established competitor in the US enterprise market but has historically invested less in EU-specific regional HR systems. Enterprise pricing is also quote-based.

Finch

Finch focuses specifically on HRIS and payroll connectivity in the US market. Its depth in US payroll data is real. For European teams or multi-category needs, it is a poor fit by design.

Apideck

Apideck covers five to six categories with a developer-friendly API and more transparent pricing than some competitors. Its EU HR coverage is less specialized than Kombo's. A reasonable option for early-stage teams that need broad coverage and can accept less depth in EU-specific systems.

FAQ

Does Kombo store my customers' employee and candidate data?

Yes. Kombo's sync-and-store architecture mirrors data from connected HRIS and ATS systems into Kombo's regional infrastructure. For EU-region accounts, data is stored on EU servers with no cross-regional transit. Security controls include SOC 2 Type II and ISO 27001 certification, encryption at rest, and audit logging. Teams with strict data minimization requirements or enterprise buyers who prohibit third-party PII storage should evaluate this architectural reality explicitly during procurement.

How many integrations does Kombo support?

As of mid-2026: 70+ ATS systems, 87+ HRIS systems, plus Assessment and LMS connectors - totaling 250+ integrations across four HR-adjacent categories.

Does Kombo handle GDPR deletion requests automatically?

Yes, through deletion mirroring. When a record is deleted from the source HRIS or ATS, Kombo detects the deletion during the next sync cycle and removes the mirrored record. The timing is tied to polling intervals rather than being instantaneous.

What are Kombo's published pricing tiers?

There are none. Kombo uses a platform fee plus flat per-customer connection fee model, but pricing requires a direct sales conversation. No self-serve or published pricing tier exists as of August 2026.

How complete are Kombo's write operations versus reads?

Write operations are supported and actively developed - employee creation with staffing entities was added in June 2026. Some G2 reviewers note that write-back depth for certain ATS systems is less complete than read depth. The passthrough API is available for write operations the normalized model does not cover. Verify specific write operations during evaluation.

Is Kombo suitable for AI agent workflows?

Not natively as of August 2026. Kombo does not offer a Model Context Protocol (MCP) server or native AI agent interface. AI Apply (launched May 2026) uses browser agent technology for ATS systems that block programmatic access - a different use case from AI agent orchestration. The Series A announcement referenced future plans in this area; those capabilities have not yet shipped.

Which EU-specific HR systems does Kombo cover that other platforms miss?

Notable EU-specific systems with documented Kombo coverage include Softgarden, AFAS Software, rexx systems, HeavenHR, Kenjo, PayFit, HR WORKS, and Personio. These are where Kombo's depth most clearly exceeds US-primary competitors.

How long does Kombo integration typically take?

Multiple G2 reviewers report going from signup to working integration in days. Sandbox access is available for most systems. Exception: certain enterprise ATS sandboxes (iCIMS specifically cited) require vendor-controlled approval processes that can take three to six months.

‍

API Directory

Curated API guides and documentations for all the popular tools

API Directory

Jul 22, 2026

Okta API Directory & Integration Guide | Knit Blog

The Okta API is a RESTful management interface for Okta's identity platform. Developers use it to automate user lifecycle management, sync directory data, manage groups and app assignments, and build SCIM provisioning integrations. It supports two authentication methods — SSWS API tokens and OAuth 2.0 scoped access tokens — and all management endpoints live under https://{yourOktaDomain}/api/v1/.

Authentication

The Okta API supports two credential types.

SSWS API tokens are the simpler option for scripts and internal tooling. Generate one in Admin Console → Security → API → Tokens, then pass it in every request as Authorization: SSWS <token>. Tokens inherit the creating admin's full privilege level and expire after 30 days of inactivity (the timer resets on each successful API call). See How to get an Okta API token for the step-by-step guide, common errors, and the one gotcha everyone hits (the scheme is SSWS, not Bearer).

OAuth 2.0 scoped access tokens are Okta's recommended approach for production integrations. Tokens are short-lived (1 hour), limited to explicitly granted scopes, and requested from your org's authorization server at /oauth2/v1/authorize. Scopes follow the okta.<resource>.<operation> pattern: okta.users.read for GET access to users, okta.users.manage for create/update/delete, and so on. Only Super Admin can grant scopes to an OAuth app.

For integrations connecting to other organisations' Okta orgs — a marketplace app or a multi-tenant product — you need OAuth 2.0, not a personal API token.

Core objects and endpoints

Resource	Example endpoint	What it's for
Users	`GET/POST /api/v1/users`, `GET/PATCH/DELETE /api/v1/users/{id}`	CRUD on user accounts; lifecycle operations (activate, deactivate, suspend, unlock)
Groups	`GET/POST /api/v1/groups`, `PUT /api/v1/groups/{id}/users/{userId}`	Manage user groups and group memberships
Applications	`GET /api/v1/apps`, `POST /api/v1/apps/{id}/users`	List app integrations and manage user/group assignments to them
System Log	`GET /api/v1/logs`	Query the org audit log — user sign-ins, admin actions, policy evaluations
User Factors	`GET/POST /api/v1/users/{id}/factors`	Enrol, list, and verify MFA factors for a specific user
Sessions	`GET /api/v1/sessions/{sessionId}`	Read and revoke active authentication sessions
Policies	`GET/POST /api/v1/policies`	Read and manage org-wide authentication and authorisation policies

Every endpoint requires Content-Type: application/json and Accept: application/json on requests that include a body. All timestamps are ISO 8601 (YYYY-MM-DDTHH:mm:ss.SSSZ).

Common tasks

Sync users from Okta to your product — poll GET /api/v1/users?filter=status+eq+"ACTIVE" on a schedule, or use GET /api/v1/logs filtered to eventType eq "user.lifecycle.*" to get only changes.
Provision users into Okta from your app — POST /api/v1/users?activate=true with the user's profile; assign to an app with POST /api/v1/apps/{appId}/users.
List and sync group memberships — GET /api/v1/groups to list groups, GET /api/v1/groups/{id}/users to get members of a specific group.
Revoke a session on sign-out — DELETE /api/v1/users/{userId}/sessions clears all active Okta sessions for that user.
Pull the audit log — GET /api/v1/logs?since=2026-07-01T00:00:00Z with date filtering; paginate using the Link: next header value.

Rate limits and pagination

Rate limits

Okta uses a bucket-based rate limit system — limits apply per org per endpoint (or per endpoint per user for authenticated sessions), and vary based on your subscription tier, HTTP method, and whether you have the DynamicScale add-on. There is no single table of numbers that applies to all orgs.

Limit scope	Default limit
SSWS API token (per token, adjustable)	50% of the endpoint’s org-wide maximum
Authenticated users (Admin Console / End-User Dashboard)	40 requests / 10 sec / user / endpoint
Non-authenticated auth endpoints (`/api/v1/authn`, `/oauth2/v1/token`)	4 requests / sec per username
Identity Engine endpoints	20 requests / 5 sec per user; 10 / 5 sec per state token

When a limit is exceeded, Okta returns HTTP 429 Too Many Requests. Inspect the response headers to back off correctly:

X-Rate-Limit-Limit — total requests allowed in the current window for this bucket
X-Rate-Limit-Remaining — requests remaining before the limit is hit
X-Rate-Limit-Reset — Unix timestamp (UTC) when the window resets

Monitor live usage through the Rate Limit Dashboard in Admin Console → Reports → Rate Limits, or query the System Log for system.operation.rate_limit.warning and system.operation.rate_limit.violation events (Okta Docs, Rate limits).

Pagination

All list endpoints that return collections support cursor-based pagination. Pass limit to control page size, and use the after cursor from the Link response header to fetch the next page — do not construct the next-page URL yourself, as cursor formats can change without notice.

GET /api/v1/users?limit=200
→ HTTP 200
Link: <https://yourcompany.okta.com/api/v1/users?limit=200>; rel="self"
Link: <https://yourcompany.okta.com/api/v1/users?limit=200&after=00u1...>; rel="next"

The end of the list is signalled by the absence of a rel="next" link — except for the System Log, which always returns a next link to support continuous polling.

Build it yourself vs. use a unified API

If you're connecting one Okta org for internal use, the API is straightforward. The complexity scales when you're connecting Okta alongside BambooHR, Workday, or other HRIS/directory tools in a product — each has its own auth model, user schema, group structure, and lifecycle event format.

Knit's unified HRIS API handles Okta's auth token management, rate-limit backoff, and cursor pagination for you, and normalises users, groups, and directory data across all connected HRIS and directory connectors behind one schema. You integrate once and add connectors from a list rather than re-engineering for each one. See the Okta integration page for what Knit syncs, or book a demo to see it against your own Okta org. You can also sign up free and test with a sandbox.

Knit's Okta + AI/MCP

If your team is building AI agents or workflows that need to query Okta user and group data, Knit exposes the Okta connector as an LLM tool and MCP server — letting agents call normalised HRIS APIs without handling Okta-specific auth or pagination. See Knit LLM Tools for Okta for details.

FAQ

What is the Okta API used for?

‍The Okta API is used to programmatically manage users, groups, applications, MFA factors, sessions, and policies in an Okta org. Common use cases include user provisioning and deprovisioning, syncing directory data to a product's database, automating group-based app access, and querying the audit log for compliance reporting.

How do I authenticate to the Okta API?

‍The Okta API supports two authentication methods. SSWS API tokens are the simpler option — generate one in the Admin Console and include it as Authorization: SSWS <token> on every request. OAuth 2.0 scoped access tokens are Okta's recommended approach for production; they're short-lived and limited to specific scopes granted to an OAuth app. See How to get an Okta API token for step-by-step instructions on both.

What is the base URL for Okta API calls?

‍All management API calls go to https://{yourOktaDomain}/api/v1/, where {yourOktaDomain} is your org's subdomain — for example, https://yourcompany.okta.com/api/v1/. Some organisations use a custom domain instead. The HTTPS scheme is required; HTTP is not supported.

Does the Okta API support webhooks?

‍Okta uses Event Hooks and Inline Hooks rather than traditional webhooks. Event Hooks (POST /api/v1/eventHooks) deliver batched System Log events to an external endpoint. Inline Hooks intercept Okta workflows (e.g., the registration flow) and call your endpoint synchronously. Both are configured through the Admin Console or the API under /api/v1/eventHooks and /api/v1/inlineHooks.

How does Okta API pagination work?

‍Okta uses cursor-based pagination. List endpoints accept a limit parameter and return a Link: <url>; rel="next" response header pointing to the next page. Always follow the URL from the header rather than constructing it yourself — cursor formats can change. The end of a result set is signalled by the absence of a rel="next" link, except for the System Log which always returns one for continuous polling.

Sources:

‍

API Directory

Jul 22, 2026

Ashby API Integration Guide & API Directory | Knit

Ashby software is a robust recruiting platform designed to transform the way organizations manage their recruitment and talent acquisition processes. By integrating Applicant Tracking System (ATS), analytics, scheduling, Customer Relationship Management (CRM), and sourcing capabilities, Ashby offers a comprehensive solution that empowers recruiting teams to streamline their operations and make data-driven decisions. This all-in-one platform is tailored to enhance efficiency and strategic planning, making it an indispensable tool for modern recruitment teams.

One of the standout features of Ashby is its ability to seamlessly integrate with various systems through the Ashby API. This integration capability allows organizations to connect Ashby with their existing tools and platforms, ensuring a smooth flow of data and enhancing the overall recruitment process. The Ashby API is designed to be user-friendly and flexible, enabling developers to customize and extend the platform's functionalities to meet specific organizational needs. By leveraging the Ashby API, companies can optimize their recruitment strategies and achieve better outcomes.

Key Highlights of the Ashby API:

Comprehensive Data Access: The API provides endpoints to access and manage data related to candidates, applications, jobs, interviews, offers, and more. This allows for seamless integration of Ashby's functionalities into external applications. Ashby
Webhooks Support: Ashby supports webhooks to notify external systems about specific events, such as candidate updates or job postings, enabling real-time data synchronization and automation. Ashby

Getting Started with the Ashby API:

Obtain an API Key:
- Log in to your Ashby account.
- Navigate to the Developer Center to generate an API key.
- Ensure that the API key is kept secure, as it grants access to your Ashby data.
Explore API Documentation:
- Review the comprehensive API documentation available at Ashby API Documentation
- Familiarize yourself with the available endpoints, request structures, and response formats.
Set Up Webhooks (If Needed):
- If your application requires real-time updates, configure webhooks through the Ashby platform to receive event notifications.
Implement API Calls:
- Use standard HTTP methods (GET, POST, PUT, DELETE) to interact with the API endpoints.
- Ensure that each request includes the necessary authentication headers and complies with the API's data format requirements.

Additional Resources:

Integration Guides: Ashby provides guides and examples to assist in integrating their API with your applications, available within the API documentation.
Third-Party Integration Platforms: Services like Knit and Airbyte offer connectors to facilitate integration with Ashby, simplifying the development process.

Ashby API Endpoints

Below is a comprehensvie list of Ashby API endpoints with details on each endpoint:

API Key

POST https://api.ashbyhq.com/apiKey.info : The apiKey.info API endpoint is used to retrieve information about the API key being used to make the request. It requires the 'apiKeysRead' permission. The request is made using the POST method to the URL 'https://api.ashbyhq.com/apiKey.info'. The request headers must include 'accept' and 'content-type' set to 'application/json'. The request body is an empty JSON object. The response can either be a success response containing the API key's title and creation date or an error response with a list of error messages.

Application

POST https://api.ashbyhq.com/application.addHiringTeamMember : The Add Hiring Team Member to Application API allows you to add an Ashby user to the hiring team at the application level. It requires the 'candidateWrite' permission. The request body must include 'applicationId', 'teamMemberId', and 'roleId', all of which are UUIDs. The response can either be a success response, which includes details about the user added to the hiring team, or an error response with a list of error messages.
POST https://api.ashbyhq.com/application.change_source : The Change Application Source API allows users to update the source of a specific application. It requires the 'candidatesWrite' permission. The request is made via a POST method to the endpoint 'https://api.ashbyhq.com/application.change_source'. The request body must include 'applicationId' and 'sourceId', both of which are UUIDs. The response can either be a success or an error. A successful response includes details about the application, candidate, current interview stage, source, job, and hiring team. An error response includes a list of error messages.
POST https://api.ashbyhq.com/application.change_stage : The Change Application Stage API allows users to change the stage of an application in the system. It requires the 'candidatesWrite' permission. The request must include the applicationId and interviewStageId in the body, both of which are UUIDs. Optionally, an archiveReasonId can be provided if the application is being moved to an 'Archived' stage. The response will indicate success and provide detailed information about the application, including its status, candidate details, current interview stage, source, archive reason, job details, credited user, and hiring team. In case of an error, the response will include a list of error messages.
POST https://api.ashbyhq.com/application.create : The Create Application API allows you to consider a candidate for a job by creating an application. It requires the `candidatesWrite` permission. The request body must include the `candidateId` and `jobId` as required fields. Optional fields include `interviewPlanId`, `interviewStageId`, `sourceId`, `creditedToUserId`, `createdAt`, and `applicationHistory`. The response can either be a success response with details of the created application or an error response with a list of error messages.
POST https://api.ashbyhq.com/application.info : The Fetch Application Details API allows users to retrieve application details using either an application ID or a submitted form instance ID. If both IDs are provided, the application ID takes precedence. The API requires the 'candidatesRead' permission. The request body must include either 'applicationId' or 'submittedFormInstanceId', and optionally an 'expand' parameter to include additional related data. The response includes detailed information about the application, candidate, interview stages, job, and more. The API returns a success response with application details or an error response with error messages.
POST https://api.ashbyhq.com/application.list : The List Applications API endpoint retrieves all applications within an organization. It requires the 'candidatesRead' permission. The request is made via a POST method to the URL 'https://api.ashbyhq.com/application.list'. The request body can include parameters such as 'createdAfter', 'cursor', 'syncToken', 'limit', 'expand', 'status', and 'jobId'. The response includes a success flag, a list of results with detailed application information, and pagination details like 'moreDataAvailable' and 'nextCursor'. The response also provides a 'syncToken' for synchronization purposes. In case of errors, an error response with a list of error messages is returned.
POST https://api.ashbyhq.com/application.update : The Update Application API allows users to update an existing application. It requires the `candidatesWrite` permission. The request must include the `applicationId` in the body, which is the ID of the application to be updated. Optional fields include `sourceId`, `creditedToUserId`, `createdAt`, and `sendNotifications`. The response will indicate success and provide details about the updated application, including its status, candidate information, interview stage, source, and more. In case of an error, the response will include a list of error messages.
POST https://api.ashbyhq.com/applicationFeedback.list : The List Application Feedback API endpoint allows users to retrieve all feedback associated with a specific application. It requires the 'candidatesRead' permission. The request is made via a POST method to the specified URL with headers indicating the content type as 'application/json'. The request body can include parameters such as 'createdAfter', 'cursor', 'syncToken', 'limit', and 'applicationId'. The response includes a success flag, a list of results with detailed feedback information, and pagination details like 'moreDataAvailable' and 'nextCursor'. In case of errors, an error response with a list of error messages is returned.
POST https://api.ashbyhq.com/applicationFeedback.submit : The Submit Application Feedback API allows users to submit feedback for a specific application using a feedback form. The API requires the `candidatesWrite` permission. The request body must include the feedback form details, form definition ID, application ID, and optionally the user ID and interview event ID. The feedback form supports various field types such as Boolean, Date, Email, Number, RichText, Score, Phone, String, ValueSelect, and MultiValueSelect. The response indicates whether the submission was successful and includes the submitted form instance details. In case of errors, an error response with a list of error messages is returned.
POST https://api.ashbyhq.com/applicationForm.submit : The Submit Application Form API allows users to submit an application for a job posting. It requires the `candidatesWrite` permission and the request must be of type `multipart/form-data`. The request body must include the `jobPostingId` and `applicationForm` with `fieldSubmissions`. The API supports various field types such as Boolean, Date, Email, Number, and more. The response can be a success or an error, with detailed information about the submitted form instance and any form messages.
POST https://api.ashbyhq.com/applicationHiringTeamRole.list : The List Application Hiring Team Roles API retrieves all available hiring team roles for applications within the organization. It requires the 'candidatesRead' permission. The request is made via a POST method to the specified endpoint with an 'accept' header indicating the media type as 'application/json'. The response includes a list of roles with their unique IDs and titles if successful, or an error message if the request fails.

Approval

POST https://api.ashbyhq.com/approvalDefinition.update : The Update Approval Definition API allows users to create or update an approval definition for a specific entity that requires approval. The entity must be within the scope of an approval in Ashby that is managed by the API. The request requires the 'approvalsWrite' permission. The request body must include 'entityType', 'entityId', and 'approvalStepDefinitions'. If 'approvalStepDefinitions' is empty, approval will be skipped. The response will indicate success and provide details of the approval definition or errors if the request fails.

Archive Reason

POST https://api.ashbyhq.com/archiveReason.list : The List Archive Reasons API endpoint allows users to retrieve a list of archive reasons. It requires the 'hiringProcessMetadataRead' permission. The request is made via a POST method to the URL 'https://api.ashbyhq.com/archiveReason.list'. The request body can include a boolean parameter 'includeArchived' to specify whether archived interview plans should be included. The response can either be a success response containing a list of archive reasons with details such as 'id', 'text', 'reasonType', and 'isArchived', or an error response with a list of error messages.

Assessment

POST https://api.ashbyhq.com/assessment.addCompletedToCandidate : The 'Add Completed Assessment to Candidate' API allows you to add a completed assessment to a candidate's profile. It requires the 'candidatesWrite' permission. The request body must include the candidateId, partnerId, assessment details (including assessmentTypeId, assessmentId, assessmentName, result, and metadata), and a timestamp indicating when the assessment was completed. The response will indicate success or failure, and in the case of success, it will return the details of the assessment added. In case of an error, it will return a list of error messages.
POST https://api.ashbyhq.com/assessment.cancel : The Cancel Assessment API allows partners to cancel an assessment that has been started. The request requires the 'assessment_id' in the body, which is a UUID identifying the assessment to be canceled. The response can either be a success response containing details about the canceled assessment or an error response with a list of error messages. The API is implemented by the partner and called by Ashby.
POST https://api.ashbyhq.com/assessment.start : The Start Assessment API is used to initiate an assessment for a candidate. It requires details about the assessment type, candidate, application, and job. The request body must include the assessment_type_id, candidate details (including ashby_id, first_name, last_name, email, and ashby_profile_url), application details (including ashby_id and status), and job details (including ashby_id, name, ashby_job_url, and hiring team information). The response includes a success flag and results containing the assessment_id and various metadata about the assessment, such as update requests, assessment profile URL, assessment result, cancelled reason, and additional metadata.
POST https://api.ashbyhq.com/assessment.update : The 'Update Assessment Status' API allows users to update Ashby about the status of a started assessment. It requires the 'candidatesWrite' permission. The request body must include 'assessment_id' and 'timestamp'. Optional fields include 'assessment_status', 'assessment_profile_url', 'assessment_result', 'cancelled_reason', and 'metadata'. The response indicates the status of the update operation.

Candidate

POST https://api.ashbyhq.com/candidate.addTag : The Add Tag to Candidate API allows users to add a specific tag to a candidate's profile in the Ashby system. This API requires the `candidatesWrite` permission. The request must include the candidate's unique ID and the tag's unique ID in the request body. The response will indicate whether the operation was successful and provide detailed information about the candidate, including their contact information, social links, tags, and other relevant details. In case of an error, the response will include a list of error messages.
POST https://api.ashbyhq.com/candidate.create : The Create Candidate API endpoint allows users to create a new candidate in the system. It requires the `candidatesWrite` permission. The request must include the candidate's name, and can optionally include other details such as email, phone number, LinkedIn URL, GitHub URL, website, alternate email addresses, source ID, credited user ID, location, and creation timestamp. The response will indicate success and provide details about the created candidate, including their ID, name, contact information, social links, tags, position, company, school, application IDs, resume file handle, custom fields, profile URL, source, credited user, timezone, and primary location. In case of an error, the response will include error messages.
POST https://api.ashbyhq.com/candidate.createNote : The Create Note on Candidate API allows users to add a note to a candidate's profile. It requires the 'candidatesWrite' permission. The request body must include the candidate's unique identifier (candidateId) and the note content, which can be either a plain text string or an object specifying the content type and value. The API supports HTML elements like bold, italic, underline, links, lists, and code blocks for notes of type 'text/html'. Users can optionally specify whether to send notifications to subscribed users. The response includes a success flag and, if successful, details of the created note, including its ID, creation date, content, and author information. In case of errors, an error message is returned.
POST https://api.ashbyhq.com/candidate.info : The Candidate Information Retrieval API allows users to fetch detailed information about a candidate using either the candidate's unique ID or an external mapping ID. This API requires the 'candidatesRead' permission. The request body must include either the 'id' or 'externalMappingId' to identify the candidate. The response includes comprehensive details about the candidate, such as personal information, contact details, social links, tags, position, company, school, application IDs, resume file handle, custom fields, profile URL, source, credited user, timezone, and primary location. The response can either be a success with detailed candidate information or an error with a list of error messages.
POST https://api.ashbyhq.com/candidate.list : The List Candidates API endpoint allows users to retrieve a list of all candidates in an organization. It requires the 'candidatesRead' permission. The request is made via a POST method to the URL 'https://api.ashbyhq.com/candidate.list'. The request body can include parameters such as 'cursor' for pagination, 'syncToken' for data synchronization, and 'limit' to specify the number of items to return. The response includes a success flag, potential error messages, and detailed candidate information such as name, contact details, social links, tags, and more.
POST https://api.ashbyhq.com/candidate.listNotes : The List Candidate Notes API endpoint allows users to retrieve all notes associated with a specific candidate. It requires the 'candidatesRead' permission. The request must include the candidate's ID, and optionally a cursor, sync token, and limit for pagination. The response includes a success flag, and if successful, a list of notes with details such as note ID, creation date, content, and author information. If there are errors, an error message will be returned.
POST https://api.ashbyhq.com/candidate.search : The Candidate Search API allows users to search for candidates by email and/or name. It requires the 'candidatesRead' permission. The API is designed for use cases where a small set of candidates is needed, such as building a candidate autocomplete. The request body can include 'email' and 'name' as search parameters, which are combined with the 'AND' operator if both are provided. The response is limited to 100 results and includes detailed candidate information such as email addresses, phone numbers, social links, tags, and more. If the search criteria are invalid, an error response is returned.
POST https://api.ashbyhq.com/candidate.update : The Update Candidate API allows you to update an existing candidate's information in the system. It requires the `candidatesWrite` permission. The request body must include the `candidateId` as a required field, and can optionally include other fields such as `name`, `email`, `phoneNumber`, `linkedInUrl`, `githubUrl`, `websiteUrl`, `alternateEmail`, `socialLinks`, `sourceId`, `creditedToUserId`, `location`, `createdAt`, and `sendNotifications`. The response will indicate success or failure, and in the case of success, it will return the updated candidate details including `id`, `name`, `emailAddresses`, `phoneNumbers`, `socialLinks`, `tags`, `applicationIds`, `fileHandles`, `profileUrl`, and more.
POST https://api.ashbyhq.com/candidate.uploadFile : The Upload Candidate File API allows users to upload a file to attach to a candidate's profile in Ashby. This API requires the 'candidatesWrite' permission and the request must be made with 'multipart/form-data' content type. The request body must include the 'candidateId' and the 'file' to be uploaded. Upon successful upload, the API returns a detailed response containing the candidate's information, including their name, email addresses, phone numbers, social links, tags, position, company, school, application IDs, file handles, custom fields, profile URL, source, credited user, timezone, and primary location. In case of an error, the response will include a list of error messages.
POST https://api.ashbyhq.com/candidate.uploadResume : The candidate.uploadResume API allows users to upload a candidate's resume, parse it, and update their information in the system. This API requires the 'candidatesWrite' permission and the request must be sent with 'multipart/form-data' as the content type. The request body must include the 'candidateId' and the 'resume' file. The response will indicate success and provide detailed information about the candidate, including their contact information, social links, tags, position, company, school, application IDs, resume file handle, custom fields, profile URL, source, credited user, timezone, and primary location. If the request fails, an error response will be returned with a list of error messages.
POST https://api.ashbyhq.com/canidate.anonymize : The Anonymize Candidate API is used to anonymize a candidate's data. It requires the 'candidatesWrite' permission and all of the candidate's applications must be in the archived or hired state. The API takes a POST request with a JSON body containing the 'candidateId' as a UUID. The response can either be a success response with detailed candidate information or an error response with a list of error messages.

Candidate Tag

POST https://api.ashbyhq.com/candidateTag.create : The Create Candidate Tag API allows users to create a new tag for a candidate. It requires the 'hiringProcessMetadataWrite' permission. The request must include a JSON body with a 'title' field, which is the name of the tag. If a tag with the same title already exists, the existing tag will be returned. The response can either be a success response, which includes the tag details such as 'id', 'title', and 'isArchived', or an error response with a list of error messages.
POST https://api.ashbyhq.com/candidateTag.list : The List Candidate Tags API endpoint allows users to retrieve all candidate tags. It requires the 'hiringProcessMetadataRead' permission. The request is made via a POST method to the URL 'https://api.ashbyhq.com/candidateTag.list'. The request body can include an optional 'includeArchived' boolean parameter to specify whether archived tags should be included. The response will be a JSON object indicating success and containing an array of candidate tags, each with an 'id', 'title', and 'isArchived' status. In case of an error, the response will include a list of error messages.

Custom Field

POST https://api.ashbyhq.com/customField.create : The Create Custom Field API allows users to create a new custom field in the Ashby system. It requires the `hiringProcessMetadataWrite` permission. The request body must include the `fieldType`, `objectType`, and `title` as required fields. Optional fields include `description`, `selectableValues`, `isDateOnlyField`, and `isExposableToCandidate`. The response will indicate success and provide details of the created custom field, including its `id`, `title`, `objectType`, `isArchived`, and `fieldType`. In case of an error, the response will include a list of error messages.
POST https://api.ashbyhq.com/customField.list : The List Custom Fields API endpoint allows users to retrieve a list of all custom fields available in the Ashby system. It requires the 'hiringProcessMetadataRead' permission. The request is made via a POST method to the specified URL with headers indicating the content type as 'application/json'. The request body can include optional parameters such as 'cursor' for pagination, 'syncToken' for synchronization, and 'limit' to specify the number of items to return. The response can either be a success or an error. A successful response includes a list of custom fields with details such as 'id', 'title', 'objectType', 'isArchived', 'fieldType', and 'selectableValues' if applicable. An error response includes a list of error messages.
POST https://api.ashbyhq.com/customField.setValue : The 'Set Custom Field Value' API allows users to set the value of a custom field for a specified object. It requires the 'candidatesWrite' permission. The request body must include 'objectId', 'objectType', 'fieldId', and 'fieldValue'. The 'fieldValue' can be of various types depending on the field being updated, such as Boolean, Date, String, MultiValueSelect, Number, or ValueSelect. The response will indicate success and provide details of the updated field value, or it will return an error message if the input is invalid.

Department

POST https://api.ashbyhq.com/department.create : The Create Department API allows users to create a new department within an organization. It requires the 'organizationWrite' permission. The request must include the department's name and optionally the parent department's ID. The response will indicate success and provide details of the created department, including its ID, name, and archival status. In case of errors, an error message will be returned.
POST https://api.ashbyhq.com/department.info : The Fetch Department Details API allows users to retrieve details of a department by its unique ID. It requires the 'organizationRead' permission. The request must include the department ID in the request body. The response can either be a success response containing the department details such as ID, name, and archival status, or an error response with a list of error messages.
POST https://api.ashbyhq.com/department.list : The List Departments API endpoint allows users to retrieve a list of all departments within an organization. It requires the 'organizationRead' permission. The request is made via a POST method to the URL 'https://api.ashbyhq.com/department.list'. The request body can include an optional 'includeArchived' boolean parameter to specify whether archived departments should be included in the response. The response will return a success status and a list of department objects, each containing an 'id', 'name', 'isArchived' status, and optionally a 'parentId'. In case of an error, the response will include a list of error messages.

Feedback Form Definition

POST https://api.ashbyhq.com/feedbackFormDefinition.info : The Feedback Form Definition Information API returns a single feedback form by its unique ID. It requires the 'hiringProcessMetadataRead' permission. The request must include the 'feedbackFormDefinitionId' in the body as a UUID. The response can either be a success, containing details of the feedback form such as its ID, title, and form definition, or an error response with a list of error messages.
POST https://api.ashbyhq.com/feedbackFormDefinition.list : The List Feedback Form Definitions API endpoint allows users to retrieve a list of feedback forms. It requires the 'hiringProcessMetadataRead' permission. The request body can include parameters such as 'includeArchived' to include archived items, 'cursor' for pagination, 'syncToken' for synchronization, and 'limit' to specify the number of items to return. The response includes a success flag, a list of results with feedback form details, and pagination information. In case of errors, an error message is returned.

File

POST https://api.ashbyhq.com/file.info : The 'Retrieve File URL for Candidate' API endpoint allows users to retrieve the URL of a file associated with a candidate. This API requires the 'candidatesRead' permission. The request is made via a POST method to the URL 'https://api.ashbyhq.com/file.info'. The request body must include a 'fileHandle', which is a string representing a file handle retrieved from the public API. The response can either be a success, returning a JSON object with a 'success' boolean and a 'results' object containing the 'url' of the file, or an error, returning a 'success' boolean set to false and an 'errors' array with error message strings.

Hiring Team

POST https://api.ashbyhq.com/hiringTeam.addMember : The Add Member to Hiring Team API allows you to add an Ashby user to the hiring team at either the application or job level. It requires the 'organizationWrite' permission. The request body must include either an applicationId or jobId, along with the teamMemberId and roleId. The response will indicate success and provide details of the added team member, or it will return errors if the operation fails.
POST https://api.ashbyhq.com/hiringTeamRole.list : The List Hiring Team Roles API endpoint allows users to retrieve a list of possible hiring team roles within an organization. It requires the 'organizationRead' permission. The request is made via a POST method to the specified URL with headers indicating the expected response and request body media types as 'application/json'. The request body can include a 'namesOnly' boolean parameter, which defaults to true. If 'namesOnly' is true, the response will be an array of role titles. If false, the response will include an array of objects with each role's id and title. The response includes a 'success' boolean indicating if the request was successful and a 'results' array containing the role information.

Interview

POST https://api.ashbyhq.com/interview.info : The Fetch Interview Details by ID API allows users to retrieve detailed information about a specific interview using its unique ID. This API requires the 'interviewsRead' permission. The request must include the interview ID in the request body as a UUID. The response will include details such as the interview's title, whether it is archived, HTML and plaintext descriptions, associated job ID, and feedback form definition ID. If the request is successful, the response will include a 'success' flag and the interview details. In case of an error, the response will include a 'success' flag set to false and a list of error messages.
POST https://api.ashbyhq.com/interview.list : The 'List Interviews' API endpoint allows users to retrieve a list of interviews. It requires the 'interviewsRead' permission. The request is made via a POST method to the URL 'https://api.ashbyhq.com/interview.list'. The request body can include parameters such as 'cursor', 'syncToken', 'limit', 'includeArchived', and 'includeNonSharedInterviews'. The response can either be a success or an error. A successful response includes details about the interviews such as 'id', 'title', 'isArchived', 'instructionsHtml', 'instructionsPlain', 'jobId', and 'feedbackFormDefinitionId'. An error response includes a list of error messages.
POST https://api.ashbyhq.com/interviewEvent.list : The List Interview Events API allows users to retrieve a list of interview events associated with a specific interview schedule. It requires the 'interviewsRead' permission. The request must include the 'interviewScheduleId' in the body, which is a UUID identifying the interview schedule. The response will include a success flag and a list of interview events, each with details such as event ID, interview ID, schedule ID, interviewer IDs, creation time, start and end times, feedback link, location, meeting link, and feedback submission status. In case of errors, an error response with a list of error messages will be returned.
POST https://api.ashbyhq.com/interviewPlan.list : The List Interview Plans API endpoint allows users to retrieve a list of interview plans. It requires the 'interviewsRead' permission. The request is made via a POST method to the URL 'https://api.ashbyhq.com/interviewPlan.list'. The request body can include an optional parameter 'includeArchived' to specify whether archived items should be included in the response. The response can either be a success response containing a list of interview plans with details such as 'id', 'title', and 'isArchived', or an error response with a list of error messages.
POST https://api.ashbyhq.com/interviewSchedule.cancel : The Cancel Interview Schedule API allows users to cancel an interview schedule by its ID. It requires the 'interviewsWrite' permission. The request must include the ID of the interview schedule to be canceled and optionally whether the schedule can be rescheduled. The response will indicate success or failure, and in case of success, it will provide details about the interview schedule, including its status, associated application ID, interview stage ID, and any scheduled interview events. In case of an error, a list of error messages will be returned.
POST https://api.ashbyhq.com/interviewSchedule.create : The 'Create Scheduled Interview' API allows users to create a scheduled interview in Ashby. It requires the 'interviewsWrite' permission. The request body must include the 'applicationId' and 'interviewEvents', which detail the events that make up the interview schedule. Each event must specify 'startTime', 'endTime', and 'interviewers'. The response can either be a success, providing details of the created interview schedule, or an error with a list of error messages.
POST https://api.ashbyhq.com/interviewSchedule.list : The List Interview Schedules API retrieves all interview schedules within an organization. It requires the 'interviewsRead' permission. The request is made via a POST method to the endpoint 'https://api.ashbyhq.com/interviewSchedule.list'. The request body can include parameters such as 'createdAfter', 'cursor', 'syncToken', 'limit', 'applicationId', and 'interviewStageId'. The response includes a success flag, a list of interview schedules, and pagination details like 'moreDataAvailable', 'nextCursor', and 'syncToken'. Each interview schedule contains details such as 'id', 'status', 'applicationId', 'interviewStageId', and associated 'interviewEvents'.
POST https://api.ashbyhq.com/interviewSchedule.update : The Update Interview Schedule API allows users to update, add, or cancel interview events associated with an interview schedule. It requires the 'interviewsWrite' permission. To update an interview event, the 'interviewEventId' must be included in the request. The request body can either update an existing event or cancel an event. The response includes the status of the interview schedule and details of all associated interview events. The API returns a success response with the updated schedule details or an error response with a list of error messages.
POST https://api.ashbyhq.com/interviewStage.info : The Fetch Interview Stage Details API allows users to retrieve details of a specific interview stage by its unique ID. It requires the 'interviewsRead' permission. The request must include the 'interviewStageId' in the body as a UUID. The response can either be a success, containing details such as the stage ID, title, type, order in the interview plan, and interview plan ID, or an error response with a list of error messages.
POST https://api.ashbyhq.com/interviewStage.list : The List Interview Stages API endpoint allows users to list all interview stages for a specified interview plan in order. It requires the 'interviewsRead' permission. The request must include the 'interviewPlanId' in the body as a UUID. The response will indicate success and provide an array of interview stages, each with an id, title, type, order in the interview plan, and the interview plan id. If the request fails, an error response with a list of error messages will be returned.

Interviewer Pool

POST https://api.ashbyhq.com/interviewerPool.addUser : The 'Add User to Interviewer Pool' API allows you to add a user to a specified interviewer pool. It requires the 'hiringProcessMetadataWrite' permission. The request body must include the 'interviewerPoolId' and 'userId', both of which are UUIDs. Optionally, you can include 'interviewerPoolTrainingPathStageId'. The response will indicate success and provide details about the interviewer pool, including its ID, title, and training path information. In case of an error, the response will include a list of error messages.
POST https://api.ashbyhq.com/interviewerPool.archive : The Archive Interviewer Pool API archives an interviewer pool. It requires the 'hiringProcessMetadataWrite' permission. The request is made via a POST method to the endpoint 'https://api.ashbyhq.com/interviewerPool.archive'. The request body must include the 'interviewerPoolId', which is the ID of the interviewer pool to be archived. The response can either be a success or an error. A successful response includes details about the interviewer pool, such as its ID, title, archival status, training path, qualified members, and trainees. An error response includes a list of error messages.
POST https://api.ashbyhq.com/interviewerPool.create : The 'Create Interviewer Pool' API endpoint allows users to create a new interviewer pool. It requires the 'hiringProcessMetadataWrite' permission. The request must include a JSON body with the 'title' of the pool, which is required, and an optional 'requiresTraining' boolean to indicate if training is needed. The response will indicate success and provide details about the created pool, including its ID, title, archival status, training path, qualified members, and trainees. In case of an error, the response will include a list of error messages.
POST https://api.ashbyhq.com/interviewerPool.info : The Interviewer Pool Information API provides details about a specific interviewer pool. It requires the 'hiringProcessMetadataRead' permission. The request is made via a POST method to the endpoint 'https://api.ashbyhq.com/interviewerPool.info'. The request body must include the 'interviewerPoolId', which is a UUID identifying the pool. The response can be a success or an error. A successful response includes details such as the pool's ID, title, archival status, training path, qualified members, and trainees. An error response includes a list of error messages.
POST https://api.ashbyhq.com/interviewerPool.list : The List Interviewer Pools API endpoint allows users to retrieve a list of interviewer pools. It requires the 'hiringProcessMetadataRead' permission. The request is made via a POST method to the URL 'https://api.ashbyhq.com/interviewerPool.list'. The request body can include parameters such as 'cursor', 'syncToken', 'limit', 'includeArchivedPools', and 'includeArchivedTrainingStages'. The response includes a success flag, a list of results with details about each pool, and pagination information. In case of an error, the response will include an error message.
POST https://api.ashbyhq.com/interviewerPool.removeUser : The 'Remove User from Interviewer Pool' API allows you to remove a user from a specified interviewer pool. This API requires the 'hiringProcessMetadataWrite' permission. The request must include the 'interviewerPoolId' and 'userId' in the body, both of which are UUIDs. The response will indicate success or failure. On success, it returns details about the interviewer pool, including its ID, title, archival status, training path, qualified members, and trainees. On failure, it provides a list of error messages.
POST https://api.ashbyhq.com/interviewerPool.restore : The 'Restore Interviewer Pool' API endpoint allows users to restore an archived interviewer pool. It requires the 'hiringProcessMetadataWrite' permission. The request is made via a POST method to the specified URL with a JSON body containing the 'interviewerPoolId' of the pool to be restored. The response can either be a success, returning details of the restored pool including its ID, title, archival status, training path, qualified members, and trainees, or an error with a list of error messages.
POST https://api.ashbyhq.com/interviewerPool.update : The 'Update Interviewer Pool' API allows users to update details of an existing interviewer pool. It requires the 'hiringProcessMetadataWrite' permission. The request body must include the 'interviewerPoolId' as a required field, and optionally, the 'title' and 'requiresTraining' fields. The response can either be a success or an error. A successful response includes details of the updated interviewer pool, such as its ID, title, archival status, training path, qualified members, and trainees. An error response includes a list of error messages.

Job

POST https://api.ashbyhq.com/job.create : The 'Create a New Job' API endpoint allows users to create a new job posting in the system. It requires the 'jobsWrite' permission. The request must include a JSON body with the job title, team ID, and location ID as required fields. Optional fields include default interview plan ID and job template ID. The response will indicate success or failure, and if successful, it will return details of the created job, including its ID, title, status, and other attributes. In case of an error, the response will include a list of error messages.
POST https://api.ashbyhq.com/job.info : The Job Information Retrieval API allows users to fetch detailed information about a specific job using its unique ID. The request requires the 'jobsRead' permission and must include the job ID in the request body. Optionally, users can expand the response to include additional data related to the job's location and openings. The response includes detailed job information such as title, status, employment type, associated department, and custom fields. In case of an error, the response will include a list of error messages.
POST https://api.ashbyhq.com/job.list : The List Jobs API allows users to retrieve a list of jobs, including open, closed, and archived jobs. It requires the 'jobsRead' permission. The request body can include parameters such as 'cursor', 'syncToken', 'limit', 'status', 'openedAfter', 'openedBefore', 'closedAfter', 'closedBefore', and 'expand'. The response includes a success flag, a list of job results, and pagination information. Each job result contains details such as job ID, title, status, employment type, location, department, interview plans, custom fields, and hiring team information.
POST https://api.ashbyhq.com/job.search : The Job Search API allows users to search for jobs by title. It requires the 'jobsRead' permission. The request is made via a POST method to the endpoint 'https://api.ashbyhq.com/job.search'. The request body must include a 'title' field specifying the job title to search for. The response includes a success flag and a list of job results, each containing details such as job ID, title, status, employment type, location, department, interview plans, custom fields, job postings, requisition ID, hiring team, and timestamps for updates, openings, and closings. In case of errors, an error response with a list of error messages is returned.
POST https://api.ashbyhq.com/job.setStatus : The Set Job Status API allows users to change the status of a job by its unique ID. It requires the 'jobsWrite' permission. The job status can be set to 'Draft', 'Open', 'Closed', or 'Archived', with specific transitions allowed between these states. The request must include the job ID and the desired status in the body. The response will indicate success and provide detailed job information if successful, or error messages if not.
POST https://api.ashbyhq.com/job.update : The Update Job Details API allows users to update an existing job's details. It requires the 'jobsWrite' permission. The request must include the jobId in the body, and optionally, other fields such as title, teamId, locationId, defaultInterviewPlanId, and customRequisitionId. The response will indicate success and provide updated job details, including id, title, status, employmentType, and more. In case of errors, an error response with a list of error messages will be returned.

Job Posting

POST https://api.ashbyhq.com/jobPosting.info : The Retrieve Job Posting Information API allows users to retrieve detailed information about a specific job posting. It requires the 'jobsRead' permission. The request must include the 'jobPostingId' in the body, which is a UUID identifying the job posting. Optionally, the 'expand' parameter can be used to include additional data for related objects. The response includes detailed information about the job posting, such as its title, description, department, team, location, and linked data for search engine optimization. The API returns a success response with the job posting details or an error response with a list of error messages.
POST https://api.ashbyhq.com/jobPosting.list : The List Job Postings API endpoint allows users to retrieve all published job postings. It requires the 'jobsRead' permission. By default, it includes both listed and unlisted job postings. To only fetch publicly displayable job postings, set the 'listedOnly' parameter to true. The request body can filter results by location and department. The response includes details such as job ID, title, department, team, location, employment type, and more. It also provides a success status and handles errors with descriptive messages.
POST https://api.ashbyhq.com/jobPosting.update : The jobPosting.update API allows users to update an existing job posting. It requires the 'jobsWrite' permission. The request body must include the 'jobPostingId' to identify the job posting to update. Optionally, a new 'title' and 'description' can be provided. The description must be in HTML format and only certain HTML tags are supported. The response will indicate success and return the updated job posting details, or provide error messages if the update fails.

Location

POST https://api.ashbyhq.com/location.create : The Create Location or Location Hierarchy API allows users to create a new location or a hierarchy of locations. It requires the 'organizationWrite' permission. The request body must include the 'name' and 'type' of the location, and can optionally include the 'address', 'parentLocationId', and 'isRemote' status. The response will indicate success and provide details of the created location, or it will return error messages if the input is invalid.
POST https://api.ashbyhq.com/location.info : The Location Information Retrieval API allows users to get details for a single location by its ID. It requires the 'organizationRead' permission. The request must include a JSON body with the 'locationId' parameter, which is a UUID representing the location to fetch. The response can either be a success response containing the location details such as ID, name, archival status, address, and remote status, or an error response with a list of error messages.
POST https://api.ashbyhq.com/location.list : The List All Locations API endpoint allows users to retrieve a list of all locations, excluding regions. The request requires the 'organizationRead' permission. The request body can include an optional parameter 'includeArchived' to specify whether archived locations should be included in the response. The response will return a success status and a list of location objects, each containing details such as id, name, archival status, address, and remote status. In case of an error, the response will include a list of error messages.

Offer

POST https://api.ashbyhq.com/offer.create : The Create Offer API endpoint allows users to create a new offer in the system. It requires the `offersWrite` permission. The request must include the offer process ID, offer form ID, and the offer form details, which include field submissions. The field submissions can include various types of data such as Boolean, Currency, Date, Number, String, ValueSelect, and MultiValueSelect. The response will indicate success or failure and, if successful, will include details about the created offer, such as its ID, application ID, acceptance status, offer status, latest version details, and author information. In case of an error, the response will include a list of error messages.
POST https://api.ashbyhq.com/offer.info : The Offer Information Retrieval API allows users to fetch details about a specific offer using its unique ID. This API requires the 'offersRead' permission. The request is made via a POST method to the endpoint 'https://api.ashbyhq.com/offer.info'. The request body must include the 'offerId', which is a UUID representing the offer to be fetched. The response can either be a success or an error. A successful response includes details such as the offer's ID, application ID, acceptance status, offer status, latest version details, and author information. In case of an error, the response will include a list of error messages.
POST https://api.ashbyhq.com/offer.list : The offer.list API endpoint is used to retrieve a list of all offers with their latest version. It requires the 'offersRead' permission. The request is made via a POST method to the URL 'https://api.ashbyhq.com/offer.list'. The request body can include parameters such as 'cursor', 'syncToken', 'limit', and 'applicationId' to filter and paginate the results. The response includes a success flag, a list of offers with details such as acceptance status, offer status, latest version details, and author information. The response also indicates if more data is available for pagination and provides a new sync token for subsequent requests.
POST https://api.ashbyhq.com/offer.start : The offer.start endpoint creates and returns an offer version instance that can be filled out and submitted using the `offer.create` endpoint. It requires the `offersWrite` permission. To create a new offer version for a candidate with an in-progress offer process, call the `offer.start` endpoint and then call the `offer.create` endpoint to fill out the newly created offer version form. The request body requires the `offerProcessId`, which is the ID of the offer process to start. The response can either be a success response containing the offer version details or an error response with a list of error messages.

Opening

POST https://api.ashbyhq.com/opening.addJob : The Add Job to Opening API allows users to add a job to an existing opening. It requires the 'jobsWrite' permission. The request body must include 'openingId' and 'jobId', both of which are strings representing the IDs of the opening and the job to be added, respectively. The response will indicate success with a boolean and provide details about the opening, including its state, whether it is archived, and information about the latest version of the opening. In case of an error, the response will include a list of error messages.
POST https://api.ashbyhq.com/opening.create : The Create Opening API allows users to create a new job opening. It requires the 'jobsWrite' permission. The request body must include details such as the identifier, description, teamId, locationIds, jobIds, targetHireDate, targetStartDate, isBackfill, employmentType, and openingState. The response will indicate success and provide details of the created opening, including its ID, state, and associated metadata. In case of errors, an error response with a list of error messages will be returned.
POST https://api.ashbyhq.com/opening.info : The Retrieve Opening Information API allows users to retrieve detailed information about a specific job opening using its UUID. This API requires the 'jobsRead' permission. The request must include the 'openingId' in the body, which is the unique identifier of the opening. The response will include detailed information about the opening, such as its state, whether it is archived, and details about the latest version of the opening, including the hiring team, employment type, and other relevant details. In case of an error, the response will include a list of error messages.
POST https://api.ashbyhq.com/opening.list : The List Openings API endpoint allows users to retrieve a list of job openings. It requires the 'jobsRead' permission. The request is made via a POST method to the URL 'https://api.ashbyhq.com/opening.list'. The request body can include optional parameters 'cursor' and 'syncToken' to paginate through results and synchronize data. The response includes a success flag and a list of results, each containing details about the job opening such as its ID, state, and latest version information. In case of an error, the response will include a list of error messages.
POST https://api.ashbyhq.com/opening.removeJob : The Remove Job from Opening API allows users to remove a specific job from an opening. It requires the 'jobsWrite' permission. The request is made via a POST method to the endpoint 'https://api.ashbyhq.com/opening.removeJob'. The request body must include 'openingId' and 'jobId', both of which are required. The response can either be a success or an error. A successful response includes details about the opening, such as its state, whether it is archived, and information about the latest version of the opening. An error response includes a list of error messages.
POST https://api.ashbyhq.com/opening.search : The Opening Search API allows users to search for job openings by their identifier. It requires the 'jobsRead' permission. The request is made via a POST method to the endpoint 'https://api.ashbyhq.com/opening.search'. The request body must include a JSON object with the 'identifier' of the opening to search for. The response can either be a success or an error. A successful response includes a list of results with details about each opening, such as its ID, state, and latest version information. An error response includes a list of error messages.
POST https://api.ashbyhq.com/opening.setArchived : The 'Set Archived State of an Opening' API allows users to update the archived state of a specific job opening. It requires the 'jobsWrite' permission. The request is made via a POST method to the endpoint 'https://api.ashbyhq.com/opening.setArchived'. The request body must include 'openingId' (the ID of the opening) and 'archive' (a boolean indicating the desired archived state). The response will indicate success and provide details about the opening, including its ID, state, and latest version information. In case of errors, an error message will be returned.
POST https://api.ashbyhq.com/opening.setOpeningState : The Set Opening State API allows users to update the state of a job opening. It requires the 'jobsWrite' permission. The request is made via a POST method to the endpoint 'https://api.ashbyhq.com/opening.setOpeningState'. The request body must include 'openingId' (the ID of the opening to update), 'openingState' (the new state, which can be 'Draft', 'Approved', 'Open', or 'Closed'), and optionally 'closeReasonId' if the state is being set to 'Closed'. The response will indicate success and provide details of the updated opening, including its ID, state, and other metadata. In case of errors, an error response with a list of error messages will be returned.
POST https://api.ashbyhq.com/opening.update : The Update Opening API allows users to update an existing job opening. It requires the 'jobsWrite' permission. The request body can include parameters such as 'openingId', 'identifier', 'description', 'teamId', 'targetHireDate', 'targetStartDate', 'isBackfill', and 'employmentType'. The response will indicate success or failure and provide details about the updated opening, including its ID, state, and latest version information.

Referral

POST https://api.ashbyhq.com/referral.create : The Create Referral API endpoint allows users to create a new referral in the system. It requires the `candidatesWrite` permission. The request must include the referral form ID, the user ID of the person submitting the referral, and the field submissions. Optionally, a creation timestamp can be provided. The response will indicate success and provide details about the created referral, including its ID, creation and update timestamps, status, candidate information, interview stage, source, job details, credited user, and hiring team. In case of errors, an error response will be returned with a list of error messages.
POST https://api.ashbyhq.com/referralForm.info : The Referral Form Information API fetches the default referral form or creates one if it does not exist. It requires the 'hiringProcessMetadataRead' permission. The API is accessed via a POST request to the specified endpoint with an 'accept' header set to 'application/json'. The response can either be a success or an error. A successful response includes details about the referral form, such as its ID, title, and form definition. An error response includes a list of error messages.

Source

POST https://api.ashbyhq.com/source.list : The 'List All Sources' API endpoint allows users to retrieve a list of all sources. It requires the 'hiringProcessMetadataRead' permission. The request is made via a POST method to the URL 'https://api.ashbyhq.com/source.list'. The request body can include an optional 'includeArchived' boolean parameter to specify whether archived items should be included. The response will include a 'success' boolean indicating if the request was successful, and if successful, a 'results' array containing source objects with 'id', 'title', 'isArchived', and 'sourceType' details. If there are errors, an 'errors' array will be returned with error messages.

Survey Form Definition

POST https://api.ashbyhq.com/surveyFormDefinition.info : The Survey Form Definition Information API returns details about a single survey form definition by its ID. It requires the 'hiringProcessMetadataRead' permission. The request must include the 'surveyFormDefinitionId' in the body as a UUID. The response includes details such as the form's ID, title, archival status, form definition, and survey type. The API returns a success response with the form details or an error response with a list of error messages.
POST https://api.ashbyhq.com/surveyFormDefinition.list : The List Survey Form Definitions API endpoint allows users to retrieve a list of all survey form definitions. It requires the 'hiringProcessMetadataRead' permission. The request is made via a POST method to the specified URL with headers indicating the expected response and request body media types as 'application/json'. The request body can include optional parameters such as 'cursor' for pagination, 'syncToken' for synchronization, and 'limit' to specify the number of items to return. The response can either be a success or an error. A successful response includes a list of survey form definitions with details such as form ID, title, archived status, and form definition details. An error response includes a success flag set to false and a list of error messages.

Survey Request

POST https://api.ashbyhq.com/surveyRequest.create : The Create Survey Request API endpoint generates a survey request and returns a survey URL. This URL can be shared with a candidate to allow them to complete a survey. The request requires the `candidatesWrite` permission. The request body must include `candidateId`, `applicationId`, and `surveyFormDefinitionId`, all of which are UUIDs. The response will include a success flag and, if successful, details of the survey request including the survey URL. If unsuccessful, an error response with a list of error messages will be returned.

Survey Submission

POST https://api.ashbyhq.com/surveySubmission.list : The surveySubmission.list API endpoint allows users to list all survey submissions of a specified survey type. It requires the 'candidatesRead' permission. The request body must include the 'surveyType' parameter, which specifies the type of survey submissions to fetch. Optional parameters include 'cursor', 'syncToken', and 'limit', which control pagination and data synchronization. The response includes a success flag, pagination information, and an array of survey submission results, each containing details such as the submission ID, candidate ID, application ID, survey type, form definition, and submitted values. In case of errors, the response will include an error message.

User

POST https://api.ashbyhq.com/user.info : The Get Ashby User Information API allows you to retrieve information about a specific user in the Ashby system by their user ID. This API requires the 'organizationRead' permission. The request must include a JSON body with the 'userId' parameter, which is a UUID representing the user to be looked up. The response will either be a success response containing user details such as id, firstName, lastName, email, globalRole, isEnabled, and updatedAt, or an error response with a list of error messages.
POST https://api.ashbyhq.com/user.list : The List Users API endpoint allows you to retrieve a list of all Ashby users. It requires the 'organizationRead' permission. The request body can include parameters such as 'cursor' for pagination, 'syncToken' for synchronization, 'limit' to specify the number of items to return, and 'includeDeactivated' to include deactivated users in the response. The response includes user details such as 'id', 'firstName', 'lastName', 'email', 'globalRole', 'isEnabled', and 'updatedAt'. The 'globalRole' property specifies the user's access level in Ashby. The response can also indicate if more data is available for pagination.
POST https://api.ashbyhq.com/user.search : The User Search by Email API allows you to search for an Ashby user using their email address. It requires the 'organizationRead' permission. The request must include the email in the request body. The response will indicate success and provide user details such as id, firstName, lastName, email, globalRole, isEnabled, and updatedAt if successful. In case of an error, the response will include a list of error messages.

Webhook

POST https://api.ashbyhq.com/webhook.create : The Create Webhook Setting API allows users to create a webhook setting by specifying the type of webhook, the URL to which the webhook will send requests, and a secret token for signing the webhook request. The request requires the 'apiKeysWrite' scope for authentication. The request body must include 'webhookType', 'requestUrl', and 'secretToken' as required fields. The response will indicate success with a boolean and provide details of the created webhook setting, including its ID, enabled status, request URL, secret token, and webhook type. In case of errors, an error response will be returned with a list of error messages.
POST https://api.ashbyhq.com/webhook.delete : The Delete Webhook Setting API allows users to delete a specific webhook setting by providing the webhook ID. It requires the 'apiKeysWrite' permission. The request must include the 'webhookId' in the body as a UUID string. The response will indicate success with a boolean and return the deleted 'webhookId' if successful, or an array of error messages if there was an error.

‍

Ashby API Use Case Examples

Ashby API FAQs

General API Questions

What is the Ashby API?
The Ashby API is a RESTful interface that allows developers to programmatically interact with Ashby’s recruiting and ATS (Applicant Tracking System) data—such as jobs, candidates, interviews, offers, and more.
‍Who can use the Ashby API?
Organizations that use Ashby can enable API access for internal developers or partners to build integrations, automate workflows, sync HR data, or build reporting dashboards.‍
Where can I find the official Ashby API documentation?
You can find Ashby's full API documentation here: https://developers.ashbyhq.com

Authentication & Access

How is the Ashby API authenticated?
Ashby uses API keys for authentication. Each request must include the API key in the Authorization header as a Bearer token.
‍How can I generate an API key in Ashby?
Log in to your Ashby admin dashboard, navigate to Developer Settings, and generate a new API key. API keys should be securely stored as they provide access to sensitive recruiting data.‍
Can I restrict permissions on an API key?
Yes. You can scope API keys to specific types of data (e.g., read-only access to candidates or jobs), improving security and compliance.

Functionality & Endpoints

‍What data can I access with the Ashby API?
You can access and manage:
1. Job postings
2. Applications
3. Candidates
4. Interviews and scheduling data
5. Offers
6. Feedback and notes
7. Custom fields
8. Reports and analytics (in some plans)‍
Does Ashby support webhooks?
Yes. Ashby supports webhooks for key events such as:
1. Candidate created/updated
2. Application status changes
3. Offer updates
4. Interview scheduling changes‍
Does Ashby API support pagination?
Yes. Most list endpoints are paginated. You can use query parameters like limit and cursor to navigate large datasets.

‍Usage & Best Practices

‍Can I integrate Ashby with my HRIS or CRM using the API?
Absolutely. You can sync Ashby data with your HR systems (like BambooHR, Workday), CRMs (like Salesforce), or analytics tools using Ashby's API or third-party platforms like Knit.‍
Is there a sandbox or test environment?
Currently, Ashby doesn't provide a public sandbox. It’s recommended to create a test workspace or use demo data within your production environment (with restricted keys) for development and testing.‍
What rate limits apply to the Ashby API?
Ashby enforces rate limits per API key. While the limits are generous, if you expect high-volume syncs, contact Ashby support to discuss rate limit increases.

Troubleshooting & Support

‍My API request failed—how can I debug it?
Check the response code and message. Common issues include:‍
1. 401 Unauthorized: Missing or invalid API key‍
2. 403 Forbidden: Insufficient permissions‍
3. 429 Too Many Requests: Rate limit exceeded‍
4. 500 Internal Server Error: Ashby-side issue‍
How do I contact support for API-related issues?
You can reach out to Ashby support through the in-app chat or email. For technical API support, you may also reference the Ashby Developer Docs or ask for direct developer assistance.‍
Does Ashby offer SDKs or client libraries?
Not at the moment. Ashby provides a standard REST API and recommends using any HTTP client or tools like Postman, cURL, or libraries like Axios, requests, or Fetch.

Leveraging Knit For Ashby API Integration

For quick and seamless integration with Ashby API, Knit API offers a convenient solution. It's AI powered integration platform allows you to build any Ashby API Integration use case. By integrating with Knit just once, you can integrate with multiple other ATS, HRIS, Payroll and other systems. Knit takes care of all the authentication, authorization, and ongoing integration maintenance. This approach not only saves time but also ensures a smooth and reliable connection to Ashby API.

‍

To sign up for free, click here. To check the pricing, see our pricing page.

API Directory

Jul 22, 2026

Xero API Integration Guide & API Directory | Knit

Xero is a leading cloud-based accounting software platform tailored for small and medium-sized businesses. It offers an extensive suite of financial management tools, including invoicing, bank reconciliation, expense tracking, and financial reporting. These features simplify the financial management process, allowing businesses to efficiently handle their finances. Additionally, Xero provides payroll management tools to streamline employee payments, tax calculations, and ensure compliance with local payroll regulations. Its inventory management capabilities enable businesses to track stock levels and manage product sales effectively.

One of Xero's standout features is its integration capabilities, particularly through the Xero API. This allows seamless connectivity with a wide range of third-party applications, such as payment processors, CRM systems, and e-commerce platforms, enhancing the software's functionality. The user-friendly interface and real-time data access make it easy for users to manage their business finances from anywhere. Xero's versatility and comprehensive features make it an invaluable tool for businesses looking to streamline their financial operations and gain insights into their financial health.

Key highlights of Xero APIs

Authentication: Utilizes OAuth 2.0 for secure authentication, ensuring that only authorized applications can access user data. Xero Developer

Data Formats: Communicates using JSON, making it compatible with a wide range of programming languages and platforms. Xero Developer

Comprehensive Documentation: Provides detailed guides and references to assist developers in effectively utilizing the API. Xero Developer

SDKs and Libraries: Offers official SDKs for Java and Python, along with community-supported libraries, to streamline the development process. GitHub

‍

Xero API Endpoints

Payments

POST /Payments/{PaymentID} : Delete Payment
PUT /payments : Apply Payments to Invoices, Credit Notes, Prepayments, or Overpayments
GET https://api.xero.com/api.xro/2.0/Payments : Retrieve Payments for Invoices and Credit Notes
PUT https://api.xero.com/api.xro/2.0/Payments/{Guid}/History : Add Notes to a Batch Payment

Contacts

PUT https://api.example.com/contacts : Create Contact Records
POST https://api.xero.com/api.xro/2.0/Contacts : Create or Update Contacts
POST https://api.xero.com/api.xro/2.0/Contacts/{ContactID}/Attachments/{FileName} : Uploading an Attachment to a Contact in Xero
GET https://api.xero.com/api.xro/2.0/Contacts/{Guid}/History : Retrieving Contact History
GET https://api.xero.com/api.xro/2.0/contacts : GET Contacts

Accounts

GET https://api.xero.com/api.xro/2.0/Accounts : GET Accounts
POST https://api.xero.com/api.xro/2.0/Accounts/{AccountID} : Archive Accounts
PUT https://api.xero.com/api.xro/2.0/Accounts/{account_id}/Attachments/{file_name} : Uploading an Attachment to an Account in Xero

Bank Transactions

POST https://api.xero.com/api.xro/2.0/BankTransactions : Create or Update Bank Transactions
POST https://api.xero.com/api.xro/2.0/BankTransactions/{BankTransactionID} : Deleting Spend and Receive Money Transactions
GET https://api.xero.com/api.xro/2.0/BankTransactions/{Guid}/History : Retrieving History of Bank Transactions
POST https://api.xero.com/api.xro/2.0/BankTransactions/{bankTransactionID}/Attachments/{fileName} : Uploading an Attachment to a Bank Transaction

Bank Transfers

GET https://api.xero.com/api.xro/2.0/BankTransfers : GET BankTransfers
POST https://api.xero.com/api.xro/2.0/BankTransfers/{bank_transfer_id}/Attachments/{file_name} : Uploading an Attachment to a Bank Transfer

Batch Payments

POST https://api.xero.com/api.xro/2.0/BatchPayments : Update Batch Payment Status to DELETED

Branding Themes

GET https://api.xero.com/api.xro/2.0/BrandingThemes : Get Branding Themes
POST https://api.xero.com/api.xro/2.0/BrandingThemes/{BrandingThemeID}/PaymentServices : Apply Payment Service to Branding Theme

Contact Groups

POST https://api.xero.com/api.xro/2.0/ContactGroups : Create or Update Contact Groups
PUT https://api.xero.com/api.xro/2.0/ContactGroups/{ContactGroupID}/Contacts : PUT ContactGroups
DELETE https://api.xero.com/api.xro/2.0/ContactGroups/{ContactGroupID}/Contacts/{ContactID} : DELETE ContactGroups

Credit Notes

GET https://api.xero.com/api.xro/2.0/CreditNotes : GET Credit Notes
PUT https://api.xero.com/api.xro/2.0/CreditNotes/{CreditNoteID}/Allocations : Creating and Allocating CreditNotes
DELETE https://api.xero.com/api.xro/2.0/CreditNotes/{CreditNoteID}/Allocations/{AllocationID} : Delete CreditNotes Allocations
POST https://api.xero.com/api.xro/2.0/CreditNotes/{CreditNoteID}/Attachments/{FileName} : Uploading an Attachment to a Credit Note
PUT https://api.xero.com/api.xro/2.0/CreditNotes/{Guid}/History : Add Notes to a Credit Note

Currencies

GET https://api.xero.com/api.xro/2.0/Currencies : GET Currencies

Employees

PUT https://api.example.com/employees/{employeeId} : PUT Employees API
POST https://api.xero.com/api.xro/2.0/Employees : Create or Update Employee Records

Expense Claims

POST https://api.xero.com/api.xro/2.0/ExpenseClaims : Submit or Update Expense Claims
GET https://api.xero.com/api.xro/2.0/ExpenseClaims/{Guid}/History : Retrieving Expense Claim History

Invoice Reminders

GET https://api.xero.com/api.xro/2.0/InvoiceReminders/Settings : Check Invoice Reminders Settings

Invoices

POST https://api.xero.com/api.xro/2.0/Invoices : Create or Update Invoices
GET https://api.xero.com/api.xro/2.0/Invoices/{Guid}/History : Retrieve Invoice History
POST https://api.xero.com/api.xro/2.0/Invoices/{InvoiceID}/Attachments/{FileName} : Uploading an Attachment to an Invoice
POST https://api.xero.com/api.xro/2.0/Invoices/{InvoiceID}/Email : Email an Invoice via Xero API
GET https://api.xero.com/api.xro/2.0/Invoices/{InvoiceID}/OnlineInvoice : Retrieve Online Invoice URL

Items

GET https://api.xero.com/api.xro/2.0/Items : GET Items
GET https://api.xero.com/api.xro/2.0/Items/{Guid}/History : Retrieving Item History
DELETE https://api.xero.com/api.xro/2.0/Items/{ItemID} : Delete Items

Journals

GET https://api.xero.com/api.xro/2.0/Journals : GET Journals

Linked Transactions

POST https://api.xero.com/api.xro/2.0/LinkedTransactions : Create or Update Linked Transactions
DELETE https://api.xero.com/api.xro/2.0/LinkedTransactions/{LinkedTransactionID} : Delete Linked Transaction

Manual Journals

PUT https://api.example.com/manualjournals : Create New Manual Journals
POST https://api.xero.com/api.xro/2.0/ManualJournals : Create or Update Manual Journal
POST https://api.xero.com/api.xro/2.0/ManualJournals/{manualJournalID}/Attachments/{fileName} : Uploading an Attachment to a Manual Journal

Organisation

GET https://api.xero.com/api.xro/2.0/Organisation : Get Organisation Details
GET https://api.xero.com/api.xro/2.0/Organisation/Actions : GET Organisation Actions
GET https://api.xero.com/api.xro/2.0/Organisation/{OrganisationID}/CISSettings : Retrieve CIS Settings for an Organisation

Overpayments

GET https://api.xero.com/api.xro/2.0/Overpayments : GET Overpayments
PUT https://api.xero.com/api.xro/2.0/Overpayments/{Guid}/History : Add Notes to an Overpayment
PUT https://api.xero.com/api.xro/2.0/Overpayments/{OverpaymentID}/Allocations : Allocate Overpayment to Outstanding Invoices
DELETE https://api.xero.com/api.xro/2.0/Overpayments/{OverpaymentID}/Allocations/{AllocationID} : Deleting Overpayments Allocations

Payment Services

GET https://api.xero.com/api.xro/2.0/PaymentServices : Get Payment Services

Prepayments

GET https://api.xero.com/api.xro/2.0/Prepayments : Retrieve Prepayments
GET https://api.xero.com/api.xro/2.0/Prepayments/{Guid}/History : Retrieving Prepayment History
PUT https://api.xero.com/api.xro/2.0/Prepayments/{PrepaymentID}/Allocations : Allocate Prepayment to Outstanding Invoices
DELETE https://api.xero.com/api.xro/2.0/Prepayments/{PrepaymentID}/Allocations/{AllocationID} : Deleting Prepayments Allocations

Purchase Orders

GET https://api.xero.com/api.xro/2.0/PurchaseOrders : Retrieve Purchase Orders
GET https://api.xero.com/api.xro/2.0/PurchaseOrders/{Guid}/History : Retrieve Purchase Order History

Quotes

PUT https://api.example.com/quotes/{quoteId} : PUT Quotes API
GET https://api.xero.com/api.xro/2.0/Quotes : GET Quotes

Receipts

PUT https://api.xero.com/api.xro/2.0/Receipts : PUT Receipts
PUT https://api.xero.com/api.xro/2.0/Receipts/{Guid}/History : Add Notes to a Receipt
POST https://api.xero.com/api.xro/2.0/Receipts/{receipt_id}/Attachments/{file_name} : Uploading a Receipt Image

Repeating Invoices

POST https://api.xero.com/api.xro/2.0/RepeatingInvoices : Create or Delete Repeating Invoice Templates
GET https://api.xero.com/api.xro/2.0/RepeatingInvoices/{Guid}/History : Retrieving Repeating Invoice History

Reports

GET https://api.xero.com/api.xro/2.0/Reports : Get GST Report
GET https://api.xero.com/api.xro/2.0/Reports/AgedPayablesByContact : Aged Payables By Contact
GET https://api.xero.com/api.xro/2.0/Reports/AgedReceivablesByContact : Aged Receivables By Contact
GET https://api.xero.com/api.xro/2.0/Reports/BalanceSheet : Balance Sheet Report API
GET https://api.xero.com/api.xro/2.0/Reports/BankSummary : Bank Summary Report
GET https://api.xero.com/api.xro/2.0/Reports/BudgetSummary : Budget Summary
GET https://api.xero.com/api.xro/2.0/Reports/ExecutiveSummary : Get Executive Summary Report
GET https://api.xero.com/api.xro/2.0/Reports/ProfitAndLoss : Profit and Loss Report
GET https://api.xero.com/api.xro/2.0/Reports/TenNinetyNine : 1099 Report Retrieval
GET https://api.xero.com/api.xro/2.0/Reports/TrialBalance : Get Trial Balance Report

Tax Rates

POST https://api.xero.com/api.xro/2.0/TaxRates : Create or Update Tax Rate

Tracking Categories

PUT https://api.xero.com/api.xro/2.0/TrackingCategories : Create Tracking Categories and Options
POST https://api.xero.com/api.xro/2.0/TrackingCategories/{TrackingCategoryID} : Update Tracking Categories and Options

Users

GET https://api.xero.com/api.xro/2.0/Users : GET Users

Budgets

GET https://api.xero.com/api.xro/2.0/budgets : GET Budgets

Attachments

GET https://api.xero.com/api.xro/2.0/{Endpoint}/{Guid}/Attachments/ : GET Attachments
POST https://api.xero.com/api.xro/2.0/{Endpoint}/{Guid}/Attachments/{Filename} : Upload Attachments to Xero

Document History

GET https://api.xero.com/api.xro/2.0/{Endpoint}/{Guid}/history : Get Document History

Sample API

GET https://api.example.com/v1/resource : Sample API Documentation
POST https://api.example.com/v1/sample : Sample API

Xero API FAQs

How do I get started with the Xero API?
- Answer: To begin using the Xero API, follow these steps:some text
  - Sign up for a free Xero account.
  - Enable the Xero demo company.
  - Add your OAuth 2.0 application by logging into Xero and navigating to the developer portal.
- Source: Getting Started Guide — Xero Developer
What authentication method does the Xero API use?
- Answer: The Xero API utilizes OAuth 2.0 for authentication. You'll need to create an OAuth 2.0 app in the Xero developer portal to obtain the necessary credentials for API access.
- Source: Frequently Asked Questions — Xero Developer
Are there rate limits for the Xero API?
- Answer: Yes, Xero enforces rate limits to ensure fair usage:some text
  - Minute Limit: 60 calls per minute.
  - Daily Limit: 5,000 calls per day.
  - Concurrent Requests: A maximum of 5 concurrent requests.
- Source: Frequently Asked Questions — Xero Developer
Can I retrieve invoices using the Xero API?
- Answer: Yes, you can retrieve invoices by making a GET request to the /Invoices endpoint of the Accounting API. You can filter and sort invoices using various parameters to suit your needs.
- Source: Accounting API Overview — Xero Developer
Does the Xero API support webhooks?
- Answer: Yes, Xero supports webhooks, allowing your application to receive real-time notifications about specific events, such as changes to invoices or contacts.‍
- Source: Frequently Asked Questions — Xero Developer

Get Started with Xero API Integration

Create a Xero Account: If you don't have one, sign up for a Xero account.
Register Your Application: Access the Xero Developer Center to create a new application, which will provide you with a Client ID and Client Secret necessary for authentication. Xero Developer
Authenticate Using OAuth 2.0: Implement the OAuth 2.0 flow to obtain an access token, allowing your application to interact with the Xero API on behalf of users. Xero Developer
Utilize SDKs and Libraries: Leverage available SDKs and libraries to simplify API integration within your application. GitHub GitHub
Explore API Endpoints: Familiarize yourself with various API endpoints to perform operations such as creating invoices, managing contacts, and retrieving financial reports. Xero Developer

Additional Resources:

API Explorer: Xero offers an API Explorer to facilitate testing and understanding of API endpoints. Xero Developer
Developer Community: Engage with the Xero developer community for support, insights, and updates related to the API. Xero Developer

About Knit

For quick and seamless integration with Xero API, Knit API offers a convenient solution. It’s AI powered integration platform allows you to build any Xero API Integration use case. By integrating with Knit just once, you can integrate with multiple other CRMs, HRIS, Accounting, and other systems in one go with a unified approach. Knit takes care of all the authentication, authorization, and ongoing integration maintenance. This approach not only saves time but also ensures a smooth and reliable connection to Xero API.‍

To sign up for free, click here. To check the pricing, see our pricing page.