सपोर्ट अनुरोध में क्या शामिल करें

हम आपकी समस्या को जितनी जल्दी पुन: प्रस्तुत कर सकें, उतनी जल्दी हम उसे ठीक कर सकते हैं। नीचे हर श्रेणी में वह विशिष्ट जानकारी दी गई है जो जाँच को तेज़ करती है और अनावश्यक आदान-प्रदान से बचाती है।

Roboflow सपोर्ट टीम समस्याओं को तेज़ी से हल करती है जब किसी अनुरोध में समस्या को पुन: उत्पन्न करने के लिए पर्याप्त विवरण शामिल होता है। नीचे अपनी स्थिति खोजें और संपर्क करने पर सूचीबद्ध जानकारी शामिल करें।

हमेशा क्या शामिल करें

समस्या के प्रकार की परवाह किए बिना, ये पाँच चीज़ें हर सपोर्ट केस को तेज़ करती हैं:

1. प्रोजेक्ट और वर्कस्पेस: वर्कस्पेस ID या प्रभावित प्रोजेक्ट या वर्कस्पेस का सीधा लिंक। (ईमेल से सबमिट करने पर आवश्यक; अन्यथा यह आमतौर पर हमारे पास स्वतः होता है.)

2. वर्कस्पेस एक्सेस: Roboflow सपोर्ट टीम को आपके वर्कस्पेस तक पहुँच प्रदान करें.

3. सटीक त्रुटि: मूल त्रुटि संदेश या रिस्पॉन्स बॉडी, पराफ़्रेज़ नहीं।

4. समय-सीमा: विशिष्ट UTC टाइमस्टैम्प, "कल" नहीं।

5. आपने क्या प्रयास किया: हर प्रयास और उसका परिणाम।

Inference API त्रुटियाँ

आपका प्रोडक्शन एप्लिकेशन serverless.roboflow.com से HTTP 4xx या 5xx प्रतिक्रियाएँ प्राप्त करना शुरू कर देता है। त्रुटि संदेशों में "Internal error," "Model is temporarily not ready - retry request," "Could not acquire model manager lock," या 30 सेकंड के बाद टाइमआउट शामिल हो सकते हैं। विफलता दर अचानक बढ़ जाती है, अक्सर समय की एक संकरी अवधि के भीतर।

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

सबसे ज़्यादा क्या मदद करता है:

• विफलताओं की सटीक समय-सीमा, जिसमें टाइमज़ोन या UTC ऑफ़सेट शामिल हो। ("2026-05-22 12:30–12:40 UTC" पर कार्रवाई करना "आज सुबह" की तुलना में बहुत आसान है।)

• पूरा inference endpoint URL (उदाहरण: https://serverless.roboflow.com/test-endpoint/11 के लिए Serverless Cloud APIया [e-mail] के लिए एक समर्पित डिप्लॉयमेंट).

• त्रुटि प्रतिक्रियाओं का एक स्क्रीनशॉट या लॉग एक्सपोर्ट, जिसमें HTTP स्टेटस कोड, रिस्पॉन्स बॉडी, और टाइमस्टैम्प दिखें। आपके एप्लिकेशन या मॉनिटरिंग डैशबोर्ड का एक स्क्रीनशॉट जिसमें यह घटना दिखे, आदर्श है।

• विंडो के दौरान अनुरोधों की अनुमानित मात्रा: कुल भेजे गए अनुरोध, कितने विफल हुए, और भेजने का पैटर्न (burst बनाम steady).

• क्या विफलताएँ अभी भी जारी हैं या हल हो चुकी हैं।

• क्या विफल अनुरोधों के लिए क्रेडिट्स खर्च हुए थे।

उदाहरण सबमिशन:

"हमें लगभग 90% विफलता दर दिखाई दी जब https://serverless.roboflow.com/test-endpoint/11 पर 2026-05-22 को 11:20 और 11:35 AM UTC के बीच अनुरोध भेजे जा रहे थे। उस समय हम लगभग 150 अनुरोध/घंटा भेज रहे थे। त्रुटियों ने HTTP 503 के साथ body {"message":"Internal error."} लौटाया। संलग्न है हमारे एप्लिकेशन लॉग का एक स्क्रीनशॉट। विफलता लगभग 11:40 AM पर स्वयं ठीक हो गई प्रतीत होती है। हमारा वर्कस्पेस id fleet-pulse है। क्या विफल अनुरोधों के लिए हमसे बिल किया गया था?"

Inference प्रदर्शन समस्याएँ

Inference सर्वर सही ढंग से चलता है, लेकिन अपेक्षा से अधिक मेमोरी उपयोग करता है, समय के साथ बढ़ता है, लोड के तहत धीमा हो जाता है, या आपके उपयोग-केस के लिए अस्वीकार्य रूप से उच्च latency पैदा करता है। सामान्य रूपांतरों में Jetson डिवाइस पर घंटों के दौरान मेमोरी का अनियंत्रित बढ़ना, बड़े मॉडल का पहले अनुरोध पर लोड होने में बहुत समय लगना, या parallel batch requests के तहत throughput का कम होना शामिल है।

मेमोरी और latency मॉडल आर्किटेक्चर, batch size, concurrency सेटिंग्स, image dimensions, hardware, और inference server version पर निर्भर करती हैं। लगभग हर variable मायने रखता है।

सबसे ज़्यादा क्या मदद करता है:

• Inference server version: सटीक Docker image tag (उदाहरण: roboflow/roboflow-inference-server-jetson-5.1.1:1.2.6).

• Hardware specs: GPU model, कुल RAM, और क्या आप Jetson पर हैं तथा कौन सा JetPack version है।

• लोड किए गए हर मॉडल के model IDs और types (उदाहरण: object-detection-5gavt/16, YOLOv8-s, ViT 224×224), साथ ही क्या डिवाइस के लिए TRT packages मौजूद हैं।

• Client configuration: max_concurrent_requests, max_batch_size, और क्लाइंट साइड पर batches कैसे बनाए जाते हैं।

• समय के साथ memory या CPU usage का एक ग्राफ जो degradation pattern दिखाए (उदाहरण: से एक स्क्रीनशॉट jtop, htop, या लगभग एक घंटे की मेमोरी दिखाने वाला monitoring tool).

• सामान्य image size KB में, या यदि ज्ञात हो तो सटीक pixel dimensions।

• उपयोग में लिए गए environment variable overrides (उदाहरण: USE_INFERENCE_MODELS=True/False).

• पहले आज़माए गए कदम, जिनमें version rollbacks और flag changes शामिल हैं, और प्रत्येक का प्रभाव।

उदाहरण सबमिशन:

"हम NVIDIA Jetson AGX Orin (JetPack 5.1.1) पर roboflow/roboflow-inference-server-jetson-5.1.1:1.2.6 चला रहे हैं। हम एक साथ 7 मॉडल लोड करते हैं: 2 YOLOv8-s object detection और 5 ViT classification models। लगभग 2 घंटे के production load (max_concurrent_requests=10, max_batch_size=100, image size ~50KB) के बाद memory 8GB से ~15GB तक बढ़ जाती है। संलग्न है एक jtop graph। हमने USE_INFERENCE_MODELS=False सेट करने की कोशिश की, जिससे memory लगभग आधी हुई लेकिन accuracy भी घट गई।"

Serverless Workflow त्रुटियाँ

एक Roboflow वर्कफ़्लो (Workflows UI या के माध्यम से एक्सेस किया गया serverless.roboflow.com/infer/workflows/...) त्रुटियाँ लौटाता है, टाइमआउट होता है, या अप्रत्याशित परिणाम देता है। त्रुटियाँ HTTP 500 "Internal error," 502 "Bad gateway," या ऐसी silent failures हो सकती हैं जहाँ jobs चलते हुए दिखते हैं लेकिन कोई डेटा नहीं लौटाते। यह सरल मॉडल inference failures से अलग है: इसमें आमतौर पर multi-step pipelines, custom Python blocks, या जटिल block chains शामिल होते हैं।

Workflows pipeline के किसी भी चरण पर विफल हो सकते हैं। यह जानना कि कौन सा block दोषी है, कितने अनुरोध भेजे गए और किस पैटर्न में, तथा workflow की सटीक परिभाषा, मूल कारण को सीमित करती है।

सबसे ज़्यादा क्या मदद करता है:

• पूरा workflow URL (उदाहरण: https://serverless.roboflow.com/infer/workflows/test/test-workflow).

• विफलताएँ कब हुईं, इसका विवरण, जिसमें टाइमस्टैम्प और प्रति समय-खंड अनुमानित अनुरोध संख्या शामिल हो।

• विफल अनुरोधों के लिए HTTP status codes और पूरी response bodies। केवल "500 Internal Error" की तुलना में पूरी response body कहीं कम उपयोगी होती है।

• क्या विफलताएँ कुल हैं (सभी अनुरोध विफल) या आंशिक (कुछ सफल)।

• Roboflow सपोर्ट टीम के लिए वर्कस्पेस एक्सेस, ताकि हम workflow definition और server-side logs की जाँच कर सकें।

• विफलताएँ शुरू होने से पहले workflow में हुए कोई हालिया बदलाव (नए blocks जोड़े गए, models बदले गए, image inputs बदले गए)।

• batch jobs के लिए: batch job "Activity" सेक्शन से ID, अपेक्षित बनाम वास्तविक output record count, और job duration।

उदाहरण सबमिशन:

"हमारा workflow at https://serverless.roboflow.com/infer/workflows/my-workspace/classifier-pipeline ने 2026-05-25 को 12:33 और 12:40 UTC के बीच 195 अनुरोधों में से 170 HTTP 500 प्रतिक्रियाएँ लौटाईं। अनुरोध लगभग 15-15 के bursts में आए। सभी विफलताओं के लिए response body {"message":"Internal error."} थी। workflow लगभग 10 मिनट बाद अपने आप ठीक हो गया। हमने हाल ही में workflow नहीं बदला है। मैंने [e-mail] को workspace access दे दिया है।"

मॉडल प्रशिक्षण समस्याएँ

ए training job पूरी तरह विफल हो जाता है, अटक जाता है, बिना विवरण के एक सामान्य error popup दिखाता है, trained model बनाए बिना credits खर्च करता है, या training के बाद मॉडल अप्रत्याशित व्यवहार करता है (उदाहरण: max detections अपेक्षा से कम हैं, या बड़े dataset पर training version generation के दौरान hang हो जाती है)।

Training failures dataset की विशेषताओं (corrupt images, label format problems, class imbalances), resource constraints, या platform bugs से हो सकते हैं। सपोर्ट टीम को आपके विशिष्ट project और dataset को देखना होगा।

सबसे ज़्यादा क्या मदद करता है:

• आपने जिस model type और size को train करने की कोशिश की (उदाहरण: RF-DETR Nano, YOLOv8-L, SAM3).

• model का नाम या प्रभावित model का सीधा लिंक (उदाहरण: app.roboflow.com/my-workspace/my-project/models/my-model).

• training के लिए उपयोग किया गया dataset version number।

• त्रुटि संदेश शब्दशः, पराफ़्रेज़ करने के बजाय पूरा कॉपी-पेस्ट किया हुआ। यदि यह popup में दिखाई देता है, तो उसका screenshot लें।

• यदि UI में दिखाई दे रहा हो तो training job ID।

• क्या विफल प्रयास के लिए credits चार्ज किए गए थे।

• dataset version में images और classes की संख्या।

• विफलता से पहले dataset में हुए कोई हालिया बदलाव (नई images जोड़ी गईं, class names बदले गए, preprocessing settings बदली गईं)।

• foundation model fine-tuning के लिए (उदाहरण: SAM): dataset size, उपयोग किया गया prompt type, और प्रक्रिया के किस चरण में यह क्रैश हुआ।

उदाहरण सबमिशन:

"workspace baz-co में project foo-bar के dataset version 3 पर model YOLOv8-L के लिए training job हर बार एक सामान्य popup error के साथ विफल हो जाता है, आगे कोई विवरण नहीं दिखता। dataset में 12 classes के across ~2,400 images हैं। मुझे दो विफल प्रयासों के लिए credits चार्ज किए गए हैं। यहाँ error popup का screenshot है। Workspace access support को दे दिया गया है।"

डेटासेट और इमेज दृश्यता समस्याएँ

अपलोड की गई images dataset view में दिखाई नहीं देतीं (header count वास्तव में browsing करते समय दिखाई देने वाली संख्या से अलग होता है), labeling के बाद dataset में जोड़ी गई images गायब हो जाती हैं, dataset version preparation अनिश्चितकाल तक अटक जाती है, या batch ZIP upload सफल दिखता है लेकिन images accessible नहीं होतीं।

इन समस्याओं के लिए अक्सर backend log inspection की आवश्यकता होती है। सपोर्ट टीम को एक सटीक project identifier और आदर्श रूप से विशिष्ट upload event का रिकॉर्ड चाहिए।

सबसे ज़्यादा क्या मदद करता है:

• संख्याओं में अंतर: प्लेटफ़ॉर्म कितनी images दिखाता है बनाम dataset tab ब्राउज़ करते समय वास्तव में कितनी दिखाई देती हैं (उदाहरण: "Header says 1,004 images but only 368 show when browsing").

• जब upload हुआ था, जो platform events के साथ संबंध जोड़ने में मदद करता है।

• उपयोग की गई upload विधि: ब्राउज़र में drag-and-drop, Python SDK, REST API, ZIP upload, या mobile app।

• batch या ZIP uploads के लिए: उपलब्ध हो तो "Activity" सेक्शन से batch job ID।

• अंतर दिखाने वाला screenshot (header count बनाम browse view).

उदाहरण सबमिशन:

"workspace abc_def में मेरा project foo_bar_2 project header में 1,004 images दिखाता है लेकिन dataset tab पर क्लिक करने पर केवल 368 दिखाई देती हैं। मैंने images को 2026-05-25 को लगभग 9 AM EST पर drag-and-drop से upload किया था। Workspace access दे दिया गया है। Screenshot संलग्न है।"

Roboflow App UI त्रुटियाँ

annotation editor के बाहर Roboflow web app में कुछ अपेक्षा के अनुसार काम नहीं कर रहा: pages लोड नहीं होतीं या spinner पर अटकी रहती हैं, dataset version delete करने जैसी actions पूरी होती हुई दिखती हैं लेकिन कोई प्रभाव नहीं होता, settings panels नहीं खुलते, uploads activity queue में अटक जाते हैं, usage dashboard render नहीं होता, या buttons कोई प्रतिक्रिया नहीं देते।

UI bugs अक्सर पीछे चल रहे किसी failing या slow network request, या किसी JavaScript error के कारण होते हैं, जिसे visible interface सीधे नहीं दिखाता। ब्राउज़र के developer tools बताते हैं कि network और JavaScript स्तर पर क्या गलत हो रहा है।

सबसे ज़्यादा क्या मदद करता है:

• बग को दिखाने वाली screen recording (Loom, video, या GIF). इन मामलों के लिए यह सबसे मूल्यवान artifact है।

• ब्राउज़र network request log का screenshot, जो दिखाता है कि कोई requests विफल हो रही हैं या लंबे समय तक चल रही हैं। देखें Chrome की network panel documentation इसे कैसे खोलें; अन्य browsers में भी समान tools होते हैं।

• ब्राउज़र console log में कोई errors। देखें Chrome की console documentation इसे कैसे access करें; अन्य browsers में भी समान tools होते हैं।

• आपका browser name और version (उदाहरण: macOS 14.4 पर Chrome 124).

• चरण-दर-चरण reproduction steps: आपने क्या क्लिक किया, किस क्रम में, एक fresh page load से शुरू करके।

• क्या bug हाल ही में दिखाई दिया, और क्या यह आपके द्वारा देखे गए किसी platform update के साथ मेल खाता है।

• सटीक अपेक्षित व्यवहार बनाम वास्तविक व्यवहार।

• क्या समस्या लगातार होती है या बीच-बीच में।

उदाहरण सबमिशन:

"project के dataset tab में test-project (workspace test-workspace), version 3 पर 'Delete version' क्लिक करने पर success toast दिखता है लेकिन version सूची में बना रहता है। network log screenshot में एक DELETE request का लौटना दिखाई देता है 500 Internal Server Error. console दिखाता है Uncaught TypeError: Cannot read properties of undefined. Browser: Ubuntu 22.04 पर Firefox 126. normal और private दोनों windows में reproduces होता है। screen recording संलग्न है।"

Annotation टूल बग्स

Roboflow annotation editor में कोई tool गलत व्यवहार करता है: keyboard shortcuts काम करना बंद कर देते हैं, एक tool चुनने पर दूसरा सक्रिय हो जाता है, undo (Ctrl+Z) अपेक्षा से अधिक delete कर देता है, Label Assist अनिश्चितकाल तक लोड होता रहता है, या annotations वैसे save नहीं होते जैसे होना चाहिए।

Annotation bugs अक्सर browser-specific, OS-specific, या हालिया platform deployments के कारण होते हैं। एक screen recording लगभग हमेशा लिखित विवरण से अधिक उपयोगी होती है।

सबसे ज़्यादा क्या मदद करता है:

• बग को दिखाने वाली screen recording (Loom, video, या GIF). Annotation व्यवहार को शब्दों में बताना कठिन और दिखाना आसान होता है, इसलिए इन मामलों के लिए यह सबसे मूल्यवान artifact है।

• ब्राउज़र network request log का screenshot, जो दिखाता है कि कोई requests विफल हो रही हैं या लंबे समय तक चल रही हैं। देखें Chrome की network panel documentation इसे कैसे खोलें; अन्य browsers में भी समान tools होते हैं।

• ब्राउज़र console log में कोई errors। देखें Chrome की console documentation इसे कैसे access करें; अन्य browsers में भी समान tools होते हैं।

• आपका browser name और version (उदाहरण: macOS 14.4 पर Chrome 124).

• project type (Object Detection, Instance Segmentation, Classification, आदि) और उपयोग में लिया जा रहा विशिष्ट annotation tool (polygon, polyline, bounding box, smart polygon).

• वह keyboard shortcut या action जो बग को ट्रिगर करता है, साथ में चरण-दर-चरण reproduction steps.

• क्या समस्या सभी images को प्रभावित करती है या केवल कुछ को। यदि विशेष, तो project link और image name या ID साझा करें।

• क्या bug हाल ही में दिखाई दिया, और क्या यह आपके द्वारा देखे गए किसी platform update के साथ मेल खाता है।

• सटीक अपेक्षित व्यवहार बनाम वास्तव में क्या होता है।

• क्या समस्या लगातार होती है या बीच-बीच में।

उदाहरण सबमिशन:

"प्रोजेक्ट my-test-project और my-other-test-project (workspace test-workspace) में, polyline tool में हाल ही में तीन बग आए हैं: (1) polyline tool सक्रिय रहते हुए Ctrl+scroll से zoom करने पर bounding box tool पर स्विच हो जाता है; (2) Ctrl+Z अब केवल अंतिम point के बजाय पूरे annotation को delete कर देता है; (3) Esc दबाने पर अब annotation discard करने के बजाय उसे save कर देता है। यहाँ हर व्यवहार दिखाने वाली दो Loom recordings हैं: [link 1], [link 2]. Browser: Windows 11 पर Chrome 124."

API प्रमाणीकरण त्रुटियाँ

model inference endpoints, Roboflow Python SDK, या HTTP API पर API calls 403 Forbidden के साथ "Missing or insufficient permissions." जैसे संदेश लौटाती हैं। यह किसी plan को अपग्रेड करने के तुरंत बाद, private model तक पहुँचने की कोशिश में, या API key rotate होने के बाद हो सकता है।

403 errors गलत या expired API key, workspace-level key के बजाय project-level key (या इसके उलट) का उपयोग, ऐसे plan से model access करना जिसमें वह feature शामिल नहीं है, या plan upgrade के बाद permissions के propagate होने में देरी के कारण हो सकते हैं।

सबसे ज़्यादा क्या मदद करता है:

• पूरा error response: केवल status code नहीं, बल्कि पूरा HTTP status code और response body। SDK errors के लिए, पूरा Python traceback।

• कॉल किया जा रहा endpoint या SDK method (उदाहरण: serverless.roboflow.com/model-name/version, InferenceHTTPClient, CLIENT.infer()).

• model ID और version number।

• उपयोग में ली जा रही API key का प्रकार, workspace या project. स्वयं key साझा न करें, केवल प्रकार बताएँ।

• क्या key हाल ही में rotate की गई थी या plan हाल ही में बदला गया था।

• API call construct करने का तरीका दिखाने वाला एक redacted code snippet, जिसमें वास्तविक key को एक placeholder से बदला गया हो जैसे YOUR_API_KEY.

• क्या यह पहले काम करता था, और क्या बदला।

उदाहरण सबमिशन:

"जब कॉल कर रहा हूँ तो मुझे HTTPError: 403 Client Error: Forbidden मिल रहा है https://serverless.roboflow.com/test-endpoint/1?api_key=YOUR_API_KEY. मैं workspace-level API key का उपयोग कर रहा हूँ। यह तब शुरू हुआ जब मैंने कल Free Plan से Core में upgrade किया। model private है। यहाँ पूरा Python traceback है: [paste]. Workspace my-test-workspace है। Workspace access प्रदान कर दिया गया है।"

खाता पहुँच समस्याएँ

आप Roboflow में लॉग इन नहीं कर पा रहे: login page लगातार loading हो रहा है, Google SSO login ब्लॉक है, forgotten-password reset काम नहीं कर रहा, या connected Google account उपलब्ध न होने के कारण account locked है।

Access issues अक्सर उपयोग में लिए गए specific email या identity provider से जुड़ी होती हैं। ये Google की तरफ़ OAuth scope changes या browser/extension interference के कारण भी हो सकती हैं।

सबसे ज़्यादा क्या मदद करता है:

• जिस account तक आप पहुँचने की कोशिश कर रहे हैं, उससे जुड़ा email address।

• login method: email and password, Google SSO, या GitHub SSO.

• सटीक error message या व्यवहार: "page keeps loading," "invalid credentials," "account not found," या कोई विशिष्ट error code.

• error state का screenshot।

• browser name और version, और क्या आपने incognito/private window या किसी दूसरे browser की कोशिश की है।

• क्या यह एक नई समस्या है या हमेशा से ऐसा ही था (उदाहरण: नया बनाया गया account बनाम existing account जो काम करना बंद कर चुका है).

वर्कस्पेस और प्रोजेक्ट प्रबंधन समस्याएँ

आप नहीं कर सकते वर्कस्पेस delete करना या project (deletion button कुछ नहीं करता हुआ दिखता है या error लौटाता है), किसी workspace का गलती से गलत plan में upgrade होना, ownership transfer नहीं होना, billing failure के बाद projects का inaccessible हो जाना, image upload limit का पार हो जाना, या एक public project गलती से private data expose करना।

सबसे ज़्यादा क्या मदद करता है:

• वह specific action जो विफल हो रही है और देखा गया error message या व्यवहार।

• error state या अवांछित project state का screenshot।

• deletion issues के लिए: पुष्टि करें कि आपने workspace के भीतर सभी projects और images पहले ही delete कर दिए हैं, जो अक्सर एक सामान्य prerequisite होता है।

• accidental upgrades के लिए: upgraded workspace और intended workspace, दोनों के workspace IDs, और बदलाव का अनुमानित समय।

• image limit issues के लिए: वर्तमान में workspace में कितनी images हैं और दिखाया गया limit क्या है।

क्रेडिट और उपयोग संबंधी समस्याएँ

क्रेडिट अपेक्षा से तेज़ी से खत्म हो रहे हैं, failed training jobs या failed inference के लिए credits चार्ज किए जा रहे हैं, या usage dashboard लोड नहीं हो रहा।

सबसे ज़्यादा क्या मदद करता है:

• वह workspace name जहाँ credit issue हुआ।

• अप्रत्याशित credit consumption की अनुमानित तारीख और समय।

• किस operation ने credits खर्च किए: inference calls, training, या batch processing।

• क्या कोई ज्ञात platform incident consumption spike के साथ मेल खाता है, और क्या आपने उस समय errors देखे थे।

• consumption spike दिखाने वाला usage dashboard का screenshot।

डेटा गोपनीयता और खाता हटाना

अनुरोध खाता delete करने के और सभी संबंधित व्यक्तिगत डेटा (GDPR erasure requests), खाते को हटाने के बाद images का सार्वजनिक रूप से accessible रह जाना जैसी अधूरी data deletion, या public Universe से किसी specific project को हटाने के अनुरोध।

सबसे ज़्यादा क्या मदद करता है:

• हटाए जाने वाले account का email address।

• पुष्टि कि account deletion आगे बढ़ने से पहले account के भीतर सभी projects और workspaces पहले ही delete कर दिए गए हैं, जो आवश्यक है।

• GDPR requests के लिए: अनुरोध के कानूनी आधार का एक बयान और उस डेटा का विवरण जो आपके अनुसार अभी भी accessible है।

• किसी भी विशिष्ट public Universe resource का link जिसे हटाया जाना चाहिए, साथ में कारण का स्पष्टीकरण।

सुरक्षा समस्याएँ

एक API key गलती से expose हो गई (उदाहरण: public GitHub repo में commit कर दी गई या chat में साझा की गई), या किसी security researcher ने Roboflow platform में कोई vulnerability पाई।

यदि कोई key expose हो जाए, तो तुरंत अपने Roboflow workspace settings में उसे rotate करें। Rotation से compromised key अमान्य हो जाती है। फिर approximate exposure time के साथ support को सूचित करें ताकि हम किसी unauthorized use का audit कर सकें।

exposed keys के लिए, शामिल करें:

• पुष्टि कि key पहले ही rotate की जा चुकी है।

• लगभग तारीख और समय जब key expose हुई, और किस channel के माध्यम से।

• क्या exposure window के दौरान unauthorized API usage का कोई evidence है।

vulnerability reports के लिए, vulnerability का स्पष्ट विवरण, reproduction steps, और संभावित प्रभाव के साथ [e-mail] पर ईमेल करें।