Linking Ashby as a source
Let AI connect your sources for you
Skip the manual setup — run this in your project and the wizard auto-detects your databases and APIs and connects them to PostHog.
Contents
This source is currently in alpha. The interface and available tables may change.
The Ashby connector syncs your applicant tracking system (ATS) data – candidates, applications, jobs, offers, interviews, and users – into PostHog, so you can analyze your recruiting funnel alongside your product data.
Prerequisites
You need an Ashby account with admin access so you can create an API key. The key needs read permissions for the data you want to sync.
Adding a data source
- In PostHog, go to the Sources tab of the data pipeline section.
- Click + New source and click Link next to this source.
- Enter your credentials (see Configuration below) and click Next.
- Select the tables you want to sync, choose a sync method and frequency, then click Import.
Once the syncs are complete, you can start querying this data in PostHog.
When linking Ashby, you'll need:
- API key – create one under Admin → API Keys in Ashby. Grant read permissions for the data you want to sync, for example
candidatesRead,applicationsRead,jobsRead,offersRead,interviewsRead, andusersRead.
Sync modes
Each table can be synced in one of several modes, depending on what the source supports:
- Webhook (when available) – the source pushes changes to PostHog in real time. Fastest freshness, lowest ongoing cost, and the only mode that reliably captures updates and deletes.
- Incremental – only new or updated rows are synced on each run, using a cursor field (such as an
updated_attimestamp). Cheaper than a full refresh, but deletes aren't captured. - Append only – new rows are appended using a cursor field; existing rows are never updated. Ideal for immutable, append-only tables like event logs.
- Full refresh – the whole table is reloaded on every sync. Use it when a table has no reliable cursor or when you need deletions reflected.
See sync methods for a full explanation of how each mode works and how to choose between them.
Configuration
| Option | Type | Required |
|---|---|---|
API key | password | Yes |
Supported tables
| Table | Description | Sync method | Incremental field | Primary key |
|---|---|---|---|---|
candidates | A person who has applied to or been sourced for a role in Ashby. | Full refresh | — | — |
applications | A candidate's application to a specific job in Ashby. | Full refresh | — | — |
jobs | A job (requisition) being recruited for in Ashby. | Full refresh | — | — |
job_postings | A published, externally visible posting for a job in Ashby. | Full refresh | — | — |
offers | An offer extended to a candidate for a job in Ashby. | Full refresh | — | — |
interviews | An interview type or definition configured in Ashby. | Full refresh | — | — |
interview_schedules | A scheduled set of interviews for a candidate's application in Ashby. | Full refresh | — | — |
users | A user (recruiter, hiring manager, or admin) in the Ashby workspace. | Full refresh | — | — |
departments | A department that jobs and teams are organized under in Ashby. | Full refresh | — | — |
locations | A location that jobs can be based in within Ashby. | Full refresh | — | — |
sources | A source channel through which candidates are added in Ashby. | Full refresh | — | — |
archive_reasons | A reason an application can be archived in Ashby. | Full refresh | — | — |
candidate_tags | A tag that can be applied to candidates in Ashby. | Full refresh | — | — |
custom_fields | A custom field definition used to capture additional data on Ashby objects. | Full refresh | — | — |
openings | An opening (headcount slot) tied to one or more jobs in Ashby. | Full refresh | — | — |
projects | A project used to organize sourcing and recruiting work in Ashby. | Full refresh | — | — |
referrals | A referral of a candidate for a job in Ashby. | Full refresh | — | — |
sequences | A candidate's enrollment in an outreach sequence in Ashby. | Full refresh | — | — |
application_feedback | An interview scorecard submitted against an application in Ashby. | Full refresh | — | — |
application_history | One stage an application passed through, with when it entered and left. The rows for an application reconstruct its funnel. | Full refresh | — | — |
interview_stages | A stage in an Ashby interview plan. Resolves the stage IDs carried on applications and interview schedules. | Full refresh | — | — |
interview_events | A scheduled occurrence of an interview, with its interviewers and times. | Full refresh | — | — |
Troubleshooting
If your sync is failing or data looks wrong, see the Data warehouse troubleshooting guide. If that doesn't help, contact support – we're happy to help.