Recipes

Deprecated: use GET /api/v3.1/automated-recipe-templates/. This version stays available until it is switched off; see Moving recipes to v3.1.

When the recipes service fails, this version answers 500 with an HTML page, and an error in the 4xx range can arrive with a body that is not JSON. It also repeats the request to the recipes service up to three times, create included, so a create can run twice. v3.1 does neither: every error is {code, message, details}, and a request is repeated only when it provably never reached the service.

Returns a paginated list of available automated recipe templates that can be used to create automated recipes.

Deprecated: use GET /api/v3.1/automated-recipe-templates/{template_id}/. This version stays available until it is switched off; see Moving recipes to v3.1.

When the recipes service fails, this version answers 500 with an HTML page, and an error in the 4xx range can arrive with a body that is not JSON. It also repeats the request to the recipes service up to three times, create included, so a create can run twice. v3.1 does neither: every error is {code, message, details}, and a request is repeated only when it provably never reached the service.

Returns detailed information about a specific automated recipe template, including its tree structure and dependencies.

Deprecated: use GET /api/v3.1/automated-recipes/. This version stays available until it is switched off; see Moving recipes to v3.1.

When the recipes service fails, this version answers 500 with an HTML page, and an error in the 4xx range can arrive with a body that is not JSON. It also repeats the request to the recipes service up to three times, create included, so a create can run twice. v3.1 does neither: every error is {code, message, details}, and a request is repeated only when it provably never reached the service.

Returns a paginated list of automated recipes in the workspace.

Deprecated: use POST /api/v3.1/automated-recipes/. This version stays available until it is switched off; see Moving recipes to v3.1.

When the recipes service fails, this version answers 500 with an HTML page, and an error in the 4xx range can arrive with a body that is not JSON. It also repeats the request to the recipes service up to three times, create included, so a create can run twice. v3.1 does neither: every error is {code, message, details}, and a request is repeated only when it provably never reached the service.

Creates an automated recipe from a template. The recipe is created empty - no data sources, no connections, no accounts - so the next call must be PUT /api/v3/automated-recipes/{recipe_id}/.

Only one recipe per template per workspace. A second create from the same template returns 400 with existing_recipe_ids; treat that as "already deployed" and reuse one of the returned recipes.

The output table name is derived from the template's title, not from title in this body. title names the recipe in the UI and has no effect on the table. Two deployments of the same template with different titles produce the same table name. Uniqueness of that name is scoped to (agency, workspace), so the same name repeating across workspaces is expected and correct - do not try to make table names unique across your fleet. To learn the physical name, take datatable_id from this response and call GET /api/v3/data-tables/{data_table_id}, then read sql_name.

Deprecated: use GET /api/v3.1/automated-recipes/{recipe_id}/. This version stays available until it is switched off; see Moving recipes to v3.1.

When the recipes service fails, this version answers 500 with an HTML page, and an error in the 4xx range can arrive with a body that is not JSON. It also repeats the request to the recipes service up to three times, create included, so a create can run twice. v3.1 does neither: every error is {code, message, details}, and a request is repeated only when it provably never reached the service.

Returns detailed information about a specific automated recipe, including its configuration and connections.

Deprecated: use PUT /api/v3.1/automated-recipes/{recipe_id}/. This version stays available until it is switched off; see Moving recipes to v3.1.

When the recipes service fails, this version answers 500 with an HTML page, and an error in the 4xx range can arrive with a body that is not JSON. It also repeats the request to the recipes service up to three times, create included, so a create can run twice. v3.1 does neither: every error is {code, message, details}, and a request is repeated only when it provably never reached the service.

Supplies the configuration of an automated recipe: data sources, connections and accounts. A recipe created by POST is empty, so this call is a required step of every deployment, not an optional edit.

The payload is the complete configuration, and it is append-only. Send every data source, every connection and every account the recipe should have, including the ones it already has. Sending a delta fails: removing a data source, a connection or an account that is already configured returns 400 and nothing is saved. There is no way to remove an account, a connection or a data source from a recipe through this call. If the set has to shrink, delete the recipe with DELETE /api/v3/automated-recipes/{recipe_id}/ and deploy it again from the same template.

Returns 200 with an empty body. Read the recipe back with GET /api/v3/automated-recipes/{recipe_id}/ to confirm what was stored.

Deprecated: use DELETE /api/v3.1/automated-recipes/{recipe_id}/. This version stays available until it is switched off; see Moving recipes to v3.1.

When the recipes service fails, this version answers 500 with an HTML page, and an error in the 4xx range can arrive with a body that is not JSON. It also repeats the request to the recipes service up to three times, create included, so a create can run twice. v3.1 does neither: every error is {code, message, details}, and a request is repeated only when it provably never reached the service.

Permanently deletes an automated recipe. This is a hard delete and it cannot be undone: the SQL views the recipe produced are dropped, its cells and configuration are removed, the data tables it created in the workspace are cleaned up, and the intermediate recipes it was built on are deleted with it.

The cascade follows the recipes this one reads from, not the ones that read it: a recipe built on top of this one is left in place and will break, and an intermediate recipe that another deployed recipe also reads is deleted just the same.

Deleting frees the template slot. One recipe per template per workspace is enforced on create, so after a delete the same template can be deployed again - which is how a failed deployment is retired, and how a recipe whose account set has to shrink is replaced, since configuration is append-only.

Returns 204 with an empty body. The 204 says the deletion was attempted, not that every recipe in the tree went away: they are deleted one by one and a per-recipe failure is logged rather than reported here. Before deploying the same template again, confirm with GET /api/v3/automated-recipes/?template_id= that nothing is left.

Deprecated: use POST /api/v3.1/automated-recipes/{recipe_id}/build/. This version stays available until it is switched off; see Moving recipes to v3.1.

When the recipes service fails, this version answers 500 with an HTML page, and an error in the 4xx range can arrive with a body that is not JSON. It also repeats the request to the recipes service up to three times, create included, so a create can run twice. v3.1 does neither: every error is {code, message, details}, and a request is repeated only when it provably never reached the service.

Triggers the build process for an automated recipe. The recipe will transition through states (Extracting Data -> Building Dependencies -> Ready to work or Failed).

A 200 confirms that the build was started, not that it will succeed. The output table name is checked again for every table the recipe creates, immediately before each one is created, so a name that was free at start can be taken by the time the build reaches it. Such a failure arrives asynchronously: the recipe moves to Failed and the reason is in the error field of GET /api/v3/automated-recipes/{recipe_id}/.

The build waits for the extractions of the recipe and turns Ready to work on the ones that delivered. An extraction counts as delivered once one of its runs has completed, while the historical backfill may still be loading. Extractions that cannot deliver on their own - paused, or reused by a rebuild with nothing running - are not waited for, and the others only up to a limit; the ones left out can be missing from the output. A build with nothing to build from - no extraction delivered, or none for one extract template - fails.

Deprecated: use GET /api/v3.1/automated-recipes/{recipe_id}/extractions/. This version stays available until it is switched off; see Moving recipes to v3.1.

When the recipes service fails, this version answers 500 with an HTML page, and an error in the 4xx range can arrive with a body that is not JSON. It also repeats the request to the recipes service up to three times, create included, so a create can run twice. v3.1 does neither: every error is {code, message, details}, and a request is repeated only when it provably never reached the service.

Reports the extraction tables the recipe reads and whether each one already exists in the workspace destination. Use it to decide when a build that failed for missing data is worth repeating: once every table_exists is true, the build can be started again.

The tables come from the cells of the recipe and of the intermediate recipes it is built on, narrowed to the selected data sources. The extraction ids are the ones the last build used - created or reused - so they are empty before the first build. Nothing here is cached - every call queries the destination once.

ready is true when every listed table exists. A recipe whose cells reference no extraction tables answers with ready: false and an empty sources list. A table exists once the first account's rows land in it, so ready does not mean that every account has delivered, and it can be true while the recipe is still Extracting Data; the recipe state is the readiness signal.

Deprecated: use POST /api/v3.1/automated-recipes/{recipe_id}/resetup/. This version stays available until it is switched off; see Moving recipes to v3.1.

When the recipes service fails, this version answers 500 with an HTML page, and an error in the 4xx range can arrive with a body that is not JSON. It also repeats the request to the recipes service up to three times, create included, so a create can run twice. v3.1 does neither: every error is {code, message, details}, and a request is repeated only when it provably never reached the service.

Rebuilds the recipe from the template it was created from, and starts the build. Every recipe in the dependency tree is snapshotted first, then their cells are dropped and recreated from the current template.

This is how a fix made to a template reaches the recipes already deployed from it. The existing configuration - data sources, connections, accounts, sync_from_date - is preserved, and unlike a configuration PUT the build does not have to be triggered separately afterwards.

Takes no request body. A 200 means the reset was accepted and the build was started, not that the build will succeed - as with POST /build/, a failure arrives asynchronously in the error field of the recipe detail.