GET/api/public/legal/:slug

একটি একক আইনি পাঠ্য HTML হিসাবে সরবরাহ করে।

পেজটি „GET /api/public/legal/:slug — API-Referenz" URL-এ নির্দেশিত ফাংশনাল এলাকা নিয়ে আলোচনা করে। বিদ্যমান বিষয়বস্তু প্রকৃত প্রক্রিয়া, পূর্বশর্ত এবং পরিচিত সীমাবদ্ধতা দিয়ে সম্পূরক করা হয়। Zentor-এর কোনো ডেভেলপার API-কি সিস্টেম নেই। ড্যাশবোর্ডের জন্য বারো ঘণ্টা মেয়াদের সেশন-JWT এবং সাত দিনের মেয়াদের রিফ্রেশ-টোকেন ব্যবহার করা হয়; TOTP এবং SSO ঐচ্ছিক। উইজেট-এমবেড-টোকেন একবার প্লেইনটেক্সটে দেখানো হয় এবং অনুমোদিত Origins-এর সাথে আবদ্ধ থাকে। `GET /api/public/legal/:slug`-এর ডকুমেন্টেশন এই নির্দিষ্ট এন্ডপয়েন্টের একটি বাধ্যতামূলক প্রযুক্তিগত বিবরণ হিসেবে পড়া উচিত। গুরুত্বপূর্ণ হল মেথড, পাথ, অথেনটিকেশন, বাধ্যতামূলক ফিল্ড, সম্ভাব্য ত্রুটি এবং প্রশ্ন যে পুনরায় কল করলে একই প্রভাব সৃষ্টি হয় কিনা। এই সহায়তা বিভাগ https://zentor-app.de/hilfe/api-referenz/oeffentliche-inhalte/content.legal_by_slug তাই কোনো সাধারণ বিজ্ঞাপনমূলক বক্তব্য ধারণ করবে না, বরং শুধুমাত্র অনুসরণযোগ্য ইন্টিগ্রেশন ধাপ এবং প্রমাণিত উত্তর উদাহরণ থাকবে। `/api/public/legal/:slug` কল করার জন্য রিকোয়েস্টটি রেজিস্ট্রি অনুযায়ী তৈরি করা হয়। পাবলিক রুটগুলির কোনো সাধারণ ডেভেলপার API-কি প্রয়োজন হয় না, কারণ Zentor এমন কোনো কি সিস্টেম অফার করে না। অন্যদিকে সুরক্ষিত উইজেট-রুটগুলি একবার দেখানো এমবেড-টোকেন এবং একটি Origin-যাচাই ব্যবহার করে। HTTP-স্ট্যাটাস এবং JSON-কনটেন্ট একসাথে মূল্যায়ন করতে হবে; একটি `ok`-ফিল্ড একা ত্রুটি-হ্যান্ডলিং প্রতিস্থাপন করে না। `GET /api/public/legal/:slug` পরীক্ষার সময় বেনামী মান ব্যবহার করতে হবে। প্রকৃত গ্রাহক ডেটা, প্রোডাক্টিভ UUID, সেশন-টোকেন এবং নির্দিষ্ট টাইমস্ট্যাম্প পাবলিক উদাহরণে থাকা উচিত নয়। পরিচিত প্ল্যাটফর্ম-ব্যাপী সীমা হল ১৫ মিনিটের মধ্যে ২,০০০ রিকোয়েস্ট; কোনো ভিন্ন পৃথক সীমা প্রমাণিত নয়। নন-আইডেমপোটেন্ট POST কল অস্পষ্ট নেটওয়ার্ক বিচ্ছেদের পরে অন্ধভাবে পুনরাবৃত্তি করা উচিত নয়। এই রুটের জন্য সাধারণ ইন্টিগ্রেশন ত্রুটিগুলি বাধ্যতামূলক প্যারামিটারের অভাব, ভুল ডেটা টাইপ, মেয়াদোত্তীর্ণ ওয়ান-টাইম কোড, অননুমোদিত Origins বা একটি অ-বাস্তবায়িত ডেটাসেটের কারণে ঘটে। অ্যাপ্লিকেশনটির এই ধরনের ক্ষেত্রেগুলি আলাদাভাবে পরিচালনা করা উচিত এবং এন্ডপয়েন্ট থেকে ফেরত আসা ত্রুটি বার্তা লগ করা উচিত, গোপন বিষয়বস্তু লিখে না রেখে। একটি সফল রিকোয়েস্ট শুধুমাত্র এই প্রসেসিং ধাপটি নিশ্চিত করে, পরবর্তীতে সংযুক্ত কোনো ইমেল, পেমেন্ট বা SSO সাফল্য স্বয়ংক্রিয়ভাবে নিশ্চিত করে না। এটি „GET /api/public/legal/:slug"-এর জন্য সরাসরি প্রাসঙ্গিক। এই পেজের প্রযুক্তিগত যাচাই বাধ্যতামূলকভাবে `app/frontend/src/content/api-reference/`-এর অধীনে রেজিস্ট্রি এবং সংশ্লিষ্ট ব্যাকএন্ড রুটগুলির উপর ভিত্তি করে হতে হবে। লাইভ-টেস্ট নোট শুধুমাত্র সেই বিষয়টি দাবি করতে পারে যা প্রকৃতপক্ষে পরীক্ষা করা হয়েছে। একটি নেগেটিভ টেস্ট বা কোড-অ্যানালজি সম্পূর্ণ সাফল্যের প্রমাণ নয়। GET /api/public/legal/:slug — API-Referenz-এর জন্য তাই নথিভুক্ত কাঠামো, স্বয়ংক্রিয় পরীক্ষা এবং নিরাপদে পর্যবেক্ষণ করা লাইভ আচরণের মধ্যে স্পষ্টভাবে পার্থক্য করা প্রয়োজন।

{"ok":true,"data":{"body_html":"<h2>§ 5 DDG অনুযায়ী তথ্য</h2>...","updated_at":"2026-07-19T...","version":5}}