ऐसा अकाउंटिंग API बनाना जो ऑडिट में खरा उतरे

कोई अकाउंटिंग API जो पेमेंट राइट पर 200 OK रिटर्न करता है, वह आपको लगभग कुछ नहीं बताता। इससे यह पुष्टि नहीं होती कि बही-खाते (ledger) में एंट्री दर्ज हो गई थी, कि एक्टर (actor) इसे करने के लिए अधिकृत था, कि राशि ने वैलिडेशन पास कर लिया था, या कि अधिकार प्राप्त किसी व्यक्ति ने इसे मंज़ूरी दी थी। नीदरलैंड्स के व्यवसायों के लिए, जहां कर प्राधिकरण (tax authority) यह अपेक्षा करता है कि रिकॉर्ड्स को रीकंस्ट्रक्ट किया जा सके और सात साल तक सुरक्षित रखा जाए, "अनुरोध सफल रहा" और "बही-खाते सही हैं" के बीच का यह अंतर ही वह जगह है जहां ऑडिट में गड़बड़ी होती है।

ऑडिट-तैयार होना एक ऑपरेशनल डिज़ाइन का लक्ष्य है, न कि कोई सर्टिफिकेट। इसका मतलब है कि API एक पूरी श्रृंखला (chain) को सुरक्षित रखता है: ऑथेंटिकेटेड एक्टर से लेकर अधिकृत कार्रवाई, वैलिडेटेड स्टेट चेंज, अप्रूवल, लेजर परिणाम और छेड़छाड़-रोधी साक्ष्य (tamper-evident evidence) तक। नीचे दी गई हर बात इस श्रृंखला को जानबूझकर बनाने के बारे में है, न कि यह मान लेने के बारे में कि ऑथेंटिकेशन और TLS से सब कवर हो जाता है।

किसी अकाउंटिंग API को "ऑडिट-तैयार" क्या बनाता है

किसी ट्रांजैक्शन को रीकंस्ट्रक्ट करने वाले ऑडिटर को सवालों के एक खास क्रम का जवाब देने की ज़रूरत होती है। इसकी शुरुआत किसने की? क्या उन्हें इसकी अनुमति थी? क्या बदलाव ने अकाउंटिंग वैलिडेशन पास किया? इसे किसने अप्रूव किया? लेजर में क्या रिकॉर्ड हुआ? क्या उस रिकॉर्ड को बिना किसी निशान छोड़े बाद में बदला जा सकता है?

यदि आपका API अपने खुद के लॉग्स और डेटा मॉडल से इन सभी छह सवालों के जवाब नहीं दे सकता, तो यह ऑडिट-तैयार नहीं है, चाहे कोड कितना भी साफ क्यों न दिखे। ज़्यादातर API पहले सवाल को अच्छी तरह संभालते हैं और बाकी को खराब तरीके से।

अंतर को पाटने वाले नियंत्रण कुछ समूहों में आते हैं: स्पष्ट अकाउंटिंग स्टेट, लेयर्ड ऑथराइज़ेशन, स्कोप्ड ऑथेंटिकेशन, आइडपोटेंट राइट्स (idempotent writes), सर्वर-साइड वैलिडेशन,职责 का विभाजन (segregation of duties), और छेड़छाड़-रोधी लॉगिंग। वे एक-दूसरे को मजबूत बनाते हैं। कमज़ोर ऑथराइज़ेशन एक मजबूत ऑडिट लॉग को कमज़ोर कर देता है, क्योंकि आप अब यह भरोसा नहीं कर सकते कि लॉग किए गए एक्टर के पास वह कार्रवाई करने का कोई अधिकार था भी या नहीं।

एंडपॉइंट्स को मॉडल करने से पहले अकाउंटिंग स्टेट्स को मॉडल करें

सबसे आम डिज़ाइन की गलती हर वित्तीय रिकॉर्ड को create, read, update, delete के साथ एक स्वतंत्र रूप से एडिट करने योग्य ऑब्जेक्ट के रूप में मानना है। अकाउंटिंग इस तरह से काम नहीं करती है, और एक ऑडिटर तुरंत नोटिस कर लेगा यदि पोस्ट की गई जर्नल एंट्री को चुपचाप ओवरराइट किया जा सके।

प्रत्येक वित्तीय रूप से महत्वपूर्ण संसाधन (financially material resource) के लिए एक स्पष्ट स्टेट मशीन की आवश्यकता होती है। जर्नल एंट्री या पेमेंट आमतौर पर इस प्रक्रिया से गुजरता है:

draft → submitted → approved → posted → settled

सुधार इस रास्ते को पीछे नहीं ले जाते। कोई पोस्ट की गई एंट्री जो गलत है, उसमें एक लिंक्ड रिवर्सल या एक कंपेंसेटिंग एडजस्टमेंट होता है। मूल एंट्री बरकरार रहती है।

नियमों का एक व्यावहारिक सेट:

• ड्राफ्ट को अधिकृत उपयोगकर्ताओं द्वारा एडिट किया जा सकता है।
• सबमिट किए गए रिकॉर्ड्स को केवल अनुमत भूमिकाओं (permitted roles) द्वारा एडिट किया जा सकता है, या ड्राफ्ट में वापस किया जा सकता है।
• अप्रूव किए गए रिकॉर्ड्स के लिए नियंत्रित संशोधन और नए अप्रूवल की आवश्यकता होती है।
• पोस्ट किए गए रिकॉर्ड्स को ओवरराइट या डिलीट नहीं किया जा सकता, केवल उलट (reverse) या एडजस्ट किया जा सकता है।
• बंद अवधि (closed-period) के बदलावों के लिए उच्च स्तरीय ऑथराइज़ेशन, एक बताए गए कारण और एक ऑडिट इवेंट की आवश्यकता होती है।

अवैध ट्रांजिशन्स का कोई भी प्रयास, जैसे कि पोस्ट की गई एंट्री को एडिट करना, एक स्थिर त्रुटि (stable error) लौटाना चाहिए और फिर भी एक ऑडिट रिकॉर्ड लिखना चाहिए। असफल प्रयास भी साक्ष्य है।

यहीं पर एक इम्यूटेबल डबल-एंट्री लेजर अपनी जगह बनाता है। Nordlet का लेजर इस तरह से बनाया गया है कि हर ट्रांजैक्शन एक संतुलित, स्थायी एंट्री के रूप में दर्ज होता है, कमिट के समय डेटाबेस ट्रिगर द्वारा बैलेंस लागू (enforce) किया जाता है, और सुधार रीराइट्स के बजाय रिवर्सल के माध्यम से होते हैं। वहconstraint विकास के दौरान प्रतिबंधात्मक महसूस होता है और ऑडिट के दौरान वही चीज़ बन जाता है जिस पर आपका अकाउंटेंट भरोसा करता है।

हर अनुरोध को ऑथराइज़ करें, न कि केवल ऑथेंटिकेट

ऑथेंटिकेशन साबित करता है कि कॉल कौन कर रहा है। यह इस बारे में कुछ नहीं कहता कि क्या वह कॉलर किसी विशेष चालान, जर्नल या कानूनी इकाई को छू सकता है। OWASP API Security Project टूटे हुए ऑब्जेक्ट-लेवल ऑथराइज़ेशन को अपनी जोखिम सूची में सबसे ऊपर रखता है, ठीक इसलिए क्योंकि API ऐसे ऑब्जेक्ट आइडेंटिफ़ायर को उजागर करते हैं जो जांच न होने पर क्रॉस-टैनेंट एक्सेस को आसान बनाते हैं।

वित्तीय API के प्रत्येक अनुरोध को केवल एक टोकन के बजाय कई कारकों के संयोजन के आधार पर ऑथराइज़ किया जाना चाहिए:

• ऑथेंटिकेटेड एक्टर
• क्लाइंट एप्लिकेशन या सर्विस अकाउंट
• टेनेंट
• कानूनी इकाई (legal entity)
• रिसोर्स ID
• अनुरोधित ऑपरेशन
• वर्तमान रिसोर्स स्टेट
• राशि या ट्रांजैक्शन थ्रेशोल्ड

बाकी सब से ज़्यादा दो व्यावहारिक नियम मायने रखते हैं। पहला, ऑथेंटिकेटेड पहचान से टेनेंट और उपयोगकर्ता के संदर्भ (context) को प्राप्त करें, और क्लाइंट द्वारा प्रदान किए गए किसी भी टेनेंट या रोल क्लेम को अस्वीकार करें जो इसके विरोध में हो। कॉलर को कभी भी यह दावा करने में सक्षम नहीं होना चाहिए कि वह किस कंपनी के लिए काम कर रहा है। दूसरा, डिफ़ॉल्ट रूप से अस्वीकार (deny-by-default) का उपयोग करें। यदि कोई नीति स्पष्ट रूप से किसी कार्रवाई की अनुमति नहीं देती है, तो वह विफल हो जाती है।

दोनों दिशाओं में परीक्षण करें। क्षैतिज एक्सेस (horizontal access), जहां एक टेनेंट दूसरे टेनेंट के डेटा तक पहुंचता है, और लंबवत एक्सेस (vertical access), जहां एक सामान्य उपयोगकर्ता अप्रूवल, पोस्टिंग या एक्सपोर्ट फ़ंक्शन तक पहुंचता है। दोनों आम हैं और दोनों अकाउंटिंग डेटा में विनाशकारी हैं।

owner, admin, accountant, manager, developer और viewer की भूमिकाओं के साथ Nordlet का रोल मॉडल, एक खाते के तहत कई कंपनियों में इस अलगाव को आकांक्षी के बजाय लागू करने योग्य बनाने के लिए मौजूद है। एक डेवलपर भूमिका जो ड्राफ्ट चालान बना सकती है, उसे भुगतान जारी करने में सक्षम नहीं होना चाहिए।

टोकन को व्यावसायिक क्षमताओं के दायरे में रखें, न कि CRUD वर्ब्स तक

प्रतिनिधि एक्सेस (delegated access) के लिए, पुनर्चक्रित पासवर्ड या व्यापक स्थिर API कुंजियों (static API keys) के बजाय वर्तमान OAuth 2.0 सुरक्षा मार्गदर्शन का उपयोग करें। RFC 9700 वर्तमान सर्वोत्तम अभ्यास (Best Current Practice) है और क्लाइंट्स और ऑथराइज़ेशन सर्वर के लिए स्पष्ट आवश्यकताएं निर्धारित करता है: वैलिडेटेड रीडायरेक्ट URI, जहां लागू हो वहां PKCE, जारीकर्ता और ऑडियंस की जाँच, छोटे एक्सेस-टोकन जीवनकाल, और रद्दीकरण (revocation) के साथ रिफ्रेश-टोकन रोटेशन।

दायरे (scoping) का निर्णय वह जगह है जहाँ अकाउंटिंग-विशिष्ट सोच दिखाई देती है। read और write जैसे सामान्य दायरे职责 के विभाजन के लिए लगभग बेकार हैं। दायरे क्षमताओं से जुड़े होने चाहिए:

• journal:create और journal:approve अलग-अलग दायरे हैं।
• भुगतान निर्देश बनाना इसे जारी करने की अनुमति नहीं देता है।
• एक्सपोर्ट की अनुमति रीड की अनुमति से अलग है, क्योंकि बल्क एक्सपोर्ट डेटा-लीकेज का रास्ता है।

इस पैमाने पर कोई दिया गया उत्पाद कहाँ बैठता है, इसके बारे में सटीक रहें। Nordlet की API कुंजियों में प्रति-मॉड्यूल दायरे होते हैं जैसे sales:read और sales:write, जिनकी प्रत्येक कार्रवाई पर जाँच की जाती है, जो मॉड्यूल और रीड को राइट से अलग करता है लेकिन क्रिएट को अप्रूव से नहीं; जहाँ आपको आज उस बारीक विभाजन की आवश्यकता है, उसे कॉल से पहले अपनी खुद की सेवा में लागू करें।

उच्च-मूल्य वाले ऑपरेशनों के लिए, यह आकलन करना उचित है कि क्या FAPI 2.0 Security Profile लागू होता है। इसे संवेदनशील वित्तीय डेटा की सुरक्षा करने वाले API के लिए डिज़ाइन किया गया था और यह बेसलाइन OAuth की तुलना में मजबूत गारंटी प्रदान करता है। अधिकांश SMB अकाउंटिंग इंटीग्रेशंस को पूर्ण प्रोफ़ाइल की आवश्यकता नहीं होगी, लेकिन पेमेंट-रिलीज़ और बैंक-कनेक्शन प्रवाह इसे विचार करने के स्थान हैं।

एक-बार के ईमेल लिंक के माध्यम से Nordlet का पासवर्ड रहित साइन-इन मानव उपयोगकर्ताओं के लिए पुनर्चक्रित-पासवर्ड की समस्या को दूर करता है, जो घुमाने, लीक करने या फ़िश करने के लिए एक कम क्रेडेंशियल है।

वित्तीय राइट्स को आइडपोटेंट (idempotent) बनाएं

नेटवर्क अनुरोध के बीच में विफल हो जाते हैं। एक क्लाइंट भुगतान निर्देश भेजता है, प्रतिक्रिया आने से पहले कनेक्शन कट जाता है, और क्लाइंट फिर से प्रयास करता है। सुरक्षा के बिना, अब आपके पास दो भुगतान हैं।

आइडपोटेंसी कुंजियाँ (Idempotency keys) इसे हल करती हैं। क्लाइंट प्रत्येक राइट के साथ एक अनूठी कुंजी भेजता है; सर्वर कुंजी और उसके परिणाम को रिकॉर्ड करता है। एक ही कुंजी के साथ एक पुनः प्रयास (retry) दूसरी प्रविष्टि बनाने के बजाय मूल परिणाम लौटाता है। Nordlet प्रत्येक म्यूटेटिंग कॉल पर एक Idempotency-Key हेडर स्वीकार करता है, उसी पेलोड के साथ रीट्राई पर संग्रहीत प्रतिक्रिया को फिर से चलाता है और बदले हुए पेलोड के साथ उसी कुंजी को अस्वीकार करता है, और कोई भी अकाउंटिंग API जो इस सुविधा को छोड़ देता है, वह अंततः डुप्लिकेट लेजर एंट्री तैयार करेगा जिसे किसी को हाथ से सुलझाना होगा।

इसे सर्वर-side वैलिडेशन के साथ पेयर करें। क्लाइंट पर कभी भी यह जाँच करने के लिए भरोसा न करें कि डेबिट क्रेडिट के बराबर हैं, कि देश और अवधि के लिए वैट दर मान्य है, या कि खाता मौजूद है। वैलिडेशन सर्वर पर, स्टेट ट्रांजिशन से पहले चलता है, और एक अस्वीकृत राइट एक स्थिर त्रुटि और एक ऑडिट रिकॉर्ड तैयार करता है।

छेड़छाड़-रोधी ऑडिट ट्रेल्स और डच रिटेंशन

ऑडिट लॉग साक्ष्य परत (evidence layer) है, और इसकी सामान्य व्यावसायिक डेटा से अलग आवश्यकताएं हैं। इसे रहस्यों या पूर्ण भुगतान क्रेडेंशियल्स को रिकॉर्ड किए बिना ऑथराइज़ेशन निर्णय, पॉलिसी संस्करण, एक्टर, ऑब्जेक्ट, ऑपरेशन, पिछले और नए राज्य और कारण कोड (reason code) को रिकॉर्ड करना चाहिए।

महत्वपूर्ण विशेषता छेड़छाड़-स्पष्टता (tamper-evidence) है। यदि कोई व्यवस्थापक चुपचाप ऑडिट रिकॉर्ड को एडिट या डिलीट कर सकता है, तो लॉग कुछ भी साबित नहीं करता है। केवल-जोड़ने योग्य स्टोरेज (append-only storage), क्रिप्टोग्राफिक चेनिंग, या राइट-ओनिस रिटेंशन इन सभी का समाधान करते हैं। बात यह है कि संशोधन का पता लगाने योग्य होना चाहिए।

रिटेंशन अपनी खुद की पॉलिसी का हकदार है, जो व्यावसायिक-रिकॉर्ड विलोपन से अलग है। नीदरलैंड्स में, प्रशासनिक रिकॉर्ड के लिए सामान्य रिटेंशन अवधि सात वर्ष है, और अचल संपत्ति से संबंधित रिकॉर्ड के लिए यह दस वर्ष तक चलती है। आपके सामान्य डेटा-विलोपन और GDPR विलोपन वर्कफ़्लो को उन रिकॉर्ड्स या ऑडिट साक्ष्यों को नष्ट करने में सक्षम नहीं होना चाहिए जिन्हें कानूनी रिटेंशन नियम अभी भी कवर करता है। स्वतंत्र रूप से ऑडिट साक्ष्य के लिए कानूनी होल्ड, आर्काइवल और विलोपन नियमों को परिभाषित करें, और उन्हें उनjurisdictions पर मैप करें जिनमें आप काम करते हैं।

पीरियड लॉकिंग अकाउंटिंग लेयर पर इसका समर्थन करती है। एक बार महीना बंद हो जाने के बाद, इसमें प्रविष्टियाँ उच्च स्तरीय ऑथराइज़ेशन और एक लॉग किए गए कारण के बिना नहीं बदल सकती हैं। Nordlet पीरियड लॉकिंग को लागू करता है ताकि बंद महीने बंद रहें, API के माध्यम से भी एक लॉक की गई अवधि के भीतर दिनांकित किसी भी पोस्टिंग को अस्वीकार कर दिया जाए, जो कि पहली चीज़ों में से एक है जिसकी एक डच ऑडिटर जाँच करता है।

किनारों को सुरक्षित करें: वेबहुक, एक्सपोर्ट और इंटीग्रेशंस

कोर API आमतौर पर सिस्टम का सबसे सुरक्षित हिस्सा होता है। किनारे लीक करते हैं।

वेबहुक एक जाली-अनुरोध जोखिम (forged-request risk) हैं। sale_invoice.paid जैसी किसी घटना पर हस्ताक्षर (sign) किया जाना चाहिए ताकि प्राप्तकर्ता यह सत्यापित कर सके कि यह आपसे आया है, और प्राप्तकर्ताओं को कम से कम एक बार (at-least-once) डिलीवरी के रूप में इलाज करना चाहिए और डिडुप्लीकेशन के लिए इवेंट ID का उपयोग करना चाहिए। Nordlet कच्चे शरीर पर एक HMAC हस्ताक्षर के साथ प्रत्येक वेबहुक डिलीवरी पर हस्ताक्षर करता है और घातीय बैकऑफ़ (exponential backoff) के साथ विफल डिलीवरी को पुनः प्रयास करता है, इसलिए प्राप्तकर्ता को ठीक-एक बार (exactly-once) डिलीवरी मानने के बजाय इवेंट ID द्वारा हस्ताक्षर को सत्यापित करना और डिडुप्लिकेट करना होगा।

एक्सपोर्ट एक बल्क डेटा-लीकेज पाथ है। XLSX, PDF या JSON में रिपोर्ट एक्सपोर्ट एक ही ऑपरेशन में बड़ी मात्रा में वित्तीय डेटा खींचते हैं, इसलिए उन्हें अपनी अनुमति, दर सीमा (rate limits) और ऑडिट लॉगिंग की आवश्यकता होती है। आपके द्वारा उपभोग किए जाने वाले तीसरे पक्ष के इंटीग्रेशंस को अनियंत्रित इनपुट के रूप में माना जाना चाहिए, उसी तरह से वैलिडेट किया जाना चाहिए जिस तरह से आप सीधे क्लाइंट अनुरोधों को वैलिडेट करते हैं।

डच अकाउंटिंग API के लिए ऑडिट-तैयारता चेकलिस्ट

इससे पहले कि आप दावा करें कि कोई इंटीग्रेशन ऑडिट-तैयार है, इसका उपयोग करें:

• प्रत्येक वित्तीय संसाधन पर स्पष्ट स्टेट मशीन; पोस्ट किए गए प्रविष्टियों को ओवरराइट नहीं किया जा सकता है
• प्रत्येक अनुरोध पर ऑब्जेक्ट-लेवल और कानूनी-इकाई ऑथराइज़ेशन, डिफ़ॉल्ट रूप से अस्वीकार (deny-by-default)
• टोकन से प्राप्त टेनेंट और रोल संदर्भ, क्लाइंट दावों से नहीं
• RFC 9700 के अनुसार OAuth 2.0; क्षमता-आधारित दायरे; अलग बनाएं और स्वीकृत करें
• भूमिकाओं में लागू职责 का विभाजन, केवल प्रलेखित नहीं
• सभी वित्तीय राइट्स पर आइडपोटेंट कुंजियाँ
• स्टेट ट्रांजिशन से पहले सर्वर-साइड अकाउंटिंग और वैट वैलिडेशन
• कारण कोड के साथ केवल-जोड़ने योग्य, छेड़छाड़-रोधी ऑडिट लॉग
• डच अवधियों के लिए मैप किए गए रिटेंशन और कानूनी-होल्ड नियम (सात वर्ष, संपत्ति के लिए दस)
• बंद महीनों पर पीरियड लॉकिंग
• डिडुप्लीकेशन के साथ हस्ताक्षरित वेबहुक; स्कोप्ड, रेट-लिमिटेड, लॉग किए गए एक्सपोर्ट

हम पहले क्या बनाएंगे

यदि हम कल किसी डच प्लेटफॉर्म में अकाउंटिंग को एम्बेड कर रहे होते, तो हम सिंगल बिजनेस एंडपॉइंट लिखने से पहले स्टेट मॉडल और ऑब्जेक्ट-लेवल ऑथराइज़ेशन से शुरू करते। वे दो निर्णय नीचे की हर चीज़ को विवश करते हैं, और उन्हें एक ऐसी प्रणाली में सुधारना जो लेजर प्रविष्टियों को संपादन योग्य पंक्तियों के रूप में मानती है, वास्तव में दर्दनाक है। आइडपोटेंसी और ऑडिट लॉग इसके बाद आते हैं, क्योंकि उन्हें जल्दी जोड़ना सस्ता है और डेटा प्रवाहित होने के बाद उन्हें जोड़ना महंगा है।

बाकी सब - स्कोप्ड टोकन, हस्ताक्षरित वेबहुक, पीरियड लॉकिंग - अधिक आसानी से अनुसरण करता है जब नींव रखती है। उत्पादन डेटा को छूने से पहले सैंडबॉक्स कंपनी के खिलाफ इन सबका अभ्यास किया जा सकता है।

FAQ

क्या ऑडिट-तैयार API का मतलब है कि व्यवसाय अनुपालक (compliant) है?

नहीं, और इसके बारे में सटीक होना उचित है। ऑडिट-तैयारता सिस्टम की एक डिज़ाइन संपत्ति है: लेजर, नियंत्रण और साक्ष्य श्रृंखला इस तरह से बनाई गई है कि एक ऑडिट सफल हो सकता है। किसी विशिष्ट कर, लेखांकन या सुरक्षा फ्रेमवर्क का अनुपालन एक अलग आकलन है जो उन नियंत्रणों को एक नामित मानक पर मैप करता है। एक अच्छी तरह से बनाया गया API अनुपालन के काम को आसान बनाता है; यह इसे प्रतिस्थापित नहीं करता है।

नीदरलैंड्स में अकाउंटिंग रिकॉर्ड्स को कितने समय तक सुरक्षित रखना आवश्यक है?

सामान्य दायित्व प्रशासनिक रिकॉर्ड के लिए सात साल है, जो अचल संपत्ति से जुड़े रिकॉर्ड के लिए दस साल तक बढ़ जाता है। रिटेंशन और लीगल-होल्ड नियम बनाएं जिन्हें आपके सामान्य विलोपन वर्कफ़्लो ओवरराइड न कर सकें।

क्या वित्तीय इंटीग्रेशन के लिए एक स्थिर API कुंजी (static API key) पर्याप्त है?

संकुचित दायरे के साथ सर्वर-से-सर्वर ऑटोमेशन के लिए यह काम कर सकता है, लेकिन पुनर्चक्रित स्थिर कुंजियों को घुमाना मुश्किल है और लीक होने पर खतरनाक हैं। प्रतिनिधि एक्सेस और किसी भी मानव-सामना करने वाले प्रवाह के लिए, अल्पकालिक, क्षमता-स्कोप्ड टोकन के साथ OAuth 2.0 मजबूत विकल्प है।

अकाउंटिंग के लिए आइडपोटेंसी इतनी महत्वपूर्ण क्यों है?

क्योंकि अधिकांश प्रणालियों में एक डुप्लिकेट राइट एक झुंझलाहट है, और अकाउंटिंग में एक डुप्लिकेट राइट बही-खाते में एक गलत नंबर है जिसे किसी को ढूंढना और उलटना पड़ता है। आइडपोटेंसी कुंजियाँ रीट्राई को जोखिम भरे के बजाय सुरक्षित बनाती हैं।

आगे की पढ़ाई

• वर्तमान API जोखिम श्रेणियों के लिए OWASP API Security Project
• प्रतिनिधि-एक्सेस आवश्यकताओं के लिए RFC 9700: OAuth 2.0 Security Best Current Practice
• अभ्यास में डच कर चित्र कैसा दिखता है, इसके लिए नीदरलैंड में डेवलपर्स के लिए वास्तविक समय का EU VAT
• दायरे, आइडपोटेंसी, त्रुटियों और वेबहुक हस्ताक्षर के लिए API सम्मेलन