Skip to main content

​
Snowflake कनेक्टर के बारे में

Snowflake कनेक्टर आपको अपने Snowflake डेटा वेयरहाउस के डेटा को सीधे Perplexity से क्वेरी करने की सुविधा देता है। आप अपने Snowflake डेटाबेसेज़, अपने अन्य कनेक्ट किए गए ऐप्स, और वेब में जानकारी खोज और संयोजित कर सकते हैं — बिना SQL मैन्युअल रूप से लिखे या Snowflake कंसोल पर स्विच किए।

यह Perplexity Pro, Perplexity Max, Enterprise Pro, और Enterprise Max पर उपलब्ध है। Snowflake को कनेक्ट करना प्रति-उपयोगकर्ता किया जाता है — जब तक आप डेटा को किसी साझा प्रोजेक्ट में सिंक नहीं करते, आपके संगठन में कोई और आपका डेटा क्वेरी नहीं कर सकता।

यह मार्गदर्शिका बताती है कि कनेक्टर कैसे काम करता है, प्रमाणीकरण विधि कैसे चुनें, रोल्स और केवल-पठनीय एक्सेस कैसे कॉन्फ़िगर करें, और चरण-दर-चरण सेटअप कैसे करें। यदि आप बस सबसे तेज़ रास्ता चाहते हैं: अधिकांश संगठनों को User OAuth का उपयोग करना चाहिए — सीधे सेटअप गाइड पर जाएँ।

​
कनेक्टर किस डेटा तक एक्सेस कर सकता है

एक बार सक्षम होने पर, कनेक्टर आपके Snowflake अकाउंट से सुरक्षित रूप से कनेक्ट होता है और आपको उन डेटाबेसेज़, स्कीमाज़, टेबल्स, और व्यूज़ में खोज करने की सुविधा देता है जिन्हें देखने के लिए आप अधिकृत हैं। जब आपका Snowflake डेटा बदलता है, तो कनेक्टर आपकी अगली क्वेरी पर उन परिवर्तनों को स्वचालित रूप से दर्शाता है।

समर्थित डेटा ऑब्जेक्ट्स:

  • टेबल्स

  • व्यूज़ और मटीरियलाइज़्ड व्यूज़

  • स्कीमाज़

  • डेटाबेसेज़

  • संरचित डेटा (CSV-, JSON-, और Parquet-समर्थित टेबल्स)

असंरचित डेटा (Snowflake स्टेजेस में संग्रहीत इमेज, ऑडियो, और वीडियो) समर्थित नहीं है।

​
प्रमाणीकरण विधि चुनना

Snowflake प्रमाणीकरण के दो स्वतंत्र आयाम हैं: क्वेरीज़ किसके रूप में चलती हैं (पहचान) और वह पहचान कैसे खुद को सिद्ध करती है (क्रेडेंशियल)। Perplexity डायरेक्टरी में दो कनेक्टर उपलब्ध कराता है, जिनमें से प्रत्येक एक अनुशंसित संयोजन से मेल खाता है:

  • Snowflake (User OAuth) — प्रत्येक Perplexity उपयोगकर्ता OAuth के माध्यम से अपने स्वयं के Snowflake अकाउंट (TYPE = PERSON) से साइन इन करता है। अधिकांश संगठनों के लिए अनुशंसित।

  • Snowflake — सभी Perplexity उपयोगकर्ता एक key pair का उपयोग करके एक साझा सेवा अकाउंट (TYPE = SERVICE) के माध्यम से क्वेरी करते हैं। इसका उपयोग तब करें जब आपके अंतिम उपयोगकर्ताओं के पास व्यक्तिगत Snowflake अकाउंट न हों।

​
अनुशंसित: User OAuth

User OAuth के साथ, प्रत्येक व्यक्ति अपने स्वयं के क्रेडेंशियल्स से प्रमाणीकरण करता है, क्वेरीज़ उनकी मूल Snowflake अनुमतियों के अंतर्गत चलती हैं, और आपको एक स्पष्ट प्रति-उपयोगकर्ता ऑडिट ट्रेल मिलता है — कोई साझा सेवा अकाउंट नहीं और Perplexity के भीतर अपने रोल-आधारित एक्सेस नियंत्रण (RBAC) को फिर से बनाने की आवश्यकता नहीं। यह Snowflake की अपनी दिशा से भी मेल खाता है: इसका प्रबंधित MCP सर्वर आज केवल OAuth 2.0 का समर्थन करता है।

नोट: OAuth के साथ, एक्सेस टोकन साइन-इन के समय एक ही प्राथमिक रोल — उपयोगकर्ता के DEFAULT_ROLE — से बंधा होता है। यह सुनिश्चित करने के लिए कि उपयोगकर्ता उन्हें दी गई हर चीज़ तक पहुँच सकें, द्वितीयक रोल्स कॉन्फ़िगर करें (User OAuth रोल कॉन्फ़िगरेशन देखें)।

​
फ़ॉलबैक: सेवा अकाउंट (key pair)

एक साझा सेवा अकाउंट (TYPE = SERVICE + key pair) तब उपयुक्त है जब:

  • आपके अंतिम उपयोगकर्ताओं के पास व्यक्तिगत Snowflake अकाउंट नहीं हैं (उदाहरण के लिए, ऐसे व्यावसायिक उपयोगकर्ता जो Perplexity के माध्यम से क्वेरी करते हैं लेकिन जिनके पास Snowflake तक प्रत्यक्ष एक्सेस नहीं है)।

  • आप चाहते हैं कि सरल ऑडिटिंग के लिए सभी Perplexity क्वेरीज़ एक ही साझा पहचान के अंतर्गत चलें।

  • आप एक आंतरिक या परीक्षण वातावरण सेट कर रहे हैं जहाँ प्रति-उपयोगकर्ता पहचान की आवश्यकता नहीं है।

सेवा अकाउंट को एक समर्पित, संकीर्ण दायरे वाली रोल के साथ कॉन्फ़िगर करें — सेवा अकाउंट रोल कॉन्फ़िगरेशन देखें।

Programmatic Access Tokens (PATs) पर एक नोट: Snowflake PAT क्रेडेंशियल्स का भी समर्थन करता है, और कनेक्टर उन्हें स्वीकार करता है। हम नए सेटअप के लिए PAT की अनुशंसा नहीं करते — टोकन छोटी अवधि में समाप्त हो जाते हैं और निर्माण के समय एक ही रोल से कठोरता से बंधे होते हैं, इसलिए इस मार्गदर्शिका के सभी उदाहरणों में हम key pair का उपयोग करते हैं। यदि आपको PAT का उपयोग करना ही है, तो निर्माण के समय ROLE_RESTRICTION को अपनी समर्पित Perplexity रोल पर सेट करें।

​
रोल्स और एक्सेस कॉन्फ़िगर करना

​
User OAuth रोल कॉन्फ़िगरेशन

OAuth सत्र उपयोगकर्ता के DEFAULT_ROLE को प्राथमिक रोल के रूप में लेकर खुलता है; सत्र के भीतर रोल बदलना समर्थित नहीं है और Perplexity कोई रोल चयनकर्ता नहीं दिखाता। इसलिए प्रत्येक उपयोगकर्ता ने DEFAULT_ROLE और DEFAULT_SECONDARY_ROLES के लिए जो भी सेट किया है, ठीक वही उनका Perplexity सत्र उपयोग करता है।

इसे एक बार, सुरक्षा इंटीग्रेशन स्तर पर सेट करें:

OAUTH_USE_SECONDARY_ROLES = IMPLICIT

Snowflake का इस पैरामीटर के लिए डिफ़ॉल्ट NONE है, जिसका अर्थ है कि OAuth सत्र केवल प्राथमिक रोल सक्रिय करके खुलते हैं। इसे IMPLICIT पर सेट करना Snowflake को बताता है कि प्रत्येक उपयोगकर्ता के DEFAULT_SECONDARY_ROLES को भी स्वचालित रूप से सक्रिय करे। इसके बिना, उपयोगकर्ता केवल वही डेटा देखते हैं जो उनके DEFAULT_ROLE के माध्यम से पहुँच योग्य है — जो शायद ही कभी आप चाहते हैं।

इसके बाद दो मामलों में से एक को संभालें:

मामला A — उपयोगकर्ताओं के पास पहले से रोल डिफ़ॉल्ट्स हैं। यदि आपके उपयोगकर्ताओं के DEFAULT_ROLE और DEFAULT_SECONDARY_ROLES पहले से वैसे ही सेट हैं जैसे आप चाहते हैं, तो कुछ और न करें। IMPLICIT सेटिंग पर्याप्त है — प्रत्येक उपयोगकर्ता के मौजूदा डिफ़ॉल्ट्स ही उनके Perplexity सत्र में उपयोग होते हैं।

मामला B — उपयोगकर्ताओं के पास अभी तक रोल डिफ़ॉल्ट्स नहीं हैं। DEFAULT_ROLE को PUBLIC और DEFAULT_SECONDARY_ROLES को ALL पर सेट करके प्रत्येक सत्र को उस उपयोगकर्ता को दी गई सभी रोल्स का संघ दें:

ALTER USER <username> SET DEFAULT_ROLE = PUBLIC, DEFAULT_SECONDARY_ROLES = (‘ALL’);

नोट: Snowflake के अगस्त 2024 के परिवर्तन के बाद से, नए बनाए गए उपयोगकर्ताओं के लिए DEFAULT_SECONDARY_ROLES = (‘ALL’) डिफ़ॉल्ट है, इसलिए कई संगठनों में यह पहले से सेट है। कुछ भी बदलने से पहले जाँचने के लिए DESC USER <username> चलाएँ।

​
सेवा अकाउंट रोल कॉन्फ़िगरेशन

सेवा अकाउंट एक एकल समर्पित उपयोगकर्ता होता है जो एक विशिष्ट रोल के अंतर्गत चलता है — आमतौर पर PERPLEXITY_ROLE। OAuth के लिए उपयोग किया जाने वाला PUBLIC + (‘ALL’) पैटर्न यहाँ लागू नहीं होता। इसके बजाय, सेवा उपयोगकर्ता के DEFAULT_ROLE को अपनी समर्पित रोल पर सेट करें और उस रोल को केवल वही विशेषाधिकार दें जिनकी Perplexity को आवश्यकता है। यह Snowflake की सेवा अकाउंट सर्वोत्तम प्रथाओं का पालन करता है।

इस उपयोगकर्ता को बनाने का पूरा SQL नीचे सेटअप गाइड में दिया गया है।

​
(वैकल्पिक) OAuth के माध्यम से किन रोल्स का उपयोग किया जा सकता है, उसे प्रतिबंधित करना

यह सीमित करने के लिए कि उपयोगकर्ता Perplexity OAuth इंटीग्रेशन के माध्यम से किन Snowflake रोल्स में प्रमाणीकरण कर सकते हैं, इसे सुरक्षा इंटीग्रेशन स्तर पर सीमित करें:

  • PRE_AUTHORIZED_ROLES_LIST — इस इंटीग्रेशन के माध्यम से अनुमत रोल्स की अनुमति सूची।

  • BLOCKED_ROLES_LIST — इस इंटीग्रेशन से अवरुद्ध रोल्स की अस्वीकृति सूची।

ALTER SECURITY INTEGRATION PERPLEXITY_OAUTH
  SET PRE_AUTHORIZED_ROLES_LIST = (‘ANALYST_ROLE’, ‘READ_ONLY_ROLE’);

संवेदनशील रोल्स (उदाहरण के लिए ACCOUNTADMIN) को OAuth फ़्लो से पूरी तरह बाहर रखने के लिए इसका उपयोग करें।

​
Perplexity क्या कर सकता है, इसे नियंत्रित करना

कनेक्टर SQL को एक टूल सरफ़ेस (Merge Snowflake कनेक्टर से प्राप्त) के माध्यम से निष्पादित करता है। Snowflake (User OAuth) कनेक्टर बारीक, नामित टूल्स प्रस्तुत करता है — जिसमें एक समर्पित केवल-पठनीय क्वेरी टूल (execute_sql_readonly) शामिल है, जो केवल SELECT, WITH, SHOW, DESCRIBE, EXPLAIN, VALUES, और LIST स्वीकार करता है, और DDL/DML तथा बहु-कथन इनपुट को अस्वीकार करता है। सेवा-अकाउंट Snowflake कनेक्टर एक सामान्य execute_sql टूल प्रस्तुत करता है जो DDL और DML सहित मनमाना SQL स्वीकार करता है।

आधिकारिक नियंत्रण Snowflake RBAC है। चाहे कोई भी टूल कॉल किया जाए, क्वेरीज़ उसी रोल के अंतर्गत चलती हैं जिसकी आपका कॉन्फ़िगरेशन अनुमति देता है, इसलिए Snowflake रोल स्तर पर केवल-पठनीय प्रवर्तित करना ही विश्वसनीय बैकस्टॉप है — और सेवा-अकाउंट कनेक्टर पर यही एकमात्र प्रवर्तन सीमा है।

अनुशंसित पैटर्न — एक समर्पित रोल के साथ केवल-पठनीय प्रवर्तित करें। एक ऐसी रोल (जैसे PERPLEXITY_READ_ONLY) प्रावधान करें जो उन डेटाबेसेज़, स्कीमाज़, और टेबल्स पर केवल USAGE और SELECT देती है जिन्हें आप Perplexity को क्वेरी करने देना चाहते हैं, और INSERT, UPDATE, DELETE, CREATE, DROP, OWNERSHIP, या वेयरहाउस MODIFY नहीं देती। फिर सुनिश्चित करें कि उपयोगकर्ता उसी रोल में प्रमाणीकरण करें:

RBAC को इस तरह कॉन्फ़िगर करने पर, Snowflake Perplexity के किसी भी लेखन प्रयास को अस्वीकार कर देता है, चाहे कोई भी टूल कॉल किया जाए।

नोट: कनेक्टर सेटिंग्स में एक Tool permissions पैनल शामिल है जो उपलब्ध टूल्स की सूची देता है। Snowflake (User OAuth) कनेक्टर पर आप सीमित कर सकते हैं कि कौन से टूल्स प्रस्तुत किए जाएँ — केवल-पठनीय सेटअप के लिए, केवल रीड टूल्स सक्षम करें (उदाहरण के लिए execute_sql_readonly, list_*, describe_*, get_*) ताकि राइट/DDL टूल्स सरफ़ेस से बाहर रहें। इसे गहराई-में-सुरक्षा (defense-in-depth) मानें, आधिकारिक सीमा नहीं: Snowflake RBAC (ऊपर) ही वह है जो एक्सेस को विश्वसनीय रूप से प्रवर्तित करता है।

​
गोपनीयता और डेटा सुरक्षा

कनेक्ट होने पर, Snowflake कनेक्टर आपकी ओर से निम्नलिखित कार्रवाइयाँ कर सकता है:

  • आपके Snowflake डेटा पर SQL क्वेरीज़ निष्पादित करना

  • Cortex Search और Cortex Analyst क्वेरी करना

  • कस्टम UDFs और स्टोर्ड प्रोसीजर चलाना

यदि आप Snowflake में एक्सेस रद्द करते हैं या कोई रोल हटाते हैं, तो वह डेटा Perplexity से तुरंत अप्राप्य हो जाता है। यदि आप Perplexity में Snowflake को डिस्कनेक्ट करते हैं, तो आप चुन सकते हैं कि कैश्ड डेटा रखना है या डिलीट करना है।

​
Enterprise-grade सुरक्षा और नियंत्रण

Enterprise संगठनों के लिए, Perplexity SOC 2 Type II प्रमाणन, एंड-टू-एंड एन्क्रिप्शन, सख्त डेटा गोपनीयता उपाय, और बारीक उपयोगकर्ता एक्सेस नियंत्रण प्रदान करता है। आपके Snowflake डेटा का उपयोग AI प्रशिक्षण के लिए कभी नहीं किया जाता।

Snowflake को कनेक्ट करना प्रति-उपयोगकर्ता किया जाता है — आपके संगठन में कोई और आपका डेटा क्वेरी नहीं कर सकता। हालाँकि, यदि आप किसी साझा प्रोजेक्ट में डेटा सिंक करते हैं, तो उस प्रोजेक्ट तक एक्सेस वाला कोई भी व्यक्ति उसे खोज सकता है।

संगठन एडमिन Organization Settings में Permissions स्क्रीन से सभी उपयोगकर्ताओं के लिए कनेक्टर को सक्षम या अक्षम कर सकते हैं। रीड/राइट प्रवर्तन Snowflake रोल स्तर पर किया जाता है (Perplexity क्या कर सकता है, इसे नियंत्रित करना देखें)।

​
सेटअप गाइड

अपनी प्रमाणीकरण विधि से मेल खाने वाला मार्ग चुनें:

  • User OAuth (अनुशंसित): एक संगठन एडमिन OAuth ऐप को एक बार कॉन्फ़िगर करता है, फिर उपयोगकर्ता व्यक्तिगत रूप से साइन इन करते हैं। सीधे Snowflake को Perplexity से कनेक्ट करें पर जाएँ — चरण 1–6 का SQL केवल सेवा-अकाउंट सेटअप के लिए है।

  • सेवा अकाउंट (key pair): चरण 1–6 में SQL सेटअप चलाएँ, फिर चरण 7 में कनेक्ट करें।

​
पूर्वापेक्षाएँ

  • ACCOUNTADMIN रोल (या CREATE USER और GRANT विशेषाधिकारों वाली कोई रोल)

  • लोकल मशीन पर OpenSSL इंस्टॉल हो (macOS पर पहले से इंस्टॉल) — केवल सेवा-अकाउंट सेटअप के लिए

​
Step 1: एक key pair जनरेट करें (सेवा अकाउंट)

अपने टर्मिनल से, एक RSA निजी कुंजी जनरेट करें:

openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out snowflake_computer_key.p8 -nocrypt

फिर उससे मेल खाती सार्वजनिक कुंजी जनरेट करें:

openssl rsa -in snowflake_computer_key.p8 -pubout -out snowflake_computer_key.pub

​
Step 2: एक रोल और वेयरहाउस बनाएँ

USE ROLE ACCOUNTADMIN;

— Create a dedicated role
CREATE ROLE IF NOT EXISTS PERPLEXITY_ROLE
  COMMENT = ‘Role for Perplexity service account’;

— Create a warehouse (or use an existing one)
CREATE WAREHOUSE IF NOT EXISTS PERPLEXITY_WAREHOUSE
  WAREHOUSE_SIZE = ‘XSMALL’
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE
  COMMENT = ‘Warehouse for Perplexity queries’;

— Grant warehouse usage to the role
GRANT USAGE ON WAREHOUSE PERPLEXITY_WAREHOUSE TO ROLE PERPLEXITY_ROLE;

​
Step 3: सेवा अकाउंट उपयोगकर्ता बनाएँ

इसे ACCOUNTADMIN के रूप में चलाएँ। RSA_PUBLIC_KEY मान को अपनी snowflake_computer_key.pub फ़ाइल की सामग्री से बदलें (हैडर और फ़ुटर पंक्तियों के बिना)।

USE ROLE ACCOUNTADMIN;

CREATE USER PERPLEXITY_USER
  TYPE = SERVICE
  DEFAULT_ROLE = PERPLEXITY_ROLE
  DEFAULT_WAREHOUSE = PERPLEXITY_WAREHOUSE
  COMMENT = ‘Service account for Perplexity’
  RSA_PUBLIC_KEY = ‘MIIBIjANBgkqhki…your_public_key_here…IDAQAB’;

— Grant the dedicated role to the service account
GRANT ROLE PERPLEXITY_ROLE TO USER PERPLEXITY_USER;

नोट: TYPE = SERVICE इसे एक गैर-मानवीय अकाउंट के रूप में चिह्नित करता है — पासवर्ड सेट न करें। DEFAULT_ROLE = PERPLEXITY_ROLE इसे केवल उन्हीं विशेषाधिकारों वाली एक समर्पित रोल तक सीमित करता है जिनकी Perplexity को आवश्यकता है।

​
Step 4: अपने डेटा तक एक्सेस दें

— Grant access to a specific database
GRANT USAGE ON DATABASE MY_DATABASE TO ROLE PERPLEXITY_ROLE;

— Grant access to all schemas in a database (current and future)
GRANT USAGE ON ALL SCHEMAS IN DATABASE MY_DATABASE TO ROLE PERPLEXITY_ROLE;
GRANT USAGE ON FUTURE SCHEMAS IN DATABASE MY_DATABASE TO ROLE PERPLEXITY_ROLE;

— Grant read access to all tables and views (current and future)
GRANT SELECT ON ALL TABLES IN DATABASE MY_DATABASE TO ROLE PERPLEXITY_ROLE;
GRANT SELECT ON FUTURE TABLES IN DATABASE MY_DATABASE TO ROLE PERPLEXITY_ROLE;
GRANT SELECT ON ALL VIEWS IN DATABASE MY_DATABASE TO ROLE PERPLEXITY_ROLE;
GRANT SELECT ON FUTURE VIEWS IN DATABASE MY_DATABASE TO ROLE PERPLEXITY_ROLE;

अधिक चयनात्मक एक्सेस के लिए, Snowflake GRANT डॉक्यूमेंटेशन देखें।

​
Step 5: क्वेरी हिस्ट्री और एक्सेस हिस्ट्री तक एक्सेस दें

Perplexity सटीक क्वेरी निर्माण के लिए Data Map बनाने हेतु SNOWFLAKE.ACCOUNT_USAGE स्कीमा के दो व्यूज़ का उपयोग करता है:

View

उद्देश्य

QUERY_HISTORY

क्वेरी मेटाडेटा, प्रदर्शन, और उपयोग पैटर्न

ACCESS_HISTORY

ऑब्जेक्ट-स्तरीय ऑडिट ट्रेल (केवल Enterprise Edition)

USE ROLE ACCOUNTADMIN;
GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE PERPLEXITY_ROLE;

नोट: ACCESS_HISTORY केवल Snowflake Enterprise Edition या उच्चतर पर उपलब्ध है; Standard Edition पर Perplexity स्वचालित रूप से QUERY_HISTORY पर वापस आ जाता है। इस चरण को छोड़ने से क्वेरी सटीकता कम हो जाती है। Perplexity इन व्यूज़ का उपयोग कैसे करता है, इसके लिए Data Map को समझना देखें।

​
एक्सेस सत्यापित करें

USE ROLE ACCOUNTADMIN;
GRANT ROLE PERPLEXITY_ROLE TO USER <your_username>;
USE ROLE PERPLEXITY_ROLE;
USE WAREHOUSE PERPLEXITY_WAREHOUSE;
SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY LIMIT 5;
SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY LIMIT 5;

​
Step 6: (वैकल्पिक) IP पतों को अनुमति सूची में डालें

यदि आपका Snowflake अकाउंट आने वाले कनेक्शनों को IP के अनुसार प्रतिबंधित करता है, तो इस पेज से IP पतों को अनुमति सूची में डालें:

USE ROLE ACCOUNTADMIN;
CREATE NETWORK POLICY PERPLEXITY_COMPUTER_POLICY
  ALLOWED_IP_LIST = (…US IPs from the link above…);
ALTER USER PERPLEXITY_USER SET NETWORK_POLICY = PERPLEXITY_COMPUTER_POLICY;

​
Step 7: Snowflake को Perplexity से कनेक्ट करें

​
User OAuth के लिए: पहले एडमिन सेटअप

यदि आपका संगठन OAuth का उपयोग करता है, तो व्यक्तिगत उपयोगकर्ताओं के प्रमाणीकरण से पहले एक संगठन एडमिन Snowflake (User OAuth) कनेक्टर को एक बार कॉन्फ़िगर करता है। Organization Settings → Connectors → Snowflake (User OAuth) में, एडमिन को एक तीन-चरणीय पेन दिखाई देता है:

1

Manage OAuth app — अपने Snowflake अकाउंट के विरुद्ध Perplexity को OAuth क्लाइंट के रूप में पंजीकृत करें। यह आपको एक कस्टम Snowflake SECURITY INTEGRATION बनाने और परिणामी Client ID और Client Secret को Perplexity में वापस पेस्ट करने की प्रक्रिया से ले जाता है।

2

Authenticate with Snowflake (User OAuth) — एडमिन यह सत्यापित करने के लिए एक बार प्रमाणीकरण करता है कि इंटीग्रेशन एंड-टू-एंड काम करता है।

3

Generate a data map (वैकल्पिक) — संगठन के लिए वैकल्पिक रूप से एक डेटा मैप जनरेट करें (Data Map को समझना देखें) और सटीकता में सुधार के लिए पूरक संदर्भ जोड़ें।

Step 1 में, Snowflake पक्ष पर सुरक्षा इंटीग्रेशन बनाएँ। इसे ACCOUNTADMIN के रूप में चलाएँ:

USE ROLE ACCOUNTADMIN;
CREATE SECURITY INTEGRATION PERPLEXITY_OAUTH
  TYPE = OAUTH
  ENABLED = TRUE
  OAUTH_CLIENT = CUSTOM
  OAUTH_CLIENT_TYPE = ‘CONFIDENTIAL’
  OAUTH_REDIRECT_URI = ‘https://ah.merge.dev/oauth/callback’
  OAUTH_ISSUE_REFRESH_TOKENS = TRUE
  OAUTH_REFRESH_TOKEN_VALIDITY = 7776000
  OAUTH_USE_SECONDARY_ROLES = IMPLICIT
  COMMENT = ‘OAuth security integration for Perplexity’;

Perplexity में वापस पेस्ट करने के लिए Client ID और Client Secret प्राप्त करें:

SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS(‘PERPLEXITY_OAUTH’);

एडमिन सेटअप पूरा होने के बाद, व्यक्तिगत उपयोगकर्ता नीचे दिए गए चरणों का उपयोग करके कनेक्ट कर सकते हैं।

​
कनेक्ट करें (सभी उपयोगकर्ता)

उपयोगकर्ताओं को केवल वही प्रमाणीकरण विधि दिखाई देती है जो उनके एडमिन द्वारा कॉन्फ़िगर किए गए कनेक्टर से मेल खाती है।

1

Settings में Connectors पर जाएँ और Snowflake या Snowflake (User OAuth) कनेक्टर ढूँढें।

2

Enable → Add Connector पर क्लिक करें।

3

अपनी कॉन्फ़िगर की गई विधि का उपयोग करके प्रमाणीकरण करें (नीचे देखें)।

4

सेटअप पूरा करने के लिए Allow पर क्लिक करें।

Key-pair प्रमाणीकरण (Snowflake कनेक्टर)। अपना Snowflake अकाउंट पहचानकर्ता, उपयोगकर्ता नाम, और निजी कुंजी (snowflake_computer_key.p8) दर्ज करें।

OAuth (Snowflake (User OAuth) कनेक्टर)। साइन इन करने के लिए आपको Snowflake पर रीडायरेक्ट किया जाएगा। कोई रोल चयनकर्ता नहीं है — आपका सत्र आपके DEFAULT_ROLE को प्राथमिक रोल के रूप में उपयोग करता है, और OAUTH_USE_SECONDARY_ROLES = IMPLICIT के माध्यम से आपके DEFAULT_SECONDARY_ROLES सक्रिय होते हैं। यदि आपकी रोल डिफ़ॉल्ट्स पहले से कॉन्फ़िगर हैं, तो किसी कार्रवाई की आवश्यकता नहीं है।

यदि आपके सत्र में वह डेटा नहीं दिख रहा जिसकी आप अपेक्षा करते हैं, तो अपने Snowflake एडमिन से अपने DEFAULT_ROLE और DEFAULT_SECONDARY_ROLES सत्यापित करने के लिए कहें (User OAuth रोल कॉन्फ़िगरेशन देखें)।

​
अपने Snowflake डेटा का उपयोग करना

एक बार कनेक्ट हो जाने पर, Computer कार्यों में अपने Snowflake डेटा का संदर्भ दें। डेटाबेसेज़, स्कीमाज़, या टेबल्स का उल्लेख करें और Perplexity उन्हें बहु-चरणीय वर्कफ़्लो के हिस्से के रूप में क्वेरी करेगा — सब कुछ एक सुरक्षित क्लाउड सैंडबॉक्स में अतुल्यकालिक रूप से। इस तरह की क्वेरीज़ आज़माएँ:

  • “Summarize the revenue trends from the Q4 sales table and highlight key metrics”

  • “Find all customer records updated in the last 30 days”

  • “What are the top-performing products based on the analytics schema?”

  • “Compare this quarter’s pipeline data against the previous quarter’s figures”

​
समस्या निवारण

​
आपके संगठन के लिए Snowflake सक्षम नहीं है

यदि आप किसी Enterprise संगठन में हैं और कनेक्टर सक्षम नहीं कर पा रहे हैं, तो हो सकता है किसी एडमिन ने उसे अक्षम किया हो। अपने संगठन एडमिन से संपर्क करें, या Perplexity सहायता से संपर्क करें।

​
कनेक्शन और प्रमाणीकरण समस्याएँ

  • सत्यापित करें कि Perplexity के IP पते आपकी Snowflake नेटवर्क नीति में अनुमति सूची में हैं।

  • पुष्टि करें कि रोल के पास आवश्यक वेयरहाउसेज़, डेटाबेसेज़, और स्कीमाज़ पर USAGE विशेषाधिकार हैं।

  • किसी भी नीति परिवर्तन के बाद उपयोगकर्ताओं से कनेक्टर को फिर से कनेक्ट करने के लिए कहें।

​
“Invalid private key” त्रुटि

सुनिश्चित करें कि आप निजी कुंजी (snowflake_computer_key.p8) पेस्ट कर रहे हैं, सार्वजनिक कुंजी नहीं। फ़ाइल -----BEGIN PRIVATE KEY----- से शुरू होनी चाहिए।

​
वर्तमान प्रमाणीकरण नीति द्वारा प्रमाणीकरण अस्वीकृत

ACCOUNTADMIN के रूप में SHOW AUTHENTICATION POLICIES चलाएँ और सुनिश्चित करें कि PERPLEXITY_USER ऐसी नीति के अंतर्गत आता है जिसमें KEYPAIR शामिल है। यदि आवश्यक हो:

CREATE AUTHENTICATION POLICY PERPLEXITY_AUTH_POLICY
  AUTHENTICATION_METHODS = (‘KEYPAIR’)
  CLIENT_TYPES = (‘DRIVERS’);
ALTER USER PERPLEXITY_USER SET AUTHENTICATION POLICY PERPLEXITY_AUTH_POLICY;

​
OAuth: कनेक्ट करने के बाद उपयोगकर्ता को सीमित डेटा दिखता है

OAuth सत्र उपयोगकर्ता के DEFAULT_ROLE को प्राथमिक रोल के रूप में उपयोग करता है, और OAUTH_USE_SECONDARY_ROLES = IMPLICIT के माध्यम से द्वितीयक रोल्स सक्रिय होती हैं। यदि किसी उपयोगकर्ता को अपेक्षित एक्सेस नहीं मिल रहा है:

  • पुष्टि करें कि सुरक्षा इंटीग्रेशन में OAUTH_USE_SECONDARY_ROLES = IMPLICIT सेट है।

  • DESC USER <username> चलाएँ और DEFAULT_ROLE और DEFAULT_SECONDARY_ROLES जाँचें — सत्र ठीक वही उपयोग करता है जो वहाँ कॉन्फ़िगर है।

  • यदि उपयोगकर्ता के पास कोई प्रति-उपयोगकर्ता रोल कॉन्फ़िगरेशन नहीं है और आप चाहते हैं कि उन्हें दी गई हर चीज़ तक एक्सेस मिले, तो DEFAULT_ROLE = PUBLIC और DEFAULT_SECONDARY_ROLES = (‘ALL’) सेट करें।

  • इनमें से कोई भी सेटिंग बदलने के बाद नया टोकन जारी करने के लिए उनसे कनेक्टर को डिस्कनेक्ट और फिर से कनेक्ट करवाएँ।

​
ACCESS_HISTORY व्यू त्रुटि लौटाता है

पुष्टि करें कि आपका Snowflake अकाउंट Enterprise Edition या उच्चतर है।

​
ACCOUNT_USAGE व्यूज़ पर अपर्याप्त विशेषाधिकार

सत्यापित करें कि GRANT IMPORTED PRIVILEGES को ACCOUNTADMIN के रूप में चलाया गया था और PERPLEXITY_ROLE उपयोगकर्ता को दी गई है।

​
Key-pair प्रमाणीकरण विफल होता है

यह पुष्टि करने के लिए कि सार्वजनिक कुंजी फ़िंगरप्रिंट भरा हुआ है, DESC USER PERPLEXITY_USER फिर से चलाएँ।

यदि इन सेटिंग्स को अपडेट करने के बाद भी समस्याएँ बनी रहती हैं, तो सहायता के लिए Perplexity सहायता से संपर्क करें।

अंतिम संशोधन 4 सितंबर 2026

संबंधित विषय

कनेक्टर और इंटीग्रेशनConfluence के साथ Perplexity कनेक्ट करनाJira के साथ Perplexity कनेक्ट करनाLinear के साथ Perplexity को कनेक्ट करनाPerplexity को Databricks से कनेक्ट करना