GET/api/public/legal/:slug

یک متن حقوقی واحد را به صورت HTML ارائه میدهد.

این صفحه با عنوان "GET /api/public/legal/:slug — مرجع API" به بخش عملکردی مشخص شده در URL اشاره دارد. محتوای موجود با جزئیات مربوط به جریان کار، پیش‌نیازها و محدودیت‌های شناخته شده تکمیل شده است. Zentor سیستم کلید API برای توسعه‌دهندگان ندارد. برای داشبورد، از توکن‌های Session-JWT با طول عمر ۱۲ ساعت و توکن‌های Refresh با طول عمر ۷ روز استفاده می‌شود؛ TOTP و SSO اختیاری هستند. توکن‌های Embed برای ویجت‌ها یک‌بار به صورت متن ساده نمایش داده می‌شوند و به دامنه‌های مجاز محدود می‌شوند. مستندات مربوط به `GET /api/public/legal/:slug` باید به عنوان یک توصیف فنی دقیق از این نقطه پایانی خاص در نظر گرفته شود. مواردی که در آن مهم هستند شامل روش، مسیر، احراز هویت، فیلدهای اجباری، خطاهای احتمالی و این است که آیا فراخوانی مجدد همان اثر را ایجاد می‌کند یا خیر. این بخش راهنما با آدرس https://zentor-app.de/hilfe/api-referenz/oeffentliche-inhalte/content.legal_by_slug نباید شامل اظهارات تبلیغاتی کلی باشد، بلکه فقط باید شامل مراحل یکپارچه‌سازی قابل اجرا و نمونه‌های پاسخ معتبر باشد. برای فراخوانی `/api/public/legal/:slug`، درخواست مطابق با رجیستری ایجاد می‌شود. مسیرهای عمومی نیازی به کلید API عمومی برای توسعه‌دهندگان ندارند، زیرا Zentor چنین سیستمی را ارائه نمی‌دهد. در مقابل، مسیرهای ویجت محافظت‌شده از توکن Embed که یک‌بار نمایش داده می‌شود و همچنین بررسی دامنه استفاده می‌کنند. وضعیت HTTP و محتوای JSON باید به طور مشترک ارزیابی شوند؛ یک فیلد `ok` به تنهایی جایگزین مدیریت خطا نیست. هنگام آزمایش `GET /api/public/legal/:slug`، باید از مقادیر ناشناس استفاده شود. داده‌های واقعی مشتری، UUIDهای فعال، توکن‌های نشست و مهر زمانی‌های خاص نباید در نمونه‌های عمومی قرار گیرند. محدودیت کلی پلتفرم شناخته شده ۲,۰۰۰ درخواست در ۱۵ دقیقه است؛ محدودیت انفرادی متفاوتی مشخص نشده است. درخواست‌های POST غیر-ایدم‌پوت نباید پس از قطع ارتباط شبکه نامشخص، به طور کورکورانه تکرار شوند. خطاهای یکپارچه‌سازی معمول برای این مسیر ناشی از پارامترهای اجباری از دست رفته، انواع داده‌های نادرست، کدهای یک‌بار مصرف منقضی شده، دامنه‌های غیرمجاز یا عدم وجود مجموعه داده پیاده‌سازی شده است. برنامه باید این موارد را به طور جداگانه مدیریت کند و پیام خطایی را که از نقطه پایانی برگردانده می‌شود، ثبت کند، بدون اینکه محتوای حساس را ثبت کند. یک درخواست موفق فقط این مرحله پردازش را تأیید می‌کند، نه به طور خودکار موفقیت یک عملیات بعدی مانند ایمیل، پرداخت یا SSO. این موضوع برای "GET /api/public/legal/:slug" کاملاً مرتبط است. بررسی فنی این صفحه باید به طور اجباری بر اساس رجیستری موجود در `app/frontend/src/content/api-reference/` و مسیرهای بک‌اند مربوطه باشد. یادداشت‌های تست زنده فقط باید ادعاهایی را مطرح کنند که واقعاً بررسی شده‌اند. یک تست منفی یا یک آنالیز کد، مدرک کاملی از موفقیت نیست. بنابراین، برای GET /api/public/legal/:slug — مرجع API، باید تمایز واضحی بین ساختار مستند شده، تست خودکار و رفتار زنده قابل مشاهده وجود داشته باشد.

{"ok":true,"data":{"body_html":"<h2>اطلاعات مطابق با § 5 DDG</h2>...","updated_at":"2026-07-19T...","version":5}}