GET/api/public/legal
সকল পাবলিক আইনি পাঠ্য (Impressum, Datenschutz, AGB) সংগ্রহ করে সরবরাহ করে।
„GET /api/public/legal — API-Referenz" পৃষ্ঠাটি URL-এ নির্দেশিত কার্যক্ষেত্রটি নিয়ে আলোচনা করে। বিদ্যমান বিষয়বস্তু প্রকৃত প্রক্রিয়া, পূর্বশর্ত এবং পরিচিত সীমাবদ্ধতা দিয়ে সম্পূরক করা হয়েছে। Zentor-এর কোনো ডেভেলপার API-কি সিস্টেম নেই। ড্যাশবোর্ডের জন্য বারো ঘণ্টা মেয়াদের Session-JWT এবং সাত দিনের মেয়াদের Refresh-Token ব্যবহার করা হয়; TOTP এবং SSO ঐচ্ছিক। Widget-Embed-Token একবারের জন্য প্লেইন টেক্সটে দেখানো হয় এবং অনুমোদিত Origins-এর সাথে আবদ্ধ থাকে। `GET /api/public/legal`-এর ডকুমেন্টেশনকে এই নির্দিষ্ট এন্ডপয়েন্টের বাধ্যতামূলক প্রযুক্তিগত বিবরণ হিসেবে পড়তে হবে। পদ্ধতি, পাথ, প্রমাণীকরণ, বাধ্যতামূলক ক্ষেত্র, সম্ভাব্য ত্রুটি এবং পুনরায় কল করলে একই প্রভাব সৃষ্টি হয় কিনা — এই বিষয়গুলো গুরুত্বপূর্ণ। https://zentor-app.de/hilfe/api-referenz/oeffentliche-inhalte/content.legal_list এই সহায়তা বিভাগে তাই কোনো সাধারণ বিজ্ঞাপনমূলক বিবৃতি থাকা উচিত নয়, বরং শুধুমাত্র অনুসরণযোগ্য ইন্টিগ্রেশন ধাপ এবং প্রমাণিত উত্তর উদাহরণ থাকা উচিত। `/api/public/legal` কল করার জন্য রেজিস্ট্রি অনুযায়ী অনুরোধ তৈরি করা হয়। পাবলিক রুটগুলোর জন্য সাধারণ ডেভেলপার API-কি প্রয়োজন হয় না, কারণ Zentor এমন কোনো কী সিস্টেম অফার করে না। অন্যদিকে সুরক্ষিত Widget-রুটগুলো একবার দেখানো Embed-Token এবং Origin-যাচাই ব্যবহার করে। HTTP-স্ট্যাটাস এবং JSON-বিষয়বস্তু একসাথে মূল্যায়ন করতে হবে; শুধুমাত্র একটি `ok`-ফিল্ড ত্রুটি-পরিচালনার বিকল্প নয়। `GET /api/public/legal` পরীক্ষার সময় বেনামী মান ব্যবহার করতে হবে। প্রকৃত গ্রাহক ডেটা, প্রোডাক্টিভ UUID, সেশন-টোকেন এবং নির্দিষ্ট টাইমস্ট্যাম্প পাবলিক উদাহরণে থাকা উচিত নয়। পরিচিত প্ল্যাটফর্ম-ব্যাপী সীমা হল ১৫ মিনিটের মধ্যে ২,০০০ অনুরোধ; ভিন্ন কোনো পৃথক সীমা প্রমাণিত নয়। নন-আইডেমপোটেন্ট POST-কল অস্পষ্ট নেটওয়ার্ক বিচ্ছিন্নতার পরে অন্ধভাবে পুনরাবৃত্তি করা উচিত নয়। এই রুটের জন্য সাধারণ ইন্টিগ্রেশন ত্রুটিগুলো ঘটে বাধ্যতামূলক প্যারামিটার অনুপস্থিত, ভুল ডেটা টাইপ, মেয়াদোত্তীর্ণ ওয়ান-টাইম কোড, অননুমোদিত Origin বা অ-বাস্তবায়িত ডেটাসেটের কারণে। অ্যাপ্লিকেশনের উচিত এই ধরনের ক্ষেত্রগুলো আলাদাভাবে পরিচালনা করা এবং এন্ডপয়েন্ট থেকে ফেরত আসা ত্রুটি বার্তা লগ করা, গোপন বিষয়বস্তু লিখে না রেখে। একটি সফল অনুরোধ শুধুমাত্র সেই প্রক্রিয়াকরণ ধাপটি নিশ্চিত করে, পরবর্তীতে সংযুক্ত ইমেল, পেমেন্ট বা SSO সাফল্য স্বয়ংক্রিয়ভাবে নিশ্চিত করে না। এটি „GET /api/public/legal"-এর জন্য সরাসরি প্রাসঙ্গিক। এই পৃষ্ঠার প্রযুক্তিগত যাচাই অবশ্যই `app/frontend/src/content/api-reference/`-এর অধীনে রেজিস্ট্রি এবং সংশ্লিষ্ট ব্যাকএন্ড-রুটের উপর ভিত্তি করে হতে হবে। লাইভ-টেস্ট নোট শুধুমাত্র সেই বিষয়গুলো দাবি করতে পারে যা প্রকৃতপক্ষে পরীক্ষা করা হয়েছে। একটি নেগেটিভ টেস্ট বা কোড-অ্যানালজি সম্পূর্ণ সাফল্যের প্রমাণ নয়। GET /api/public/legal — API-Referenz-এর জন্য তাই নথিভুক্ত কাঠামো, স্বয়ংক্রিয় পরীক্ষা এবং নিশ্চিতভাবে পর্যবেক্ষণ করা লাইভ আচরণের মধ্যে স্পষ্টভাবে পার্থক্য করতে হবে।
Auth & Absicherung
কোনো প্রমাণীকরণ প্রয়োজন নেই
Idempotent: Ja
Beispiel-Response
{"ok":true,"data":{"impressum":{"body_html":"...","updated_at":null,"version":0},"datenschutz":{"body_html":"...","updated_at":null,"version":0},"agb":{"body_html":"...","updated_at":null,"version":0}}}Live-Test-Nachweis
সাফল্য (200) লাইভ বনাম প্রোডাকশন যাচাই করা হয়েছে।