GET/api/public/legal

تمام متون حقوقی عمومی (مشخصات ناشر، حفاظت از دادهها، شرایط عمومی) را به صورت جمعآوریشده ارائه میدهد.

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

{"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}}}