Destinations

Destinations in Native App mode are the same connector catalog as cloud Zeotap — Salesforce, HubSpot, Meta, Google Ads, S3, Slack, Mailchimp, Klaviyo, Braze, and the rest. The difference is where the egress happens: instead of leaving Zeotap’s cloud, the request leaves your Snowflake account through an External Access Integration (EAI) you’ve explicitly approved for the destination’s host.

The two EAIs the install needs to operate (Zeotap cloud, SendGrid) are granted from the application’s Configure tab during install. Destination EAIs are granted per-type, on demand, when you add a destination — the recommended flow is described below.

Adding a destination type — recommended flow

In the Zeotap UI, choose Destinations → Add destination and pick the destination type. The destination wizard checks whether the destination type’s EAI is already bound to the application:

• If the EAI is bound, the wizard moves straight to OAuth or API-key entry.
• If the EAI is not bound, the wizard sends you to Apps → <APP_NAME> → Configure in Snowsight to click Grant on the destination’s reference. Snowsight reads the host:port allow-list from the application’s CONFIGURE_REFERENCE_CALLBACK and provisions the EAI on your behalf — no SQL required. Once you confirm the grant landed, the wizard re-checks the binding and proceeds with the destination configuration.

This per-type flow scopes egress narrowly: you only authorize outbound network access for the destinations you actually use, and Snowflake’s review surface stays manageable. The Configure-tab consent flow is idempotent — re-granting an already-bound reference is a no-op.

Per-destination EAI mapping

Every destination family has a corresponding EAI reference declared in the application manifest. Here is the catalog the in-product wizard and the Configure tab cover:

You only need to bind the references for destination families you actually use. The in-product wizard (recommended) only generates SQL for the type you’re adding. The bulk script (described below) lets you comment out any section you don’t need.

Configuring the destination

Once the EAI for the destination type is bound, the configuration flow is identical to cloud Zeotap — for OAuth destinations, the UI walks you through the OAuth flow; for API-key destinations, it asks for credentials directly. Zeotap stores the credentials in the in-account Postgres metadata store (encrypted at rest).

When the destination runs, the connector running in the SPCS service (or in an ephemeral job service for sync runs) opens an outbound HTTPS request to the destination’s host. The request leaves through the EAI for that destination type. If the EAI ever stops being bound — for instance, the operator drops it — the connector returns an External access integration not enabled error and the UI shows it on the destination’s status panel; the wizard can be re-run to re-provision.

Bulk-provision all destination EAIs

Two paths:

• Configure tab (recommended): Snowsight → Apps → <APP_NAME> → Configure, then Grant next to each destination’s manifest reference. Snowsight reads the host:port allow-list from the application’s CONFIGURE_REFERENCE_CALLBACK and provisions the EAI for you. No SQL required.
• Setup-app SQL blocks: Snowsight → Apps → <APP_NAME> → Open. The destination-EAI section renders the CREATE NETWORK RULE + CREATE EAI + REGISTER_REFERENCE_CALLBACK + ATTACH_EAI block per family with brand identifiers already substituted. Copy the blocks for the families you need into a Snowsight worksheet and run as ACCOUNTADMIN. Each section is independent. The blocks are idempotent — re-running rebuilds the rule and EAI without breaking anything.

Bring-your-own EAI for destinations outside the catalog

For destinations the catalog doesn’t cover — internal APIs, niche SaaS vendors, new vendors before Zeotap’s next Marketplace upgrade — your account admin can author an EAI in your account and grant USAGE to the Zeotap application:

-- 1. Create a network rule for the destination's host.
CREATE NETWORK RULE zeotap_infra.public.acme_rule
  TYPE = HOST_PORT MODE = EGRESS
  VALUE_LIST = ('api.acme.com:443');
 
-- 2. Wrap the rule in an EAI.
CREATE EXTERNAL ACCESS INTEGRATION acme_eai
  ALLOWED_NETWORK_RULES = (zeotap_infra.public.acme_rule)
  ENABLED = TRUE;
 
-- 3. Grant USAGE to the Zeotap application.
GRANT USAGE ON INTEGRATION acme_eai TO APPLICATION <APP_NAME>;

In the Zeotap UI, choose Add destination → Custom (BYO-EAI), enter acme_eai as the EAI name, and provide the destination’s credentials. Zeotap calls a procedure inside the application that validates the grant and runs ALTER SERVICE to attach the new EAI. The new integration takes effect on the next request without a service restart.

Restricted regions

Some Snowflake regions reject wildcard hostnames in EAI rules (e.g. *.salesforce.com). When that happens, use the fallback SQL path from the setup app’s destination grid — paste the family’s block into a Snowsight worksheet, replace the wildcard with a per-instance allow-list (e.g. acme.my.salesforce.com), and run as ACCOUNTADMIN. The list of regions known to require this workaround at each release is published on the Zeotap Marketplace listing page.