> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kombo.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Passthrough API

> Implement any edge case feature with our passthrough API.

## Overview

The Passthrough API lets you call the native API of any connected integration directly, while Kombo handles authentication for you. This bridges the gap between the unified API and integration-specific requirements — you get the consistency of Kombo's auth layer with the flexibility of the underlying tool's full API surface.

## When to Use It

Use the Passthrough API when you need integration-specific data or actions that the unified API does not cover. Common examples:

* Reading provider-specific resources (e.g., HiBob work history, Workday compensation plans)
* Calling write endpoints that Kombo doesn't offer as a unified action
* Accessing tool-specific configuration (e.g., ATS picklists, custom templates)

<Tip>
  For reading additional fields on standard models, prefer [custom
  fields](./custom-fields) — they're simpler and work across integrations.
  [Integration fields](./integration-fields) cover a narrow niche and are rarely
  the right choice. The Passthrough API is best for accessing entirely different
  endpoints or performing writes that aren't part of the unified API.
</Tip>

## How It Works

1. **Authentication**: Authenticate with your Kombo API key as usual. Kombo forwards the request with the correct tool-specific credentials.
2. **Choose the API**: Find the API identifier for your integration in the [passthrough endpoint reference](../v1/post-passthrough-tool-api).
3. **Build your request**: Specify the HTTP method, endpoint path, headers, query parameters, and request body — exactly as the tool's native API expects.

## The `api_options` Parameter

Most integrations don't require `api_options` — simply set the `path` and Kombo routes to the right API.

However, some integrations have multiple underlying APIs or services that share the same authentication but use different base URLs or protocols. For these, `api_options` tells Kombo which specific service to target.

Integrations that use `api_options` document the required fields directly on their passthrough endpoint specification. Common examples:

* **Workday REST**: requires `service_name` (e.g., `"staffing"`, `"compensation"`) and optionally `version` to select the correct REST service
* **Workday SOAP**: requires `service_name` (e.g., `"Staffing"`, `"Recruiting"`) and optionally `service_version` to target the right SOAP service
* **SOAP-based tools** (Nmbrs, HR Office, Taleo): require `service_name` or `operation_name` to route to the correct SOAP service

If an integration doesn't document `api_options`, you don't need to provide it.

## Testing with Komboman

Use [Komboman](./komboman), the built-in API client in the Kombo dashboard, to test passthrough calls interactively. It handles authentication automatically and saves request history, making it easy to experiment with native API endpoints.

Find the full passthrough endpoint specification [here](../v1/post-passthrough-tool-api).