Snowflake Storage, API, and Git Integrations

1.Storage integration: delegated access to cloud storage

When Snowflake has to read from or write to your own cloud storage, it needs an identity that storage provider accepts. Without a storage integration, someone would paste secret keys into each stage definition. With one, Snowflake keeps a generated identity and access management (IAM) entity for your cloud storage. A cloud administrator grants that entity permissions on the buckets or containers, and users no longer supply credentials when they create stages or load and unload data.

The integration also controls *where* stages can point. STORAGE_ALLOWED_LOCATIONS lists the buckets and optional paths an external stage may reference, and STORAGE_BLOCKED_LOCATIONS can carve out exceptions. One integration can serve many external stages, but each stage URL must fall inside the allowed locations.

CREATE [ OR REPLACE ] STORAGE INTEGRATION [IF NOT EXISTS]
  <name>
  TYPE = { EXTERNAL_STAGE | POSTGRES_EXTERNAL_STORAGE | POSTGRES_INTERNAL_STORAGE }
  cloudProviderParams
  ENABLED = { TRUE | FALSE }
  STORAGE_ALLOWED_LOCATIONS = ('<cloud>://<bucket>/<path>/' [ , '<cloud>://<bucket>/<path>/' ... ] )
  [ STORAGE_BLOCKED_LOCATIONS = ('<cloud>://<bucket>/<path>/' [ , '<cloud>://<bucket>/<path>/' ... ] ) ]
  [ COMMENT = '<string_literal>' ]

The provider-specific parameters show how much of the work Snowflake handles. Amazon S3 needs STORAGE_AWS_ROLE_ARN, the IAM role your AWS administrator sets up. Microsoft Azure needs AZURE_TENANT_ID. Google Cloud Storage needs only STORAGE_PROVIDER = 'GCS': no key file is exchanged or stored, because the identity is generated on the Snowflake side.

Here is how it works for S3. The external stage references the storage integration. Snowflake associates the integration with the IAM user it created for your account, and your AWS administrator grants that user access to the buckets. Each time someone loads or unloads through the stage, Snowflake checks the IAM user's permissions on the bucket before it allows or denies access.

Two edge cases come up in exam questions. First, setting ENABLED = FALSE does more than stop new stages from using the integration. Existing stages that reference it lose access to their storage location too. Second, an integration cannot always be used. For cloud storage in a government region or a China region, it only works from a Snowflake account hosted in that same region. In other cases you supply credentials with the CREDENTIALS parameter of CREATE STAGE.

Sources12

2.API integration: reaching services over HTTPS

A storage integration is for object storage. An API integration is for any service Snowflake calls over HTTPS. The object records which kind of service it is, the identifier and credentials Snowflake uses to call it, and which endpoints are allowed. The service might be a cloud provider's HTTPS proxy, such as an Amazon API Gateway behind an external function, a Git repository API, or an external Model Context Protocol (MCP) server. The API_PROVIDER parameter sets the type of service, and each provider has its own syntax.

For external functions, the API integration is the object Snowflake checks before any outbound call leaves the account. API_ALLOWED_PREFIXES limits which proxy endpoints and resources the functions using the integration may call. Each URL in the list works as a prefix: allowing https://xyz.amazonaws.com/production/ allows every resource under that path. API_BLOCKED_PREFIXES (Azure, Google and Git syntax) excludes paths that would otherwise be allowed. The prefix list is enforced by Snowflake regardless of what the attached cloud role could reach, so it is the place to tighten scope. Two smaller rules: an Azure API integration can authenticate to only one tenant, and setting ENABLED = FALSE breaks every external function that relies on the integration.

CREATE [ OR REPLACE ] API INTEGRATION [ IF NOT EXISTS ] <integration_name>
  API_PROVIDER =  ? 
  API_ALLOWED_PREFIXES = ('<...>')
  [ API_BLOCKED_PREFIXES = ('<...>') ]
  [ ALLOWED_AUTHENTICATION_SECRETS = ( { <secret_name> [, <secret_name>, ... ] } ) | all | none ]
  ENABLED = { TRUE | FALSE }
  [ COMMENT = '<string_literal>' ]
  ;

Sources3

3.Git integration: a repository clone built on an API integration

Git integration is not a third kind of integration object. It is a Git repository clone, a schema-level object (GIT REPOSITORY) that sits on top of an API integration whose API_PROVIDER is git_https_api. Once set up, Snowflake keeps a clone of your remote repository that includes all branches, tags and commits. Snowflake then acts as one more client of that repository, so your local development tools carry on working as before.

Supported platforms are GitHub, GitLab, BitBucket, Azure DevOps and AWS CodeCommit, including instances at custom URLs, such as a corporate Git server. The origin URL must use HTTPS. Repositories larger than 2 GB are not supported.

Creating a clone takes three things: the ORIGIN URL, the API_INTEGRATION, and optionally GIT_CREDENTIALS. GIT_CREDENTIALS names a Snowflake secret, ideally holding a personal access token. If the remote needs authentication, the secret must already exist and must be listed in the API integration's ALLOWED_AUTHENTICATION_SECRETS. That rule explains a common failure: the token and the integration can each be correct and authentication still fails, because the two objects were never linked. The creating role needs CREATE GIT REPOSITORY on the schema plus USAGE on both the integration and the secret.

CREATE OR REPLACE GIT REPOSITORY snowflake_extensions
  API_INTEGRATION = git_api_integration
  GIT_CREDENTIALS = git_secret
  ORIGIN = 'https://github.com/my-account/snowflake-extensions.git';

After the clone exists, you work with it much like a stage. The command family is CREATE, ALTER, DESCRIBE and DROP GIT REPOSITORY, plus SHOW GIT REPOSITORIES, SHOW GIT BRANCHES and SHOW GIT TAGS. ALTER GIT REPOSITORY … FETCH pulls the latest branches, tags and commits from the remote. You list files with the stage path syntax, for example LS @repository_name/branches/branch_name, and the same path pattern works for tags and commits. Paths into the clone can also point to handler files for procedures and UDFs.

To run a SQL script kept in the repository, use EXECUTE IMMEDIATE FROM with a path into the clone. It can be run from any Snowflake session, so you can keep a script such as a new-account setup in Git. The role running it needs the privileges for every statement in the file. In the other direction, Workspaces, Streamlit apps and Snowflake notebooks can commit and push changes back to the remote repository.

EXECUTE IMMEDIATE FROM @snowflake_extensions/branches/main/sql/create-database.sql;

Sources456

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Every S3 storage integration gets its own Snowflake IAM user, so separate integrations are isolated at the AWS identity level.Why is that wrong?

   Snowflake creates one IAM user per account, and all S3 storage integrations reference it. Separation comes from bucket permissions and STORAGE_ALLOWED_LOCATIONS.

   Covered in Storage integration: delegated access to cloud storage

2. 2.Git integration is its own integration type, created with a dedicated CREATE ... INTEGRATION statement separate from API integrations.Why is that wrong?

   A Git repository clone references an ordinary API integration whose API_PROVIDER is git_https_api.

   Covered in Git integration: a repository clone built on an API integration

3. 3.Any secret containing a valid token can be passed as GIT_CREDENTIALS.Why is that wrong?

   The secret must also be listed in the API integration's ALLOWED_AUTHENTICATION_SECRETS. A valid token in a secret that isn't listed still fails.

   Covered in Git integration: a repository clone built on an API integration

Practise it for real

Connect a GitHub repository to Snowflake and run a SQL script from it

1. 1.Create an API integration with API_PROVIDER = git_https_api. Set API_ALLOWED_PREFIXES to your organization's GitHub URL and list your secret's name in ALLOWED_AUTHENTICATION_SECRETS.

   Why: The Git repository clone needs a git_https_api integration, and the integration decides which secrets and URLs are allowed.

   You should see: The integration appears in SHOW INTEGRATIONS.

2. 2.Create a secret of TYPE password that holds your GitHub username and a personal access token, and make sure its name matches the one listed in ALLOWED_AUTHENTICATION_SECRETS.

   Why: GIT_CREDENTIALS must name a secret the integration allows, and the docs recommend a personal access token as the password.

   You should see: The secret exists in a schema your role can use.

3. 3.Run CREATE GIT REPOSITORY with ORIGIN set to the repository's HTTPS URL, API_INTEGRATION set to your integration, and GIT_CREDENTIALS set to your secret.

   Why: This creates the clone in Snowflake, including its branches, tags and commits.

   You should see: SHOW GIT REPOSITORIES lists the new clone, and SHOW GIT BRANCHES lists your branches.

4. 4.Push a setup.sql file to the remote, then run ALTER GIT REPOSITORY <name> FETCH.

   Why: The clone only sees remote changes after a fetch.

   You should see: LS @<name>/branches/main; lists the new file.

5. 5.Run EXECUTE IMMEDIATE FROM @<name>/branches/main/setup.sql; using a role that can run every statement in the file.

   Why: This runs the script stored in Git from a Snowflake session.

   You should see: The result of the file's last statement is returned.