canonical: https://jentic.com/apis/tryfinch.com/tryfinch

# Tryfinch Finch Employment Data API

Unified API for employment systems providing access to company data, employee directories, payroll, deductions, and benefits across multiple HR/payroll providers. The API exposes 35 endpoints secured with basic, bearer authentication.

## For AI agents

Programmatically create a new connect session, reauthenticate an existing connection. Covers 35 operations with basic, bearer authentication.

## Scope

Does not handle payments, communications, or crm - use for hr and recruiting only.

## Capabilities

- Create a new connect session
- Reauthenticate an existing connection
- Exchange authorization code for access token
- Disconnect access tokens
- Get account info for access token
- List all available providers
- Make direct requests to employment system

## Use cases

### HR and Recruiting Operations

Use the Finch Employment Data API to perform hr recruiting operations programmatically. The API provides 35 endpoints covering core functionality including create a new connect session, reauthenticate an existing connection, exchange authorization code for access token.

Example prompt: Call POST /connect/sessions to create a new connect session

### Automated Connect Management

Automate connect operations by combining multiple Finch Employment Data API endpoints. Agents can reauthenticate an existing connection and then exchange authorization code for access token in a single workflow.

Example prompt: Call POST /connect/sessions/reauthenticate to reauthenticate an existing connection, then verify the result

### AI Agent Integration via Jentic

AI agents discover and call Finch Employment Data API endpoints through Jentic without managing credentials directly. An agent searches for the required operation by intent, receives the matching endpoint schema, and executes the call with Jentic-managed authentication. This eliminates the need to read API documentation or handle basic, bearer tokens manually.

Example prompt: Search Jentic for 'create a new connect session', load the operation schema, and execute with Jentic-managed credentials

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | /connect/sessions | Create a new connect session |
| POST | /connect/sessions/reauthenticate | Reauthenticate an existing connection |
| POST | /auth/token | Exchange authorization code for access token |
| POST | /disconnect | Disconnect access tokens |
| GET | /introspect | Get account info for access token |
| GET | /providers | List all available providers |
| POST | /forward | Make direct requests to employment system |
| GET | /employer/company | Read basic company data |

## Key resources

- **Connect** — Operations related to Connect
- **Deductions** — Operations related to Deductions
- **Documents** — Operations related to Documents
- **Management** — Operations related to Management
- **Organization** — Operations related to Organization

## Why Jentic

- **Setup:** Wiring Finch Employment Data API by hand means supporting both its basic and bearer auth, running its connect session and token exchange flow, and handling errors and retries yourself. Through Jentic you install once, import Finch Employment Data API from the API Directory, store the credentials once, and your agent calls it.
- **Permission scoping:** Finch Employment Data API drives connect sessions, token exchange, and forwarding through flat paths that take their input in the request body, so scoping is operations-only: you limit the agent to the operations it needs, such as creating a connect session or reading company data, and leave out anything else. Every operation the agent can run is one you put in that allowed set.
- **Credential handling:** Your Finch Employment Data API credentials are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create a connect session' or 'read employer company data', and Jentic returns the matching Finch Employment Data API operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Greenhouse** — Alternative hr recruiting API
- **Lever** — Alternative hr recruiting API
- **Workday** — Complementary hr recruiting API

## FAQ

### What authentication does the Finch Employment Data API use?

The Finch Employment Data API uses basic, bearer authentication. Through Jentic, these credentials are stored encrypted in your Jentic One instance and injected at execution time, so raw secrets never enter the agent context.

### Can I create a new connect session with the Finch Employment Data API?

Yes. Use the POST /connect/sessions endpoint. The API returns structured JSON responses that agents can parse and act on directly.

### What are the rate limits for the Finch Employment Data API?

Rate limits are not specified in the OpenAPI spec. Check the vendor documentation for current limits. Through Jentic, rate limiting is handled automatically with retry logic built into the execution layer.

### How do I create a new connect session through Jentic?

Install the Jentic SDK with pip install jentic, authenticate through Jentic One, the self-hosted execution layer, then search for 'create a new connect session'. Jentic returns the matching Finch Employment Data API operation with its input schema. Load the schema and execute the call - credentials are injected automatically.

### How many endpoints does the Finch Employment Data API have?

The Finch Employment Data API exposes 35 endpoints covering connect, deductions, documents operations.

### Can I limit what my agent is allowed to do with the Finch Employment Data API?

Yes. Because you run Jentic One yourself, your own rules decide which Finch Employment Data API operations and credentials the agent may use. Since the API drives its connect sessions, token exchange, and forwarding through flat paths that take input in the request body, scoping is operations-only: you allow just the operations the agent needs, such as creating a connect session or reading employer company data, and leave out everything else. Every operation the agent can run is one you put in that allowed set, so it cannot call anything you have not permitted.
