Ashby to Snowflake: How to Move Your Data

Moving Ashby into Snowflake lets you analyse hiring the way you analyse everything else. Ashby reports capably on a pipeline and cannot tell you whether a recruiting channel produces people who stay, because that answer lives in systems it has never seen.

This guide covers the managed path with Airbyte. Two things shape the build: two different causes make a stream come back empty without complaining, and this is candidate data, which is among the most sensitive material a company holds.

Ashby to Snowflake at a glance:

Why move data from Ashby to Snowflake?

Two situations account for most of these pipelines.

The first is measuring recruiting against outcomes rather than activity. Time to hire and offer acceptance are available inside Ashby; whether a source produces people who are still here in two years is a question needing your HR system, and only a warehouse holds both.

The second is governance and reporting obligations, where a queryable record of hiring activity matters. Snowflake is a good choice here specifically because of its access controls, since this dataset has an unusually narrow legitimate audience and an unusually broad potential one.

What do you need before you start?

Four things, and the first has a minimum that is easy to miss:

An API key with per-module read permissions. Organization read is required for the connection check itself, plus read on each module whose streams you want. The Ashby source documentation lists which module each stream needs.

A start date, knowing what it bounds. Supplied in the usual timestamp format, and it limits replication for the applications and interview schedules streams rather than for everything you select.

Snowflake objects and a genuinely narrow grant. A warehouse, database, schema and a role that can create tables. Give this its own schema, because interview feedback should not sit where general analysts browse.

Agreement from somebody accountable for people data. Warehousing candidate records is a decision your people or legal team should make deliberately rather than discover, and retention obligations for unsuccessful applicants are specific.

If your Snowflake account restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the network policy before you begin.

How do you build an Ashby to Snowflake pipeline in Airbyte?

Step 1: Grant Organization read plus the modules you actually need

Organization read is the minimum, because the connection check itself depends on it, and a key without it fails before you get to any stream. Then grant read on each module your chosen streams draw from, matching the list rather than granting broadly. Recruitment data rewards least privilege more than most, and a key scoped to what you analyse is easier to justify than one scoped to everything.

Step 2: Configure the Ashby source

Click Sources in the left navigation, then New Source, and select Ashby, following adding a source. Supply the API key and a start date. The connector reads streams concurrently with a small default number of workers and budgets against a limit of a thousand requests per minute per key, so there is little tuning to do.

Step 3: Configure the Snowflake destination

Click Destinations, then New Destination, and select Snowflake, following adding a destination. Supply the account identifier, warehouse, database, schema and role. Candidate and application records carry nested structures for custom fields and feedback, and Snowflake holds those natively.

Step 4: Create the connection and apply controls first

Click Connections, then New connection, select your streams and a sync mode. Daily is ample for hiring data. Then apply masking and access policies before anybody is told the schema exists, which matters more here than on almost any other source in the catalogue.

Then check your stream row counts against expectations, because two different things make a stream arrive empty.

Why might a stream come back empty?

For two unrelated reasons, which is worth knowing because they look identical from the warehouse. The first is permissions: a key lacking read on the relevant module produces no data for the streams that module serves, and only Organization read is mandatory enough to stop the connection check.

The second is a feature gate. The stream carrying AI-generated criteria evaluations depends on the AI Application Review feature being enabled for your organisation, and where it is not, the stream returns empty results rather than an error. That is a subscription question rather than a configuration one, and no amount of checking your key will reveal it.

The start date is the third thing that makes a stream look smaller than expected, and it behaves selectively: it bounds replication for the applications and interview schedules streams rather than across the board. So a stream with fewer rows than you anticipated has three candidate explanations, and checking permissions, features and the start date in that order resolves most of them quickly.

Who should be able to read candidate records?

Very few people, and fewer than will have schema access by default. This dataset describes named individuals who applied for jobs, most of whom were not hired, together with interview feedback written by colleagues who assumed a small audience. It is among the most sensitive material any company holds and it arrives in ordinary columns.

Masking policies are the right tool because the useful analysis rarely needs identities. Time to hire, offer acceptance rates, source effectiveness and pipeline conversion are all counts and durations, and an analyst can produce every one of them without reading a name or a feedback comment. Row access policies handle the other dimension where hiring is devolved to regional teams.

Retention deserves explicit attention, more than for most sources. Candidate records, particularly for unsuccessful applicants, are usually subject to a defined retention period in your jurisdiction, and a warehouse keeps things indefinitely unless somebody decides otherwise. Agree the period, implement it, and remember that your copy is now a second place where an erasure request has to be honoured.

Frequently asked questions

The connection check fails. What is missing?

Most likely Organization read, which is required for the check itself regardless of which streams you intend to sync.

Why is the AI evaluations stream empty?

It requires the AI Application Review feature to be enabled for your organisation. Without it the stream returns empty results rather than raising an error.

Does the start date limit every stream?

No. It bounds replication for the applications and interview schedules streams, so other streams are not affected by it.

Do I need to worry about rate limits?

Rarely. Ashby allows a thousand requests per minute per key and the connector budgets against that while reading streams concurrently with a small number of workers.

Can I do this without writing code?

The pipeline, yes. Masking and access policies are SQL, and with candidate data they are the part that makes the whole exercise defensible.

Get your Ashby data into Snowflake

Grant Organization read plus the specific modules your streams need, and expect three separate explanations for a stream that looks short: permissions, a feature gate on the AI evaluations stream, and a start date that bounds only applications and interview schedules. Then treat this as the sensitive dataset it is, mask identities and feedback, agree a retention period for unsuccessful candidates, and apply all of it before the schema is handed out.

Airbyte's connector catalog includes 600+ pre-built connectors, so hiring can be measured against the outcomes it produced. For conversation data with similar sensitivity into the same destination, see Gong to Snowflake, and for workforce identity into the same destination, Okta to Snowflake.

Start syncing now →