GET/api/public/access-request/paypal/config
চেকআউট ফ্রন্টএন্ডের জন্য পাবলিক PayPal কনফিগারেশন (মোড, মুদ্রা) সরবরাহ করে।
পৃষ্ঠা „GET /api/public/access-request/paypal/config — API-Referenz“ URL-এ নির্দেশিত কার্যক্ষেত্রটি নিয়ে আলোচনা করে। বিদ্যমান বিষয়বস্তু প্রকৃত প্রক্রিয়া, পূর্বশর্ত এবং পরিচিত সীমাবদ্ধতা দিয়ে সম্পূরক করা হয়েছে। ফর্ম-বিল্ডার ট্রিগার-কীওয়ার্ড, ফিল্ড টাইপ এবং বাধ্যতামূলক ফিল্ড চিহ্নিতকরণ সহ স্বাধীনভাবে কনফিগারযোগ্য ফর্ম সমর্থন করে। ফাংশনটি E2E-পরীক্ষিত। `GET /api/public/access-request/paypal/config`-এর ডকুমেন্টেশনকে এই নির্দিষ্ট এন্ডপয়েন্টের প্রযুক্তিগত বিবরণ হিসেবে পড়তে হবে। পদ্ধতি, পাথ, প্রমাণীকরণ, বাধ্যতামূলক ফিল্ড, সম্ভাব্য ত্রুটি এবং প্রশ্ন যে পুনরায় কল একই প্রভাব সৃষ্টি করে কিনা — এগুলো গুরুত্বপূর্ণ। বর্তমান URL https://zentor-app.de/hilfe/api-referenz/formulare/forms.access_request_paypal_config তাই সাধারণ বিজ্ঞাপনমূলক বিবৃতি ধারণ করবে না, বরং শুধুমাত্র তাৎক্ষণিকভাবে সম্পাদনযোগ্য ইন্টিগ্রেশন ধাপ এবং প্রমাণিত প্রতিক্রিয়া উদাহরণ ধারণ করবে। `/api/public/access-request/paypal/config` কল করার জন্য, অনুরোধটি রেজিস্ট্রি অনুযায়ী তৈরি করা হয়। পাবলিক রুটগুলির জন্য সাধারণ ডেভেলপার API-কী প্রয়োজন হয় না, কারণ Zentor এমন কোনো কী সিস্টেম অফার করে না। অন্যদিকে সুরক্ষিত উইজেট রুটগুলি একবার দেখানো এমবেড-টোকেন এবং একটি অরিজিন-পরীক্ষা ব্যবহার করে। HTTP-স্ট্যাটাস এবং JSON-বিষয়বস্তু একসাথে মূল্যায়ন করতে হবে; একা একটি `ok`-ফিল্ড ত্রুটি-পরিচালনা প্রতিস্থাপন করে না। `GET /api/public/access-request/paypal/config` পরীক্ষা করার সময়, বেনামী মান ব্যবহার করতে হবে। প্রকৃত গ্রাহক ডেটা, প্রোডাক্টিভ UUID, সেশন টোকেন এবং নির্দিষ্ট টাইমস্ট্যাম্প পাবলিক উদাহরণে থাকা উচিত নয়। জ্ঞাত প্ল্যাটফর্ম-ব্যাপী সীমা হল 15 মিনিটের মধ্যে 2.000 অনুরোধ; একটি ভিন্ন পৃথক সীমা নথিভুক্ত নয়। অস্পষ্ট নেটওয়ার্ক বিঘ্নের পরে নন-আইডেমপোটেন্ট POST কল অন্ধভাবে পুনরাবৃত্তি করা উচিত নয়। এই রুটের জন্য সাধারণ ইন্টিগ্রেশন ত্রুটিগুলি হল: বাধ্যতামূলক প্যারামিটার অনুপস্থিত, ভুল ডেটা টাইপ, মেয়াদোত্তীর্ণ ওয়ান-টাইম কোড, অননুমোদিত অরিজিন, বা আগে থেকে বিদ্যমান নয় এমন রেকর্ড। অ্যাপ্লিকেশনটির উচিত এই ধরনের ক্ষেত্রেগুলি আলাদাভাবে পরিচালনা করা এবং এন্ডপয়েন্ট থেকে ফেরত আসা ত্রুটি বার্তা লগ করা, গোপন বিষয়বস্তু না লিখে। একটি সফল অনুরোধ শুধুমাত্র এই প্রক্রিয়াকরণ ধাপটি নিশ্চিত করে, স্বয়ংক্রিয়ভাবে পরবর্তী ইমেল, পেমেন্ট বা SSO সাফল্য নয়। এই পৃষ্ঠার প্রযুক্তিগত পরীক্ষা বাধ্যতামূলকভাবে `app/frontend/src/content/api-reference/`-এর অধীনে থাকা রেজিস্ট্রি এবং সংশ্লিষ্ট ব্যাকএন্ড রুটের উপর নির্ভর করবে। লাইভ-টেস্ট টীকাগুলি কেবলমাত্র সেই বিষয়গুলোই দাবি করতে পারবে যা প্রকৃতপক্ষে যাচাই করা হয়েছে। একটি নেগেটিভ টেস্ট বা কোড-সাদৃশ্য সম্পূর্ণ সাফল্যের প্রমাণ নয়। GET /api/public/access-request/paypal/config — API-রেফারেন্সের ক্ষেত্রে, তাই নথিভুক্ত কাঠামো, স্বয়ংক্রিয় পরীক্ষা এবং নিশ্চিতভাবে পর্যবেক্ষণকৃত লাইভ আচরণের মধ্যে স্পষ্ট পার্থক্য করা আবশ্যক।
Auth & Absicherung
কোনো প্রমাণীকরণ প্রয়োজন নেই
Idempotent: Ja
Beispiel-Response
{"ok":true,"data":{"enabled":false,"mode":"স্যান্ডবক্স","currency":"EUR"}}Live-Test-Nachweis
সাফল্য (200) লাইভ যাচাইকৃত।