Skip to main content

Introduction

Honeydew enables deep integration in Snowflake with a snowflake native application. It can be installed from the Snowflake Marketplace Listing. When the native app is installed, Honeydew API can be accessed directly from a Snowflake connection or the web interface, to do things such as:
  • Query data based on a semantic query
  • Generate Snowflake SQL query from a semantic query
  • Consume any metadata such as field names and descriptions
  • Update the semantic layer definitions

Installation

1

Honeydew account

Honeydew native application requires a Honeydew account. If you don’t have one yet, schedule a 20-min onboarding here. Review the initial setup documentation for a full list of setup steps.
2

Native App installation name

Note the name you have given to the application (i.e. SEMANTIC_LAYER) and replace SEMANTIC_LAYER in all examples below with the actual application name. You can find the names of the installed applications by running the following command:
3

Create API Key

In Honeydew application, navigate to the Settings page, and generate an API Key to be used for this integration. Copy the generated API Key and API Secret values.
When creating the API key, make sure to assign the appropriate role based on the types of API calls you plan to make. For example:
  • If you only need to query data, assign the Viewer role
  • If you need to modify semantic layer definitions, assign the Editor role
  • If you need full administrative access, assign the Admin role
4

Set API Credentials

Set the Honeydew API Credentials for the Honeydew application, replacing api_key and api_secret with the generated API Key values:
5

Create Honeydew API Integration

Create a Snowflake integration to the Honeydew API:
This integration is used to allow the Honeydew native application to access the Honeydew API.The API_NETWORK_RULE is automatically created by the Honeydew native application setup process. It is pointing to the api.honeydew.cloud endpoint (or to a custom endpoint if you are using a private Honeydew deployment).
Make sure to name the integration HONEYDEW_API_ACCESS_INTEGRATION - do not change that name.
6

Grant Integration Access

Grant the Honeydew API integration to the Honeydew application:
7

Enable External Access

Enable the Honeydew API integration for all Honeydew code functions and procedures:
You will receive the following result upon success:
8

Grant Native App Access

Optionally, grant native app access to any additional Snowflake roles:
Only the ACCOUNTADMIN role has the CREATE INTEGRATION privilege by default. The privilege can be granted to additional roles as needed.

Upgrade

The Honeydew Snowflake Native Application is upgraded automatically when new versions are released.

Native App Access

Grant native app access to any additional Snowflake roles:

Usage Examples

Note that most calls require to choose the workspace and working branch. The convention here is to set those as variables, i.e.

Workspace and Branches

List all workspaces and branches:
Required permission: Viewer or higher
Create a new branch named branch for a given workspace:
Required permission: Editor or higher
Sync a specific entity’s table from source in a given workspace and branch:
Required permission: Editor or higher
Sync all tables from source in a given workspace and branch:
Required permission: Editor or higher
Reload a given workspace and branch:
Required permission: Viewer or higher
Reload all existing workspaces:
Required permission: Viewer or higher
Reload a given workspace and branch for all users:
Required permission: Admin
Reload all existing workspaces for all users:
Required permission: Admin

Schema

Parameters

List all global parameters in the given workspace and branch:
Required permission: Viewer or higher

Entities

List all entities in the given workspace and branch:
Required permission: Viewer or higher
List all entity relations in the given workspace and branch:
Required permission: Viewer or higher

Fields Metadata

List all fields in the given workspace and branch:
Required permission: Viewer or higher
List all broken fields (fields with error) in the given workspace and branch:
Required permission: Viewer or higher
List all fields in the given workspace and branch, for a specific domain:
Required permission: Viewer or higher
Fields include metrics and attributes.
All SHOW_* functions return object_key and yaml columns for each object. The object_key uniquely identifies the object and is used with ALTER_OBJECT and DROP_OBJECT. The yaml column contains the full YAML definition of the object.

Fields Add/Update/Delete

Change attribute field of entity entity
Required permission: Editor or higher
Change metric field of entity entity
Required permission: Editor or higher

Object CRUD

You can create, update, and delete any semantic layer object using its YAML definition. This provides a generic interface for managing entities, fields, domains, and other objects. Retrieve the object_key and yaml for existing objects from the SHOW_* functions described above. All object CRUD functions accept an optional force_with_error parameter (default FALSE). When set to TRUE, the operation proceeds even if validation errors are detected. This is useful when you want to save a draft that has known issues, such as a reference to a field that doesn’t exist yet. Create a new object from a YAML definition:
Update an existing object using its object_key:
Delete an object using its object_key:
Required permission: Editor or higher

Create Entity

Create a new entity with its dataset in a single call, by providing both the entity and dataset YAML definitions:
Required permission: Editor or higher

Domains

List all domains in the given workspace and branch:
Required permission: Viewer or higher
Show lookml model for all domains:
Required permission: Viewer or higher
Show lookml model for a specific domain:
Required permission: Viewer or higher
Show lightdash model for all domains:
Required permission: Viewer or higher
Show lightdash model for a specific domain:
Required permission: Viewer or higher

Queries

Get data from a semantic query

The following stored procedure allows to run a semantic query and get the resulting data. It also possible to only generate the SQL (see next section).
You might need to grant access for the native application to the relevant data, for example:
Required permission: Viewer or higher
If Honeydew parameters are used, their default values will be used. To control parameter values, generate the SQL and set parameter values within it - see the next section.
Attributes and metrics may either refer to named fields in the semantic layer, or to new ad-hoc calculations based on them.
Metric ad-hoc expressions can do anything a metric can do.In particular may use qualifiers such as FILTER (WHERE ...) and GROUP BY (...) to create ad-hoc filtered and/or partial metrics.
All the filters apply. To allow better performance optimizations, it is recommended to pass multiple filters that will all apply rather than a single one with multiple conditions and an AND between them.
When passing filters to the native app, may use both attributes and metrics for filtering.Attributes filter data similar to how WHERE behaves in SQL (only rows that match the expression are returned)When a metric is used in a filter (entity.count > 0) it will be grouped by attributes before filtering, similar to how HAVING behaves in SQL. Only rows that the metric aggregation matches are returned.

Generate SQL for a query

The following function generates SQL for an ad-hoc semantic query
Required permission: Viewer or higher

Using parameters with generated SQL

If a query is using Honeydew parameters then they will be generated as session variables in the query, and can be set with SET. This is typically used for automation, with code calling the API setting parameter values. A sample Snowflake stored procedure that sets parameters can look like:
Required permission: Viewer or higher

BI SQL Interface wrapper

It is possible to use the native application as a wrapper to the live SQL interface: Get data from ad-hoc SQL:
Required permission: Viewer or higher
Get compiled SQL query from ad-hoc SQL:
Required permission: Viewer or higher

Dynamic Datasets

Metadata

List all dynamic datasets in the given workspace and branch:
Required permission: Viewer or higher

Add/Update/Delete

Create a dynamic dataset dataset in given workspace and branch:
Required permission: Editor or higher
Update a dynamic dataset dataset in given workspace and branch:
Required permission: Editor or higher
Delete a dynamic dataset dataset from a given workspace and branch
Required permission: Editor or higher

Get Data or SQL

Get the data for a dynamic dataset dataset:
Required permission: Viewer or higher
Get the SQL query for a dynamic dataset dataset:
Required permission: Viewer or higher

Deployment

Deploy the dynamic dataset dataset according to its deployment settings (can be used for aggregate aware caching and incremental aggregate updates):
Required permission: Editor or higher
Deploy the entity entity according to its deployment settings (to update entity cache):
Required permission: Editor or higher
Deploy all entity caches in a given workspace and branch:
Required permission: Editor or higher
Get the SQL to build the entity cache, for use with an external orchestrator:
Required permission: Viewer or higher
Clear deployed cache status:
Required permission: Editor or higher
Honeydew scans the data warehouse information schema to check for validity of caches.If an entity or a dynamic dataset used for caching was deployed without calling DEPLOY_DYNAMIC_DATASET or DEPLOY_ENTITY (for example via a third party tool) then can call CLEAR_DEPLOYED_CACHE_STATUS to notify Honeydew that that a data cache was updated in the data warehouse.

AI Analyst

Plaintext Questions To Data

Translate plaintext questions to the correct Snowflake query using the semantic layer:
Returns a JSON object containing the following keys:
  • llm_response: A descriptive response from the language model
  • llm_response_json: The JSON representation of the semantic query
  • perspective: A JSON representing the attributes, metrics and filters of the query
  • sql: The generated SQL query
  • error: An error message if an error was encountered
  • judge: A JSON containing the judge evaluation of the answer
Required permission: Viewer or higher
The Claude 4.5 Sonnet (claude-sonnet-4-5) model currently demonstrates the best performance, and is recommended for most use cases.

Ask Deep Analysis Questions

Run complex analysis questions using a multi-step agentic flow, leveraging the semantic layer as the source of truth:
Returns a JSON object containing the following keys:
  • markdown: An analysis report in markdown format
  • data: A JSON array of data sets generated during the analysis
  • suggested_responses: An array of suggested follow-up questions
  • conversation_id: The conversation ID to be used for follow-up questions
Required permission: Viewer or higher

Cortex Code

Important: If using Cortex Code, ensure the Snowflake Cortex Prerequisites are met, including the COPILOT_USER role grant.

Use Cases

Semantic Querying

The native app allows to query data using the semantic layer, without the need to write SQL queries. This is useful for users who are not familiar with SQL or want to leverage the semantic layer’s capabilities to simplify their queries. You can find some examples here.

BI Tools Integration

The native app can be used to integrate Honeydew with various BI tools. You can find some examples here.

Building custom AI analyst applications

The native app can be used to build custom AI analyst applications that leverage the semantic layer to answer user questions in natural language. For more details, see the AI Analyst API documentation and AI Workflow documentation.

ETL Tools Integration

The native app interface can be used to integrate Honeydew with dbt as well as other ETL tools, for use cases such as:
  1. Automatically generating and refreshing datasets (tables/views) based on semantic layer definitions.
  2. Maintaining semantic layer pre-aggregations freshness.
  3. Deploying semantic layer definitions to production environments.
For more details, see the ETL Tools integration documentation and specifically the dbt integration documentation.

Development and Testing

The native app can be used to develop and test semantic layer definitions. Developers can use their favorite development tools to edit the semantic layer definitions, push them directly to git, and use the native app APIs to validate the definitions. These validations can also be integrated into CI/CD pipelines to ensure that the semantic layer definitions are valid before deploying them to production.

Example workflow

  1. Create a new branch in the semantic layer for development
  2. Make changes to the semantic layer definitions using your favorite development tools
  3. Push the changes to git
  4. Run the following native app calls to validate the changes:
  1. If there are no errors, create a pull/merge request in git to merge the changes into the main branch.
  2. Once the pull/merge request is approved, merge the changes into the main branch.
  3. Run the following native app call to reload the workspace and branch for all users: