Snowflake customer access guide
How can customers access Snowflake data without Snowflake accounts?
Use a customer portal for branded human access and workflow, a reader account for a managed Snowflake query experience, or an API or export for system-to-system consumption.
The direct answer
Customers do not need personal Snowflake accounts to use data stored in Snowflake. A customer portal can authenticate them through the application, enforce organisation and role permissions, query Snowflake through a constrained server-side identity and return only the approved result.
For technically capable data consumers, Snowflake reader accounts provide a provider-managed way to query shared read-only data. For software consumers, expose a stable customer API or controlled export rather than warehouse credentials.
01
Four practical access patterns
| Pattern | Best for | Customer experience | Main responsibility |
|---|---|---|---|
| Customer portal | Business users, self-service and workflow | Branded web application | Application identity, authorisation and support |
| Reader account | Data users who need SQL analysis | Provider-managed Snowflake account | Provider administration, share and compute governance |
| Customer API | Customer software and repeatable integration | Versioned machine contract | Authentication, quotas, scope and lifecycle |
| Scheduled export | Periodic, bounded exchange | File delivered through an agreed channel | Cut-off, schema, security and reconciliation |
Snowflake also documents Open Data Sharing for non-Snowflake consumers through an Iceberg REST Catalog, but currently marks it as Preview. Treat it as an emerging data-platform option and confirm feature status and constraints before using it in a production design.
02
Use a portal when the customer needs meaning and action
The customer never sees Snowflake credentials or tables. The application resolves who they represent, what records and fields they may access, and which query shapes are allowed. It can add definitions, freshness, files, support and actions that data sharing alone does not provide.
This is usually the best choice for account managers, operational users, customers with varied technical ability, or any service that needs a consistent brand and workflow. See the detailed Snowflake customer portal architecture.
03
Use reader accounts for provider-managed analytical access
Snowflake Secure Data Sharing lets a provider share selected database objects without copying the data. Shared objects are read-only to the consumer. A standard share is consumed by another Snowflake account; a reader account lets a provider give a non-customer a Snowflake environment for querying shared data.
- The provider creates, owns and manages the reader account.
- The consumer works in a Snowflake data environment rather than a bespoke portal.
- The shared objects remain read-only.
- The provider must plan identity, administration, warehouse use, monitoring and support.
- The approach fits capable data consumers, not every external business user.
A reader account is not simply a free login screen. Confirm commercial and operational responsibilities against current Snowflake documentation before offering it as a customer service.
04
Use an API or export for machine consumption
A customer API should expose stable business resources, not a generic SQL proxy. Authenticate the calling organisation, authorise each dataset and operation, limit fields and volume, paginate results, version contracts and make usage visible. A scheduled export can be simpler when data is periodic and the receiving system already supports files.
API
On-demand integration
Use for repeatable customer software access with bounded requests and supportable versions.
Export
Periodic exchange
Use for agreed snapshots with schema, totals, encryption, delivery status and retention.
Compare an API with a customer portal when both human and machine access are under consideration.
05
Choose from the customer job
- Choose a portal when people need guided search, explanation, documents, workflow or delegated customer administration.
- Choose Secure Data Sharing when the customer already works in Snowflake and wants governed read-only data in its own account.
- Choose a reader account when a capable data consumer needs a Snowflake query environment but is not an existing Snowflake customer.
- Choose an API when customer software needs on-demand, versioned access.
- Choose an export when periodic delivery is enough and a simpler contract reduces operating effort.
- Combine patterns when business users and data teams inside the same customer have different needs.
06
Keep access governed in every pattern
- Define the customer organisation, data purpose and approved fields.
- Map customer identities to governed Snowflake keys and entitlements.
- Use separate least-privilege service identities and protect credentials.
- Apply row and field restrictions close to the data and again in the delivery contract.
- Bound queries, exports, concurrency and data retention.
- Expose freshness and material limitations.
- Audit sensitive access and assign support, data-quality and security owners.
Sources
Primary references
Questions
Frequently asked questions
Can customers access Snowflake data without Snowflake accounts?
Yes. A customer-facing application can query approved Snowflake data on the server and present it through the application's own identity and permissions. Snowflake reader accounts are another option for consumers who need a Snowflake query experience without being existing Snowflake customers.
What is a Snowflake reader account?
A reader account is created and managed by a data provider so a consumer can query shared read-only data without becoming a Snowflake customer. The provider carries account-management and usage responsibilities, so it is not the same as a branded customer portal.
Is Secure Data Sharing suitable for every customer?
No. Standard Secure Data Sharing fits consumers with Snowflake accounts and data capability. A portal is usually easier for business users who need guided access, explanation and workflow.
Can we give customers an API instead?
Yes. A customer API or scheduled export suits machine-to-machine use. It still needs application-owned authentication, customer scope, quotas, versioning and support.
Does Snowflake Open Data Sharing remove the need for an application?
Not necessarily. Snowflake currently documents Open Data Sharing as a Preview feature for non-Snowflake consumers through the Iceberg REST Catalog. It is a data-access option, not a replacement for a branded human workflow, and its status should be checked before adoption.
Choose the access path
Bring the customer roles, data need and expected usage.
LCR can help define the application and integration layer when customers need useful access without direct warehouse exposure.