Era API

Era API के एंडपॉइंट, ऑथेंटिकेशन, पेजिनेशन और लिमिट, कॉपी करने लायक़ अनुरोधों के साथ।

आख़िरी अपडेट: 1 अक्टूबर 2026

अभी भी बीटा में

ये एंडपॉइंट आज काम करते हैं, लेकिन API अभी भी बदल रहा है, इसलिए कुछ जानकारी बदल सकती है। यह पेज आख़िरी बार कब अपडेट हुआ, यह जानने के लिए ऊपर दी गई 'आख़िरी अपडेट' तारीख़ देखें।

क्विकस्टार्ट

शुरू करने से पहले आपको एक Era अकाउंट चाहिए जिसमें कम से कम एक संस्थान जुड़ा हो — कनेक्शन के बिना इन एंडपॉइंट के पास लौटाने को कुछ नहीं होगा।

1
Era में साइन इन करें और अगर पहले से नहीं किया है तो कोई संस्थान जोड़ें।
2
डैशबोर्ड में अपनी API कीज़ खोलें और एक की बनाएं। शुरुआत में ज़्यादातर स्कोप पर निशान लगा होता है; जो स्कोप पैसे भेज सकते हैं, ट्रेड कर सकते हैं, आपकी बिलिंग बदल सकते हैं, आपके दस्तावेज़ मिटा सकते हैं या और कीज़ बना सकते हैं, उन पर नहीं। जो नहीं चाहिए उनसे निशान हटा दें। पढ़ने के लिए banking:read चाहिए, और कुछ भी बदलने के लिए banking:write। एक्सपायरी भी आप चुनते हैं; कभी न ख़त्म होने वाला विकल्प है ही नहीं।
3
की कॉपी करके किसी सुरक्षित जगह रखें, जैसे किसी सीक्रेट्स मैनेजर में। वह सिर्फ़ एक बार दिखती है, इसलिए अगर की खो जाए, तो नई की बनाएँ।
4
अपनी रिक्वेस्ट के साथ उसे हेडर में भेजें।

cURL

curl "https://forge.era.app/api/banking/transactions?page=1&pageSize=20" \
  -H "X-API-Key: fmk_your_key_here"

रिस्पॉन्स · 200

{
  "transactions": [ … ],
  "pagination": {
    "currentPage": 1,
    "pageSize": 20,
    "totalItems": 412,
    "totalPages": 21
  },
  "historyWindowApplied": true,
  "historyWindowFloorDate": "2026-06-28",
  "historyWindowHiddenCount": 137,
  "historyWindowEarliestDate": "2024-03-02",
  "historyWindowDegraded": false
}

अपना ख़ुद का क्लाइंट लिख रहे हैं? उसे https://forge.era.app/api/openapi/public.json पर मौजूद OpenAPI डॉक्यूमेंट से जनरेट करें। यह इस पेज के हर एंडपॉइंट को बताता है — हर फ़ील्ड, हर स्टेटस, और नियमों के हर तरह के फ़िल्टर और एक्शन — और इसे ख़ुद API परोसता है, इसलिए यह पीछे नहीं छूटता।

की बनाएं

एंडपॉइंट

सत्रह एंडपॉइंट: आठ पढ़ने के लिए और नौ लिखने के लिए।

GET
/banking/accounts
आपके हर जुड़े हुए संस्थान में, हर वह अकाउंट जिसे आप देख सकते हैं
GET
/banking/accounts/{accountId}/balance
एक अकाउंट का बैलेंस, देनदारी होने पर क्रेडिट से जुड़े फ़ील्ड सहित
GET
/banking/accounts/summary
जो अकाउंट आपको दिखते हैं, उनका कुल जोड़, डिफ़ॉल्ट रूप से लाइव अकाउंट का
GET
/banking/transactions
आपके ट्रांज़ैक्शन, एक बार में एक पेज
PUT
/banking/transactions/{id}
एक ट्रांज़ैक्शन बदलें
PUT
/banking/transactions/bulk
एक साथ 100 तक बदलें
GET
/banking/categories
पूरा कैटेगरी ढांचा, सब-कैटेगरी भी नेस्टेड
POST
/banking/categories
कैटेगरी जोड़ें
GET
/banking/tags
आपके अकाउंट के सभी टैग, एक ही रिस्पॉन्स में
POST
/banking/tags
टैग बनाएँ
GET
/banking/rules
आपके अकाउंट के सभी ऑटोमेशन नियम, एक ही रिस्पॉन्स में
POST
/banking/rules
नियम बनाएँ
POST
/banking/rules/preview
नियम का प्रीव्यू देखें
PUT
/banking/rules/{ruleId}
नियम बदलें
POST
/banking/rules/{ruleId}/enable
नियम चालू करें
POST
/banking/rules/{ruleId}/disable
नियम बंद करें
DELETE
/banking/rules/{ruleId}
नियम हटाएँ

प्रमाणीकरण

अपनी की इन दो तरीकों में से किसी एक से भेजें:

ऑथेंटिकेशन के तरीके

हेडर: X-API-Key: fmk_your_key_here
बियरर टोकन: Authorization: Bearer fmk_your_key_here

हर रिक्वेस्ट TLS से एन्क्रिप्टेड होती है।

कीज़ ख़त्म होती हैं, और कितनी जल्दी — यह आप बनाते वक़्त चुनते हैं। ज़्यादा से ज़्यादा मुफ़्त प्लान पर 90 दिन और पेड प्लान पर 365 दिन। कभी न ख़त्म होने वाला विकल्प नहीं है, इसलिए इस पर बनाई किसी भी चीज़ को की समय रहते बदलने की योजना चाहिए।

रिस्पॉन्स हेडर

X-RateLimit-* हेडर आपका दैनिक बजट बताते हैं, इसलिए ये आपको सिर्फ़ उसी प्लान पर दिखेंगे जिसका दैनिक बजट प्रकाशित हो। फ़िलहाल ऐसा सिर्फ़ मुफ़्त प्लान है। वहाँ भी इन्हें वैकल्पिक मानें: बिना इनके आए रिस्पॉन्स का मतलब है कि गिनती पता नहीं है, यह नहीं कि कुछ गड़बड़ हुई। हर 429 में Retry-After आता है।

रिस्पॉन्स हेडर

X-RateLimit-Limit: आपके प्लान का दैनिक बजट। सिर्फ़ उन प्लान पर भेजा जाता है जिनका दैनिक बजट प्रकाशित है, और किसी और सीमा वाले 429 पर कभी नहीं।
X-RateLimit-Remaining: आपके दैनिक बजट में कितना बचा है। कभी शून्य से नीचे नहीं। सिर्फ़ उन प्लान पर भेजा जाता है जिनका दैनिक बजट प्रकाशित है, और किसी और सीमा वाले 429 पर कभी नहीं।
X-RateLimit-Reset: आपका दैनिक बजट अगला एक अनुरोध कब खाली करेगा, Unix टाइमस्टैम्प के रूप में, सेकंड में। यह वह समय नहीं है जब पूरा बजट फिर से भर जाए: बजट लगातार आगे खिसकता है, इसलिए अनुरोध एक-एक करके वापस मिलते हैं। सिर्फ़ उन प्लान पर भेजा जाता है जिनका दैनिक बजट प्रकाशित है, और किसी और सीमा वाले 429 पर कभी नहीं। प्रति-मिनट बर्स्ट सीमा का अपना कोई हेडर नहीं है — देखें लिमिट
Retry-Afterसिर्फ़ 429 पर: हर 429 में Retry-After आता है: उतने सेकंड रुकें, फिर दोबारा कोशिश करें। जिस 429 में X-RateLimit-* हेडर भी हों, उसे मुफ़्त प्लान के दैनिक बजट ने मना किया। जिस 429 में वे न हों, उसे किसी और सीमा ने मना किया, जैसे प्रति-मिनट बर्स्ट सीमा ने। Retry-After एक सेकंड से लेकर 24 घंटे तक कुछ भी हो सकता है। देखें लिमिट

एरर

यह API ये एरर स्टेटस कोड लौटाता है:

400
गलत इनपुट: कोई ग़लत पैरामीटर, खाली या 100 से ज़्यादा आइटम वाला बल्क अपडेट, ऐसा राइट जो एक ही कॉल में एक ही फ़ील्ड को सेट भी करे और क्लियर भी, या ऐसा नियम जो आपस में मेल न खाता हो। किसी नियम को डिलीट, चालू या बंद करने वाली कॉल ऐसी हर क्वेरी कुंजी को भी अस्वीकार करती है जो वह नहीं लेती, और 400 उसका नाम बताता है।
401
की नहीं है, या ऐसी की जो पार्स नहीं होती। इसे X-API-Key हेडर या बियरर टोकन के रूप में भेजें।
402
प्लान का कोटा आड़े आ रहा है। आज यह सिर्फ़ कैटेगरी या पैटर्न नियम बनाने पर लागू होता है। इंतज़ार से यह नहीं हटता, बड़े प्लान से हटता है। बहुत तेज़ी से कॉल करने पर इसके बजाय 429 आता है।
403
की के पास इस कॉल को चाहिए वाला स्कोप नहीं है — या, दोनों ट्रांज़ैक्शन राइट में से किसी एक में, id किसी और की है या सिरे से मौजूद ही नहीं है। API इन दोनों में फ़र्क़ नहीं बताता। Era की लाइब्रेरी वाला नियम 403 देता है, जब आप उसे हटाने की, या उसका नाम, विवरण, प्राथमिकता, तारीख़ें या applicationScope बदलने की कोशिश करते हैं। उसके फ़िल्टर, एक्शन या ग्रुप बदलने पर इसके बजाय 400 मिलता है।
404
ऐसी चीज़ जो मौजूद नहीं है। बैलेंस एंडपॉइंट इसे बिना बॉडी के लौटाता है, ऐसे accountGroupKey के लिए जो किसी अकाउंट को नहीं दर्शाता, या जिसकी बनावट ही key जैसी नहीं है। नियम वाले एंडपॉइंट इसे ऐसी नियम key के लिए लौटाते हैं जो आपकी नहीं है। ट्रांज़ेक्शन कभी 404 नहीं देते — 403 देखें।
409
आप लिख ही रहे थे कि किसी और चीज़ ने वह रो बदल दी — नियम के मामले में, इसका मतलब है ऐसा version जो अब मौजूदा नहीं है। इसे फिर पढ़ें और अपना राइट फिर भेजें। नियम पर, 409 का मतलब यह भी हो सकता है कि उसके एक्शन नियमों को एक चक्र में चला देंगे; ऐसे में एक्शन बदलें।
429
बहुत ज़्यादा अनुरोध। आप मुफ़्त प्लान पर अपना दैनिक बजट ख़र्च कर चुके हैं या किसी और सीमा तक पहुँच गए हैं, जैसे प्रति-मिनट बर्स्ट सीमा। कितना रुकना है, यह Retry-After बताता है — एक सेकंड से 24 घंटे तक — और 402 के उलट, इंतज़ार करने से आपका अगला अनुरोध खाली हो जाता है। प्रकाशित आँकड़े और 429 आपको क्या बताता है, यह लिमिट में देखें।

एरर के फ़ॉर्मेट

ज़्यादातर एरर एक ही फ़ॉर्मेट में लौटते हैं: statusCode, message, और एक errors ऑब्जेक्ट जो बताता है कि क्या गड़बड़ थी। सभी नहीं: 401, और बैलेंस एंडपॉइंट का 404, बिना किसी बॉडी के लौटते हैं, इसलिए बॉडी पढ़ने से पहले स्टेटस पढ़ें।

उदाहरण

{
  "statusCode": 403,
  "message": "One or more errors occurred!",
  "errors": {
    "generalErrors": ["Transaction does not belong to the authenticated user"]
  }
}

आम एरर

एक ही राइट में किसी फ़ील्ड को सेट करना और क्लियर करना — 400।
बल्क अपडेट में 100 से ज़्यादा id — 400, और कुछ नहीं बदलता। एक से कम भी वैसा ही है।
ऐसा ट्रांज़ैक्शन जो आपका नहीं है, या सिरे से मौजूद ही नहीं — 403, कभी 404 नहीं। यानी रिस्पॉन्स कभी नहीं बताता कि कोई id मौजूद है या नहीं, बस इतना बताता है कि वह आपकी नहीं है।
किसी और चीज़ ने पहले ही वह रो बदल दी — 409।

लिमिट

डॉक्यूमेंटेड एंडपॉइंट्स में से दो, एक कॉल में आप कितना मांग सकते हैं इस पर सीमा लगाते हैं। बाकी नहीं लगाते।

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

अकाउंट्स, बैलेंस, समरी, कैटेगरी और टैग की लिस्ट, कैटेगरी बनाना, टैग बनाना, सिंगल-ट्रांज़ेक्शन राइट, और नियमों का हर एंडपॉइंट — इन पर कोई पर-कॉल वॉल्यूम सीमा नहीं है। आपको पूरा सेट वापस मिलता है, या वही एक रो जो आपने नाम से मांगी — सिवाय नियम प्रीव्यू के, जो मेल गिनता है पर उनकी ज़्यादा से ज़्यादा 50 keys और 10 नमूने लौटाता है।
pageSize को मना नहीं किया जाता, 100 पर सीमित कर दिया जाता है। ज़्यादा माँगें तो भी आपको 200 के साथ 100 रो मिलेंगी — जो भेजा उस पर भरोसा करने की बजाय रिस्पॉन्स में pagination.pageSize पढ़ें।
ट्रांज़ैक्शन का बल्क राइट 100 id पर सीमित है, और pageSize से उलट इसे सीमित नहीं, मना कर दिया जाता है: 101 भेजें तो 400 मिलेगा और कुछ नहीं बदलेगा।
की बनाते समय आपके चुने शेड्यूल पर एक्सपायर होती है — फ़्री प्लान पर ज़्यादा से ज़्यादा 90 दिन, पेड प्लान पर 365 दिन। कभी न एक्सपायर होने का कोई विकल्प नहीं है।
आपका प्लान एक हिस्ट्री-विंडो फ़्लोर लगा सकता है जो पुराने ट्रांज़ैक्शन छुपा देता है। ट्रांज़ैक्शन के रिस्पॉन्स में historyWindow फ़ील्ड होते हैं जो बताते हैं कि कोई फ़्लोर लागू हुआ या नहीं और कहाँ।

रेट लिमिट

Era दो रेट लिमिट प्रकाशित करता है। हर प्लान में एक बर्स्ट सीमा है: किसी भी चलते हुए एक मिनट में अनुरोधों की सीमा। मुफ़्त प्लान में इसके अलावा एक दैनिक बजट है: किसी भी चलते हुए 24 घंटों में अनुरोधों की सीमा। कोई अनुरोध करने के एक मिनट बाद वह बर्स्ट सीमा में नहीं गिना जाता, और एक दिन बाद दैनिक बजट में भी नहीं। फ़िलहाल पेड प्लान में कोई प्रकाशित दैनिक बजट नहीं है। इनमें से किसी से, या API की लागू की गई किसी और सीमा से आगे जाने पर कॉल 429 के साथ लौटती है।

सीमाएं आपके खाते की होती हैं, किसी की की नहीं। आपकी बनाई हर REST की उसी बर्स्ट सीमा से और, मुफ़्त प्लान पर, उसी दैनिक बजट से खर्च करती है, इसलिए दूसरी की बनाने से ज़्यादा कॉल नहीं मिलतीं। MCP टूल कॉल अलग से गिनी जाती हैं, इसलिए REST कॉल और MCP कॉल कभी एक-दूसरे की सीमा खर्च नहीं करतीं।

प्लान के हिसाब से रेट लिमिट

प्लान	दैनिक बजट	बर्स्ट सीमा
Basic	100 प्रति दिन	10 प्रति मिनट
Organize	कोई नहीं	30 प्रति मिनट
Automate	कोई नहीं	60 प्रति मिनट
Optimize	कोई नहीं	60 प्रति मिनट
Operate	कोई नहीं	120 प्रति मिनट

फ़िलहाल पेड प्लान में कोई प्रकाशित दैनिक बजट नहीं है।

पेड प्लान उचित उपयोग पर भी चलते हैं: API आपके अपने वित्तीय डेटा पर स्क्रिप्ट, डैशबोर्ड और इंटीग्रेशन के लिए है, उतनी मात्रा में जो एक व्यक्ति के लिए ठीक हो।

किसी भी प्लान पर कोई हेडर बर्स्ट सीमा नहीं बताता, इसलिए अपनी रफ़्तार टेबल के हिसाब से रखें। मुफ़्त प्लान पर, किसी बर्स्ट के 429 के साथ लौटने से ठीक पहले भी X-RateLimit-Remaining शून्य से काफ़ी ऊपर दिख सकता है।

429 आपको क्या बताता है

किस सीमा ने आपको रोका। X-RateLimit-* हेडर वाला 429 मुफ़्त प्लान के दैनिक बजट से आया है; बिना उनके वाला किसी और सीमा से, जैसे बर्स्ट सीमा से। बॉडी problem-details में होती है, और इसका detail फ़ील्ड बताता है कि आपका अगला अनुरोध कब खाली होगा। अगर दैनिक बजट या बर्स्ट सीमा ने रोका है, तो यह उस सीमा का नाम, वह कितना देती है, और कौन सा प्लान इसे बढ़ाता या हटाता है, या यह कि आप पहले से सबसे ऊँचे प्लान पर हैं, यह भी बताता है। यह लोगों के पढ़ने के लिए लिखा है, इसलिए इसे पार्स करने के बजाय हेडर पढ़ें।

429 रिस्पॉन्स, दैनिक बजट

{
  "type": "https://httpstatuses.com/429",
  "title": "Too Many Requests",
  "status": 429,
  "detail": "You've used up your daily budget of 100 requests. Your next request frees up at 2026-09-16T09:00:00Z. The Organize plan removes it."
}

हर 429 में Retry-After भी होता है: सेकंड की एक पूरी संख्या, एक सेकंड से 24 घंटे तक। बर्स्ट सीमा का इंतज़ार ज़्यादा से ज़्यादा एक मिनट होता है; मुफ़्त प्लान का दैनिक बजट पूरे 24 घंटे माँग सकता है। रोकी गई कॉल किसी भी सीमा में नहीं गिनी जाती, लेकिन जल्दी दोबारा कोशिश न करें: हर 429 पर Retry-After पूरा होने तक रुकें। दैनिक बजट और बर्स्ट सीमा पर, जल्दी की गई कोशिश फिर रोकी जाती है, और इंतज़ार पूरा होने पर एक अनुरोध खाली होता है, पूरी सीमा नहीं। उसे भेजें और देखें कि क्या लौटता है: रोके जाने पर एक और Retry-After, या मुफ़्त प्लान पर, पूरी होने पर हेडर।

रेट लिमिट उस की को नहीं बचाती जिसका आपको पता ही नहीं रहा। लीक हुई की उन्हीं सीमाओं से कटती है जिनसे आपके अकाउंट की हर दूसरी की, और वह वह सब कर सकती है जिसकी उसके स्कोप अनुमति देते हैं। उसे रद्द करने से वे कॉल वापस नहीं मिलतीं जो वह पहले ही कर चुकी है। किसी की को लेकर शक हो, तो उसे रद्द कर दें। नीचे सुरक्षा और की प्रबंधन देखें।

देखें कि हर प्लान में क्या शामिल है

आम तौर-तरीक़े

रिस्पॉन्स के फ़ील्ड camelCase में होते हैं। क्वेरी पैरामीटर के नाम छोटे-बड़े अक्षर का फ़र्क़ नहीं देखते, पर बाक़ी हर तरह से उन्हें ठीक वैसे ही लिखना होता है जैसे यह पेज दिखाता है — इसलिए pageSize और PageSize दोनों चलते हैं। प्रकाशित स्पेक उनमें से ज़्यादातर को PascalCase में लिखता है। ज़्यादातर एंडपॉइंट ऐसी क्वेरी कुंजी को अनदेखा कर देते हैं जो वे नहीं लेते, इसलिए ग़लत लिखा फ़िल्टर बस फ़िल्टर नहीं करता — जो लौटता है उसे जाँच लें। नियम को डिलीट, चालू और बंद करने वाली कॉल इसका अपवाद हैं: वे किसी भी दूसरी कुंजी को 400 के साथ अस्वीकार करती हैं, जो उसका नाम बताता है। revert_retroactively को अंडरस्कोर के साथ भेजें — revertRetroactively अस्वीकार हो जाता है — और इसे सिर्फ़ डिलीट और बंद करने पर भेजें, क्योंकि चालू करना सिर्फ़ version लेता है।

जो फ़ील्ड कैलेंडर का एक दिन बताता है, वह YYYY-MM-DD में होता है। जो फ़ील्ड एक पल बताता है, वह ऑफ़सेट के साथ ISO 8601 में होता है।

पेज का आकार ठुकराया नहीं जाता, बस सीमा तक काट दिया जाता है। pageSize में 500 माँगिए और आपको 100 पंक्तियाँ और एक 200 मिलेगा, कोई एरर नहीं — इसलिए जो भेजा उस पर भरोसा करने के बजाय pagination.pageSize वापस पढ़िए।

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

REST सादा HTTP है, इसलिए इसे कॉल करने के लिए किसी SDK की ज़रूरत नहीं — HTTP क्लाइंट वाली कोई भी भाषा काफ़ी है। इंस्टॉल करने को कुछ नहीं है।

वर्ज़निंग और बदलाव

API अभी बीटा में है, इसलिए यहाँ दर्ज चीज़ें बदल सकती हैं: कोई एंडपॉइंट, कोई फ़ील्ड, या कोई कॉल कैसे काम करती है।

पाथ में वर्ज़न नंबर नहीं है और कोई वर्ज़न हेडर भी नहीं। हर एंडपॉइंट का एक ही वर्ज़न चालू रहता है, और वही है जो यहाँ दर्ज है।

Changelog

Era Developer Platform में क्या बदला, जिसमें Era API शामिल है, सबसे नया पहले। कोई ईमेल या फ़ीड नहीं है, इसलिए API पर काम की योजना बनाते समय changelog देख लें।

Changelog खोलें

सुरक्षा और की प्रबंधन

एजेंट को मंज़ूरी देने से एक की बनती है

जब आप OAuth से किसी एजेंट को मंज़ूरी देते हैं, Era उसके लिए एक API की बना देता है। वह उसी डैशबोर्ड सूची में आती है जिसमें आपकी बनाई कीज़ हैं, और नाम Era ख़ुद क्लाइंट के नाम से बनाता है।

नाम कैसे बनता है

Auto -- Claude

उसमें ठीक वही स्कोप होते हैं जो आपने उस स्क्रीन पर मंज़ूर किए थे, और कुछ नहीं। डैशबोर्ड से उसे रद्द करें, और जब तक आप उसे दोबारा मंज़ूर न करें, एजेंट को नई पहुँच नहीं मिलेगी। उसके पास पहले से मौजूद टोकन अपनी मियाद ख़त्म होने तक चलता रहता है, ज़्यादा से ज़्यादा एक घंटे।

राइट आपके एक्टिविटी लॉग में दिखते हैं, रीड नहीं

की बनाना और रद्द करना, दोनों आपके एक्टिविटी लॉग में दिखते हैं, और एजेंट MCP पर जो भी टूल कॉल करता है वह भी। REST राइट भी दिखता है — उस बदलाव के रूप में जो उसने किया, जैसे कोई टैग बना या कोई ट्रांज़ैक्शन बदला। REST रीड कोई एंट्री नहीं बनाता। ये एंट्रियाँ Era हर प्लान पर दर्ज करता है, लेकिन पूरा लॉग पढ़ने के लिए Organize या उससे ऊपर चाहिए — उससे नीचे आपको सिर्फ़ सबसे नई एंट्रियाँ दिखती हैं। राइट की एंट्री में आपके अकाउंट का नाम होता है, उस की का नहीं जिसने बदलाव किया।

किसी की पर कभी शक हो तो उसे रद्द कर दीजिए। आपकी ख़ुद बनाई की अपने अगले ही अनुरोध से REST और MCP पर काम करना बंद कर देती है। किसी एजेंट के लिए बनी की को तुरंत नई पहुँच मिलनी बंद हो जाती है, और उसके पास पहले से मौजूद कोई भी टोकन एक घंटे के भीतर ख़त्म हो जाता है। नई की बनाने में एक मिनट लगता है।

की पर भरोसा करने से पहले जान लेने लायक कुछ और बातें।

स्कोप मोटे हैं: banking:read इस पेज की रीड से कहीं ज़्यादा कवर करता है — यही स्कोप आपके अकाउंट की बाक़ी रीड भी कवर करता है — बैलेंस, होल्डिंग, कनेक्शन, ख़र्च। एक ही स्कोप, इससे संकरा विकल्प है ही नहीं। लिखने वाले स्कोप भी उतने ही सूची में हैं जितने पढ़ने वाले — इसलिए किसी भी की को पासवर्ड की तरह संभालें। वह आपके पूरे Era अकाउंट की तरह काम करती है, किसी हिस्से की तरह नहीं।
banking:write Era को बदलता है, आपके बैंक को नहीं: banking:write सिर्फ़ वही बदलता है जो Era के पास रखा है, आपके बैंक में रखी कोई चीज़ नहीं। यह पैसे नहीं भेज सकता और कोई पेमेंट नहीं कर सकता। banking:read की तरह banking:write भी एक ही चौड़ा स्कोप है। इसमें वे बदलाव आते हैं जो आप Era में ख़ुद कर सकते हैं, जैसे किसी ट्रांज़ैक्शन की कैटेगरी, व्यापारी का नाम, नोट और समीक्षा-स्थिति; कैटेगरी, टैग और ऑटोमेशन नियम; Era आपके अकाउंट्स के लिए जो नाम दिखाता है और कौन-से अकाउंट आपको दिखते हैं; और मैन्युअल अकाउंट, उनके बैलेंस और ट्रांज़ैक्शन। यह नया कनेक्शन शुरू कर सकता है, लेकिन अपने बैंक में साइन इन आप ख़ुद ही करते हैं, प्रदाता के फ़्लो में, की के ज़रिए नहीं। यह नया सिंक माँग सकता है, जो सिर्फ़ पढ़ता है, या किसी इंस्टीट्यूशन को डिसकनेक्ट कर सकता है। डिसकनेक्ट करने से Era का जुड़ाव ख़त्म होता है, और बैंक में आपका अकाउंट खुला और जस का तस रहता है।
स्कोप अपडेट नहीं होते: की के स्कोप बनाते वक़्त तय हो जाते हैं और बाद में कभी नहीं बदलते। जो चीज़ किसी स्कोप में तो आती है पर अभी चालू नहीं हुई, उसके लिए यह मायने रखता है: आज social:write दे दिया, तो जिस दिन साझा व्यू आएंगे उस दिन भी वह की उसे लिए बैठी होगी। जो आज इस्तेमाल कर रहे हैं वही दीजिए, जो शायद कभी करें वह नहीं।
मंज़ूरी की ज़रूरत नहीं: की बनाने के लिए न कोई समीक्षा है, न प्रतीक्षा सूची: Era में कोई आपके अनुरोध को मंज़ूरी नहीं देता। यह बनते ही आपके एक्टिविटी लॉग में दर्ज हो जाता है, तो कोई अनजान की आसानी से नज़र आ जाती है।
बैंक लॉगिन की पहुँच से बाहर रहता है: की आपके बैंक लॉगिन तक नहीं पहुँच सकती, क्योंकि Era के पास वह होता ही नहीं। आप उसे डेटा प्रदाता के चलाए कनेक्शन फ़्लो में डालते हैं, Era की किसी स्क्रीन पर नहीं — उसके बाद Era के पास रहता है सिर्फ़ हर कनेक्शन का एक एक्सेस टोकन, जो AES-256 से एन्क्रिप्टेड रहता है और संस्थान को डिस्कनेक्ट करके फेंका जा सकता है।
Era आपकी की का सिर्फ़ हैश रखता है: आपकी की 256 बिट का रैंडम डेटा है। Era इसे SHA-256 से हैश करता है और सिर्फ़ हैश रखता है, इसलिए अगर की खो जाए, तो उसे रद्द करके नई बना लें।

Era आपके डेटा की हिफ़ाज़त कैसे करता है

मुख्य संसाधन

अकाउंट

GET/banking/accounts

ज़रूरी स्कोपbanking:read

हर जुड़े संस्थान में फैले, वे सारे अकाउंट जो आपको दिखते हैं — और उनके बग़ल में उनकी गिनती भी जो छूट गए: excludedAccountCount, जो दो हिस्सों में बँटी है — tierExcludedAccountCount उन अकाउंट के लिए जिन्हें आपके प्लान की अकाउंट सीमा बाहर रखती है, और userExcludedAccountCount उनके लिए जिन्हें आपने छिपाया है। accountLimit बताता है कि आपका प्लान आपके सारे कनेक्शन मिलाकर एक साथ कितने अकाउंट दिखाता है। accountLimitLift उस सबसे सस्ते प्लान का नाम बताता है जिसमें आपके हर न-छिपाए अकाउंट के लिए जगह है, और जब आपका प्लान कुछ भी बाहर नहीं रखता, तब यह null होता है। हर अकाउंट अपने साथ अपना accountGroupKey लेकर आता है — वही मान जो बैलेंस वाला एंडपॉइंट अपने पाथ में लेता है — और वह connectionId भी जिससे वह जुड़ा है, इसलिए सबसे पहले यही कॉल कीजिए। connectionId लेता है ताकि आप एक ही कनेक्शन तक सीमित कर सकें (गिनतियाँ भी उसके साथ सीमित होती हैं, accountLimit और accountLimitLift नहीं), और includeExcluded ताकि आपके प्लान से बाहर रखे गए और आपके छिपाए हुए अकाउंट भी आ जाएँ।

क्वेरी पैरामीटर

connectionIdवैकल्पिक: सूची को एक ही कनेक्शन के अकाउंट तक सीमित करता है।
includeExcludedवैकल्पिक: आपके प्लान से बाहर रखे गए और आपके छिपाए हुए अकाउंट भी शामिल करता है, उनके बैलेंस रोककर। हर पंक्ति का visibility फ़ील्ड बताता है कि कौन-सा मामला है: tierExcluded या userExcluded, और बाक़ी में visible। बैलेंस वाला एंडपॉइंट इन्हें अलग तरह से लिखता है, इसलिए दोनों के लिए एक ही पार्सर मत रखिए। इसके true होने पर भी excludedAccountCount आता है, और वे अकाउंट पहले से लिस्ट में होते हैं, इसलिए दोनों को मत जोड़िए। डिफ़ॉल्ट रूप से false।

रिस्पॉन्स · 200

{
  "accounts": [
    {
      "accountGroupKey": "uagr_7f3c9a21",
      "connectionId": "ucon_4b19e02c",
      "name": "Everyday Checking",
      "currentBalance": 4820.16,
      "supportsTransactions": true,
      …
    }
  ],
  "excludedAccountCount": 1
}

जिस अकाउंट को आपने छिपाया है, या जिसे आपका प्लान बाहर रखता है, उसके बैलेंस वाले फ़ील्ड शून्य नहीं, null लौटते हैं — null का मतलब है रोक रखा गया, ख़ाली नहीं। supportsTransactions का null भी इसी भाव में है: उसका मतलब है कि Era कह नहीं सकता, यह कभी नहीं कि जवाब ना है। प्लान वाले फ़ील्ड के साथ भी यही है: अगर उस कॉल पर Era आपका प्लान नहीं पढ़ पाया, तो tierExcludedAccountCount, userExcludedAccountCount, accountLimit और accountLimitLift सब null लौटते हैं। जिस प्लान में अकाउंट की कोई सीमा नहीं, उसमें accountLimit भी null होता है, और जब किसी प्लान में इससे ज़्यादा जगह न हो या आपका प्लान कुछ भी बाहर न रखता हो, तो accountLimitLift भी।

अकाउंट का बैलेंस

GET/banking/accounts/{accountId}/balance

ज़रूरी स्कोपbanking:read

One account's balance, with the credit fields filled in when the account is a liability. The path takes that account's accountGroupKey — the same value /banking/accounts returns for it. The key is not checked for shape before the lookup, so a malformed key and an unknown one answer the same way.

रिस्पॉन्स · 200

{
  "accountGroupKey": "uagr_7f3c9a21",
  "currentBalance": 4820.16,
  "availableBalance": 4712.03,
  "creditLimit": null,
  "currencyCode": "USD",
  "availableCredit": null,
  "asOf": "2026-08-11T09:32:00Z",
  "visibility": null
}

छिपाया हुआ अकाउंट हो, या वह जिसका कनेक्शन टूट चुका है — जवाब फिर भी 200 ही आता है, बस बैलेंस वाले फ़ील्ड null होते हैं। 404 का मतलब है कि अकाउंट सचमुच है ही नहीं, या की की बनावट ही key जैसी नहीं थी। यहाँ visibility फ़ील्ड पर नज़र रखिए: अकाउंट दिखता हो तो वह null है, आपके प्लान की अकाउंट सीमा उसे बाहर रखे तो tier_excluded, आपने उसे छिपाया हो तो user_excluded, और उसका कनेक्शन टूट गया हो तो connection_severed। tier_excluded होने पर accountLimit आपके प्लान की सीमा है, और accountLimitLift उस सबसे सस्ते प्लान का नाम बताता है जिसमें इस अकाउंट समेत आपके हर न-छिपाए अकाउंट के लिए जगह है। बाक़ी हर स्थिति में accountLimitLift null होता है, और connection_severed होने पर accountLimit भी null होता है।

अकाउंट का सार

GET/banking/accounts/summary

ज़रूरी स्कोपbanking:read

जो अकाउंट आपको दिखते हैं, उन सबका जोड़, डिफ़ॉल्ट रूप से लाइव अकाउंट का: totalAssets, totalLiabilities, और netWorthHint, जो पहले में से दूसरा घटाकर बनता है। कौन-से मोड गिने जाएँ, यह चुनने के लिए simulationModes दें: अकाउंट की सूची और कुल जोड़ में सिर्फ़ वही मोड आते हैं जो आप बताते हैं। includedSimulationModes हर जवाब में बताता है कि ये कौन-से मोड गिनते हैं। simulationExcludedAccountCount उन अकाउंट की गिनती है जो आपको दिखते हैं पर अपने मोड की वजह से बाहर रह गए। totalHiddenCount अलग गिनती है: वे अकाउंट जिन्हें आपका प्लान या आपकी अपनी विज़िबिलिटी सेटिंग किसी भी मोड में छिपाती है, और simulationModes ने जिन्हें बाहर रखा, वे कभी इसमें नहीं आते।

क्वेरी पैरामीटर

simulationModesवैकल्पिक: किस तरह के अकाउंट जोड़ने हैं: असली पैसे के लिए live, ब्रोकर के प्रैक्टिस अकाउंट के लिए paper, काल्पनिक अकाउंट के लिए scenario। एक से ज़्यादा माँगने के लिए पैरामीटर दोहराएँ, जैसे simulationModes=live&simulationModes=paper। इसे छोड़ दें तो सिर्फ़ लाइव अकाउंट गिने जाते हैं। खाली या अनजानी वैल्यू 400 के साथ ठुकरा दी जाती है, जिसमें मान्य वैल्यू की सूची होती है।

रिस्पॉन्स · 200

{
  "userId": "7d1c0b93a8e24f60",
  "accounts": [ … ],
  "totalVisibleCount": 6,
  "totalHiddenCount": 2,
  "totalAssets": 48210.75,
  "totalLiabilities": 9327.40,
  "netWorthHint": 38883.35,
  "includedSimulationModes": [ "live" ],
  "simulationExcludedAccountCount": 0,
  "computedAt": "2026-08-11T09:32:00Z"
}

netWorthHint सिर्फ़ इसी रिस्पॉन्स में आए अकाउंट गिनता है, और क्या छूट रहा है यह दो गिनतियाँ बताती हैं। simulationExcludedAccountCount उन अकाउंट की संख्या है जो आपके माँगे गए मोड से बाहर हैं। totalHiddenCount उन अकाउंट की संख्या है जो किसी भी मोड में आपसे छिपे हैं। यह दो हिस्सों में बँटती है: tierExcludedAccountCount उन अकाउंट के लिए जिन्हें आपके प्लान की अकाउंट सीमा बाहर रखती है, और userExcludedAccountCount उनके लिए जिन्हें आपने ख़ुद छिपाया है। अगर उस कॉल पर Era आपका प्लान नहीं पढ़ पाया, तो दोनों null होते हैं। accountLimitLift उस सबसे सस्ते प्लान का नाम बताता है जो पहली तरह के अकाउंट वापस ले आता है, और जब ऐसे अकाउंट न हों, तो यह null होता है। netWorthHint को आख़िरी नेट वर्थ नहीं, शुरुआती आँकड़ा मानकर चलिए।

ट्रांज़ैक्शन

GET/banking/transactions

ज़रूरी स्कोपbanking:read

आपके ट्रांज़ैक्शन, एक बार में एक पेज, पेजिंग की गिनती के साथ लपेटकर। page और pageSize लेता है (ऊपरी सीमा 100), साथ में अकाउंट, तारीख़ की सीमा, लागू नियम और लगाए गए टैग के वैकल्पिक फ़िल्टर।

क्वेरी पैरामीटर

accountIdवैकल्पिक: एक अकाउंट के ट्रांज़ैक्शन तक सीमित करता है, उसके accountGroupKey से।
fromDateवैकल्पिक: सिर्फ़ इस तारीख़ को या उसके बाद के ट्रांज़ैक्शन।
toDateवैकल्पिक: सिर्फ़ इस तारीख़ को या उससे पहले के ट्रांज़ैक्शन।
pageवैकल्पिक: पेज नंबर, 1 से शुरू। डिफ़ॉल्ट रूप से 1।
pageSizeवैकल्पिक: प्रति पेज पंक्तियाँ। डिफ़ॉल्ट रूप से 50, 100 तक सीमित।
sortByवैकल्पिक: सॉर्ट करने का फ़ील्ड: transactionDate, amount, description, category, या merchantName।
sortDirectionवैकल्पिक: asc या desc। डिफ़ॉल्ट रूप से अवरोही।
categoryKeysवैकल्पिक: Only transactions in these categories, by their fcat_ keys. Takes a list, not a single key, and a transaction matches if its effective category is any one of them. Send the literal "uncategorized" to select the transactions that have no category at all.
searchवैकल्पिक: व्यापारी, विवरण, कैटेगरी, अकाउंट नाम और राशि पर फ़ुल-टेक्स्ट सर्च।
ruleIdsवैकल्पिक: सिर्फ़ वे ट्रांज़ैक्शन जिन्हें किसी ऑटोमेशन रूल ने छुआ, उस रूल की की से।
tagKeysवैकल्पिक: सिर्फ़ वे ट्रांज़ैक्शन जिन पर इनमें से कोई टैग लगा है।
reviewStatusesवैकल्पिक: needs_review, reviewed, या flagged। एक सूची लेता है; ट्रांज़ैक्शन तब मेल खाता है जब उसका समीक्षा स्टेटस इनमें से कोई एक हो।
includeChildrenवैकल्पिक: With a category filter set, also include transactions in the subcategories of every key you passed. Defaults to false.
includePendingवैकल्पिक: पिछले 7 दिनों के लंबित शुल्क भी लौटाता है, जिन पर isPending लगा होता है। डिफ़ॉल्ट रूप से false। लंबित पंक्तियाँ केवल पढ़ने के लिए हैं।

रिस्पॉन्स · 200

{
  "transactions": [ … ],
  "pagination": {
    "currentPage": 1,
    "pageSize": 20,
    "totalItems": 412,
    "totalPages": 21
  },
  "historyWindowApplied": true,
  "historyWindowFloorDate": "2026-06-28",
  "historyWindowHiddenCount": 137,
  "historyWindowEarliestDate": "2024-03-02",
  "historyWindowDegraded": false
}

आपका प्लान हिस्ट्री-विंडो की एक सीमा लगा सकता है, जो उससे पुराने ट्रांज़ैक्शन छिपा देती है। रिस्पॉन्स में historyWindow वाले फ़ील्ड इसीलिए आते हैं: historyWindowApplied बताता है कि सीमा ने सचमुच कुछ छिपाया, historyWindowFloorDate बताता है वह कहाँ पड़ी, historyWindowHiddenCount बताता है उसके पीछे कितनी पंक्तियाँ हैं, और historyWindowEarliestDate बताता है कि आपकी हिस्ट्री असल में कहाँ तक जाती है। इनके बिना छोटा नतीजा उस अकाउंट से अलग नहीं दिखता जिसमें इससे पुराने ट्रांज़ैक्शन हैं ही नहीं। इनमें से दो आपका कोड बदल देते हैं: सीमा लगी होने पर भी historyWindowHiddenCount null हो सकता है, इसलिए null को शून्य नहीं, अनजान मानकर पढ़ें; और जब historyWindowDegraded true हो, तो उस कॉल पर Era आपके प्लान की पुष्टि नहीं कर पाया, इसलिए सीमा की तारीख़ तथ्य नहीं, अनुमान है। जिस पेड कॉल में प्लान की पुष्टि हो जाती है, वहाँ कोई सीमा नहीं लगती और historyWindowApplied false लौटता है। आपके प्लान की अकाउंट सीमा ट्रांज़ैक्शन भी बाहर रखती है: tierExcludedAccountCount बताता है कि वह आपके कितने अकाउंट इस कॉल से बाहर रखती है, और userExcludedAccountCount कि आपने कितने छिपाए हैं — अगर आपने किसी अकाउंट पर फ़िल्टर किया है, तो दोनों सिर्फ़ उसी अकाउंट तक सीमित रहते हैं। अगर उस कॉल पर Era आपका प्लान नहीं पढ़ पाया, तो दोनों null होते हैं।

लंबी हिस्ट्री को पेज-दर-पेज पढ़ने में अनुरोध ख़र्च होते हैं। आपका प्लान तय करता है कि आप कितनी तेज़ी से कॉल कर सकते हैं और, मुफ़्त प्लान पर, दिन में कितनी कॉल मिलती हैं; पेड प्लान उचित उपयोग पर चलते हैं। प्लान के हिसाब से आँकड़े, रेट-लिमिट हेडर, और 429 आपको क्या बताता है — सब लिमिट में है।

देखें कि हर प्लान में क्या शामिल है

एक ट्रांज़ैक्शन बदलें

किसी ट्रांज़ैक्शन पर चार चीज़ें आप ओवरराइड कर सकते हैं: उसकी कैटेगरी, व्यापारी का नाम, आपका अपना एक नोट, और उसकी समीक्षा-स्थिति। सिर्फ़ वही भेजें जो बदल रहे हैं — जो छोड़ेंगे वह जैसा है वैसा ही रहेगा। पाथ में दिया id उस ट्रांज़ैक्शन की utgr_ की है। इसके लिए banking:read की जगह banking:write चाहिए, लेकिन यह सिर्फ़ Era में रखी ट्रांज़ैक्शन की कॉपी बदलता है: आपके बैंक वाली जैसी थी वैसी ही रहती है।

PUT/banking/transactions/{id}

ज़रूरी स्कोपbanking:write

रिक्वेस्ट बॉडी

categoryKeyवैकल्पिक: जो कैटेगरी सौंपनी है, उसकी fcat_ की। न भेजें तो ट्रांज़ैक्शन अपनी मौजूदा कैटेगरी बनाए रखता है।
merchantNameवैकल्पिक: आपका अपना व्यापारी नाम, ज़्यादा से ज़्यादा 1000 वर्ण। न भेजें तो मौजूदा नाम बना रहता है।
descriptionवैकल्पिक: इस ट्रांज़ैक्शन पर आपका अपना नोट, ज़्यादा से ज़्यादा 5000 वर्ण। न भेजें तो मौजूदा नोट बना रहता है।
clearCategoryवैकल्पिक: आपका कैटेगरी ओवरराइड हटा देता है, ताकि Era का अपना वर्गीकरण फिर से लागू हो जाए। डिफ़ॉल्ट रूप से false।
clearMerchantNameवैकल्पिक: आपका व्यापारी-नाम ओवरराइड हटा देता है, ताकि आपके बैंक का भेजा नाम वापस आ जाए। डिफ़ॉल्ट रूप से false।
clearDescriptionवैकल्पिक: आपका विवरण ओवरराइड हटा देता है, ताकि आपके बैंक का भेजा विवरण वापस आ जाए। डिफ़ॉल्ट रूप से false।
reviewStatusवैकल्पिक: इसे needs_review, reviewed, या flagged के तौर पर चिह्नित करें।
clearReviewStatusवैकल्पिक: आपका समीक्षा-स्थिति ओवरराइड हटा देता है। डिफ़ॉल्ट रूप से false।

रिस्पॉन्स · 200

{
  "transaction": { … }
}

आपको पूरा अपडेटेड ट्रांज़ैक्शन वापस मिलता है, ठीक उसी आकार में जो ऊपर की सूची लौटाती है — यहाँ दोबारा नहीं दिखाया गया, क्योंकि यह बड़ा है और API के बीटा में रहने तक बदलता रहेगा। एक ही कॉल में कोई फ़ील्ड सेट करना और उसे क्लियर करना 400 लौटाता है। ऐसा ट्रांज़ैक्शन जो आपका नहीं है, या है ही नहीं, 403 लौटाता है — API इन दोनों में फ़र्क़ नहीं बताता। और अगर आपके लिखते वक़्त किसी और चीज़ ने वही पंक्ति बदल दी, तो आपको 409 मिलता है: उसे दोबारा पढ़िए और दोबारा भेजिए।

एक साथ 100 तक बदलें

वही चार ओवरराइड, एक ही कॉल में ट्रांज़ैक्शन की एक सूची पर लागू। सूची के हर id को एक जैसे बदलाव मिलते हैं — हर ट्रांज़ैक्शन के लिए अलग-अलग बदलाव का कोई विकल्प नहीं है। इसके लिए banking:read की जगह banking:write चाहिए, लेकिन यह सिर्फ़ Era में रखी उन ट्रांज़ैक्शन की कॉपी बदलता है: आपके बैंक वाली जैसी थीं वैसी ही रहती हैं।

PUT/banking/transactions/bulk

ज़रूरी स्कोपbanking:write

रिक्वेस्ट बॉडी

transactionIds: जिन ट्रांज़ैक्शन को बदलना है, उनकी utgr_ कीज़। कम से कम एक, और ज़्यादा से ज़्यादा 100। 100 से ज़्यादा होने पर काटा नहीं, ठुकराया जाता है — ऊपर वाले pageSize के उलट, आपको 400 मिलता है और कुछ भी नहीं बदलता।
categoryKeyवैकल्पिक: जो कैटेगरी सौंपनी है, उसकी fcat_ की। न भेजें तो ट्रांज़ैक्शन अपनी मौजूदा कैटेगरी बनाए रखता है।
merchantNameवैकल्पिक: आपका अपना व्यापारी नाम, ज़्यादा से ज़्यादा 1000 वर्ण। न भेजें तो मौजूदा नाम बना रहता है।
descriptionवैकल्पिक: इस ट्रांज़ैक्शन पर आपका अपना नोट, ज़्यादा से ज़्यादा 5000 वर्ण। न भेजें तो मौजूदा नोट बना रहता है।
clearCategoryवैकल्पिक: आपका कैटेगरी ओवरराइड हटा देता है, ताकि Era का अपना वर्गीकरण फिर से लागू हो जाए। डिफ़ॉल्ट रूप से false।
clearMerchantNameवैकल्पिक: आपका व्यापारी-नाम ओवरराइड हटा देता है, ताकि आपके बैंक का भेजा नाम वापस आ जाए। डिफ़ॉल्ट रूप से false।
clearDescriptionवैकल्पिक: आपका विवरण ओवरराइड हटा देता है, ताकि आपके बैंक का भेजा विवरण वापस आ जाए। डिफ़ॉल्ट रूप से false।
reviewStatusवैकल्पिक: इसे needs_review, reviewed, या flagged के तौर पर चिह्नित करें।
clearReviewStatusवैकल्पिक: आपका समीक्षा-स्थिति ओवरराइड हटा देता है। डिफ़ॉल्ट रूप से false।

रिस्पॉन्स · 200

{
  "transactions": [ … ]
}

आपको अपडेटेड ट्रांज़ैक्शन वापस मिलते हैं, ठीक उसी आकार में जो ऊपर की सूची लौटाती है। एक ही कॉल में कोई फ़ील्ड सेट करना और उसे क्लियर करना 400 लौटाता है, और ख़ाली सूची भी। ऐसी सूची जिसमें कोई ट्रांज़ैक्शन आपका न हो, या हो ही न, पूरी कॉल के लिए 403 लौटाती है — कुछ भी नहीं बदलता। अगर आपके लिखते वक़्त किसी और चीज़ ने उनमें से किसी पंक्ति को बदल दिया, तो आपको 409 मिलता है: उन्हें दोबारा पढ़िए और दोबारा भेजिए।

कैटेगरी

GET/banking/categories

ज़रूरी स्कोपbanking:read

पूरी कैटेगरी व्यवस्था: कैटेगरी का हर समूह, जिसके अंदर उसकी उप-कैटेगरी नेस्टेड हैं। यह व्यवस्था साझा है, हर अकाउंट के लिए अलग नहीं।

रिस्पॉन्स · 200

{
  "packs": [
    {
      "packSlug": "default",
      "packName": "Era default categories",
      "isDefault": true,
      "categories": [
        {
          "projectionKey": "fcat_food_dining",
          "categoryName": "Food & dining",
          "isTopLevel": true,
          "children": [ … ]
        }
      ]
    }
  ],
  "meterLimit": 25,
  "canCreateCustomCategories": true
}

कैटेगरी जोड़ें

किसी मौजूदा पैरेंट के तहत एक यूज़र-डिफ़ाइंड कैटेगरी। इसके लिए banking:read की जगह banking:write चाहिए, लेकिन यह सिर्फ़ Era में आपकी कैटेगरी बदलता है: आपके बैंक में कुछ नहीं बदलता।

POST

ज़रूरी स्कोपbanking:write

रिक्वेस्ट बॉडी

slug: URL-सुरक्षित पहचानकर्ता — छोटे अक्षर, अंक और हाइफ़न, 2 से 50 वर्ण।
parentCategoryKey: उस कैटेगरी की fcat_ की, जिसके नीचे यह नेस्ट होगी।
name: डिस्प्ले नाम।
descriptionवैकल्पिक: वैकल्पिक विवरण।
iconNameवैकल्पिक: वैकल्पिक आइकन नाम।
spendingTypeवैकल्पिक: वैकल्पिक ख़र्च वर्गीकरण।
displayOrderवैकल्पिक: इसके साथी कैटेगरी के बीच वैकल्पिक क्रम-स्थिति।
assignmentEligibilityवैकल्पिक: किन ट्रांज़ैक्शन को यह कैटेगरी सौंपी जा सकती है, इसका वैकल्पिक नियम।
sourceSystemKeysवैकल्पिक: मौजूदा कैटेगरी की-ज़ की वैकल्पिक सूची, जिनके ट्रांज़ैक्शन आगे से यहाँ भेजे जाने चाहिए।
applyRetroactivelyवैकल्पिक: true होने पर, पुराने ट्रांज़ैक्शन को भी नए रूटिंग के हिसाब से फिर से जाँचता है। डिफ़ॉल्ट रूप से false।

रिस्पॉन्स · 201

{
  "categoryKey": "fcat_side_hustle_9f2a",
  "overlayProjectionKey": "fcov_9f2a1c",
  "action": "created",
  "isQuotaExceeded": false,
  "createdMappingRuleKeys": [ … ],
  …
}

रिस्पॉन्स retroactiveAffectedCount, mergeSourcesHiddenCount, और mergeSourcesTotalCount भी लेकर आता है, जिनकी जानकारी यह पेज नहीं देता, और साथ में isQuotaExceeded, quotaExceededMessage, और meterGate भी, जो बनाई गई कैटेगरी पर हमेशा false, null, और null होते हैं। अगर आपके प्लान का कोटा कैटेगरी बनाने से मना कर दे, तो इसके बजाय 402 आता है, जिसमें इनमें से कोई फ़ील्ड नहीं होता: उसकी बॉडी में statusCode, message, और errors.generalErrors होते हैं, जिसकी इकलौती एंट्री बताती है कि आप किस सीमा तक पहुँच गए।

tagTypeवैकल्पिक: टैग की उत्पत्ति से फ़िल्टर करता है: user, system, या auto।
includeDeletedवैकल्पिक: हटाए गए टैग भी शामिल करता है। डिफ़ॉल्ट रूप से false।

रिस्पॉन्स · 200

{
  "tags": [
    {
      "tagKey": "utag_9c2f01ab",
      "name": "business-expense",
      "displayName": "Business expense",
      "tagType": "user",
      "color": "#6DC6BA",
      "transactionCount": 42
    }
  ]
}

टैग बनाएँ

एक नया टैग, जिसका नाम लोअरकेस में बदल दिया जाता है। इसके लिए banking:read की जगह banking:write चाहिए, लेकिन यह सिर्फ़ Era में आपके टैग बदलता है: आपके बैंक में कुछ नहीं बदलता। सिस्टम टैग API से नहीं बनाए जा सकते; user और auto टैग बनाए जा सकते हैं।

POST

ज़रूरी स्कोपbanking:write

रिक्वेस्ट बॉडी

name: टैग का कैननिकल नाम।
displayNameवैकल्पिक: वैकल्पिक डिस्प्ले नाम। डिफ़ॉल्ट रूप से कैननिकल नाम।
tagTypeवैकल्पिक: user or auto. Defaults to user. system is refused — it is reserved for tags Era creates itself.
colorवैकल्पिक: दिखाने के लिए वैकल्पिक हेक्स रंग।
iconवैकल्पिक: वैकल्पिक आइकन नाम।

रिस्पॉन्स · 201

{
  "tag": {
    "tagKey": "utag_9c2f01ab",
    "name": "business-expense",
    "displayName": "Business expense",
    "tagType": "user",
    "version": 1,
    "createdAt": "2026-08-26T09:15:00Z"
  }
}

नियम

GET/banking/rules

ज़रूरी स्कोपbanking:read

आपके अकाउंट के सभी ऑटोमेशन नियम — जो आपने बनाए और जो Era ने अपनी नियम लाइब्रेरी से आपके लिए सेट किए — हर एक उसकी शर्तों (filters), वह क्या करता है (actions), वह चालू है या नहीं, और उसके वर्ज़न के साथ। कोई पेजिंग नहीं: एक ही रिस्पॉन्स में सब लौट आते हैं। बंद नियम तब तक नहीं आते जब तक आप उन्हें न मांगें।

क्वेरी पैरामीटर

includeInactiveवैकल्पिक: बंद किए गए नियम भी लौटाता है। डिफ़ॉल्ट रूप से false।

रिस्पॉन्स · 200

{
  "rules": [
    {
      "id": "rule_4c1e7a90",
      "ruleName": "Coffee shops",
      "isActive": true,
      "version": 3,
      "priority": 10,
      "filters": [{ "type": "merchant_match", "pattern": "Blue Bottle", "mode": "contains" }],
      "actions": [{ "type": "set_category", "categoryKey": "fcat_coffee_shops", "categoryDisplayName": "Coffee shops" }],
      "source": "user",
      "matchedTransactionCount": 42,
      …
    }
  ]
}

filters और actions टाइप किए गए ऑब्जेक्ट की सूचियाँ हैं। हर ऑब्जेक्ट एक type फ़ील्ड में अपना प्रकार बताता है — फ़िल्टर में merchant_match या category, एक्शन में set_category या add_tag — और क्विकस्टार्ट में लिंक किया गया OpenAPI डॉक्यूमेंट हर प्रकार और उसके फ़ील्ड की सूची देता है।

नियम बनाएँ

एक नया ऑटोमेशन नियम: ऐसी शर्तें जो ट्रांज़ैक्शन चुनती हैं, और उनसे मेल खाने वाले हर ट्रांज़ैक्शन के साथ क्या होता है। यह उसके बाद हर नए ट्रांज़ैक्शन पर चलता है, और आप चाहें तो उन पर भी जो आपके पास पहले से हैं। इसके लिए banking:read की जगह banking:write चाहिए, लेकिन यह सिर्फ़ Era में आपके नियम और ट्रांज़ैक्शन बदलता है: आपके बैंक में कुछ नहीं बदलता।

POST

ज़रूरी स्कोपbanking:write

रिक्वेस्ट बॉडी

ruleName: नियम का एक नाम।
descriptionवैकल्पिक: नियम किस लिए है, इस पर एक वैकल्पिक नोट।
priorityवैकल्पिक: आपके दूसरे नियमों के बीच यह नियम कहाँ चलता है: ऊँचा पहले चलता है, और जब दो नियम एक ही ट्रांज़ैक्शन पर एक ही चीज़ सेट करें, तो ऊँचा जीतता है। डिफ़ॉल्ट रूप से शून्य।
filters: शर्तें, टाइप किए गए फ़िल्टर ऑब्जेक्ट की सूची के रूप में — हर एक type फ़ील्ड में अपना प्रकार बताता है। किसी ट्रांज़ैक्शन को हर शर्त पूरी करनी होती है; उन्हें अलग तरह से जोड़ने के लिए and, or और not फ़िल्टर नेस्ट करें। कम से कम एक। खाता प्रकार बताने वाला account_type फ़िल्टर केवल पैटर्न नियम पर काम करता है; ट्रांज़ैक्शन नियम पर उसे 400 के साथ अस्वीकार कर दिया जाता है।
actions: नियम से मेल खाने वाले हर ट्रांज़ैक्शन के साथ क्या होता है, टाइप किए गए एक्शन ऑब्जेक्ट की सूची के रूप में: कैटेगरी सेट करना, टैग जोड़ना या हटाना, व्यापारी का नाम बदलना, विवरण फिर से लिखना, समीक्षा-स्थिति सेट करना, उसे छिपाना, या उसे ट्रांसफ़र के रूप में चिह्नित करना। कम से कम एक, और टैग एक्शन को छोड़कर हर प्रकार का ज़्यादा से ज़्यादा एक। हर टैग पहले से मौजूद होना चाहिए, और एक ही बार आ सकता है।
isActiveवैकल्पिक: नियम चालू हालत में शुरू हो या नहीं। डिफ़ॉल्ट रूप से true।
applyRetroactivelyवैकल्पिक: नियम को सिर्फ़ नए नहीं, बल्कि आपके पहले से मौजूद ट्रांज़ैक्शन पर भी चलाता है। यह तभी लागू होता है जब नियम चालू हालत में शुरू हो। डिफ़ॉल्ट रूप से false।
appliesFromवैकल्पिक: सिर्फ़ इस तारीख़ या उसके बाद के ट्रांज़ैक्शन।
appliesToवैकल्पिक: सिर्फ़ इस तारीख़ या उससे पहले के ट्रांज़ैक्शन।
applicationScopeवैकल्पिक: नियम कब चलता है: prospective सिर्फ़ नए ट्रांज़ैक्शन पर, retroactive जब इसे मौजूदा ट्रांज़ैक्शन पर चलाया जाए, या both। डिफ़ॉल्ट रूप से both।
ruleScopeवैकल्पिक: transaction, डिफ़ॉल्ट, ट्रांज़ैक्शन को एक-एक करके जाँचता है। pattern कई ट्रांज़ैक्शन में एक पैटर्न पहचानता है — जैसे बार-बार होने वाला कोई चार्ज, या ट्रांसफ़र की एक जोड़ी — जिसे patternSpec बताता है।
triggerModeवैकल्पिक: पैटर्न नियम के लिए, पैटर्न कब जाँचना है: onEachTransaction, onBatchComplete, onSchedule या onDemand। डिफ़ॉल्ट रूप से onEachTransaction।
patternSpecवैकल्पिक: पैटर्न नियम के लिए, खोजा जाने वाला पैटर्न, टाइप किए गए ऑब्जेक्ट के रूप में। ruleScope के pattern होने पर ज़रूरी।
windowDaysवैकल्पिक: पैटर्न नियम के लिए, पैटर्न का बाक़ी हिस्सा खोजने के लिए कितने दिन पीछे देखना है, 1 से 365 के बीच। ruleScope के pattern होने पर ज़रूरी।
windowLookaheadDaysवैकल्पिक: पैटर्न नियम के लिए, पैटर्न का बाक़ी हिस्सा खोजने के लिए कितने दिन आगे देखना है।
windowExcludeTriggerAccountवैकल्पिक: पैटर्न नियम के लिए, जिस ट्रांज़ैक्शन से जाँच शुरू हुई, उसके अकाउंट को खोज से बाहर रखता है। डिफ़ॉल्ट रूप से false।
groupवैकल्पिक: वह ग्रुप जिसमें नियम रखा जाए: spendingHabits, problemsAndAnomalies, incomeAndTransfers, subscriptionsAndRecurring या taxAndRecordKeeping। किसी ग्रुप में न रखने के लिए इसे छोड़ दें। categoryMapping उन नियमों के लिए आरक्षित है जिन्हें Era ख़ुद बनाता है, और इसे 400 के साथ मना कर दिया जाता है।

रिस्पॉन्स · 201

{
  "rule": { … },
  "retroactiveStatus": "completed",
  "affectedTransactionCount": 18
}

retroactiveStatus तब तक null रहता है जब तक आपने कॉल से नियम को पहले से मौजूद ट्रांज़ैक्शन पर लागू करने, या उसके किए को पलटने के लिए न कहा हो। completed का मतलब है कि वह काम रिस्पॉन्स से पहले पूरा हो गया; in_progress का मतलब है कि वह अभी चल रहा है, इसलिए affectedTransactionCount अभी अंतिम नहीं है; queue_full का मतलब है कि कतार भरी थी और काम शुरू नहीं हुआ — फिर भी नियम में किया गया बदलाव सेव हो गया; partial_success का मतलब है कि उसका सिर्फ़ कुछ हिस्सा पूरा हुआ — कुछ बदलाव सेव नहीं हुए, या काम का सिर्फ़ एक हिस्सा कतार में लगा।

नियम का प्रीव्यू देखें

नियम की शर्तों को आपके हाल के ट्रांज़ैक्शन पर आज़माता है और बताता है कि वे किनसे मेल खातीं, कुछ भी सेव किए बिना: जाँचे गए में से कितने मेल खाए, मेल खाने वालों की ज़्यादा से ज़्यादा 50 keys, और ज़्यादा से ज़्यादा 10 नमूने। ट्रांज़ैक्शन नियम पिछले 90 दिनों के ज़्यादा से ज़्यादा 5,000 ट्रांज़ैक्शन जाँचता है, और उसके नमूनों में व्यापारी, रकम और तारीख़ होती है। पैटर्न नियम के नमूनों में detectionReason होता है — पैटर्न क्यों पहचाना गया (यह ख़ाली भी हो सकता है) — और व्यापारी, रकम या तारीख़ नहीं होती। कुछ भी लिखा नहीं जाता, इसलिए banking:read काफ़ी है।

POST/banking/rules/preview

ज़रूरी स्कोपbanking:read

रिक्वेस्ट बॉडी

filters: शर्तें, टाइप किए गए फ़िल्टर ऑब्जेक्ट की सूची के रूप में — हर एक type फ़ील्ड में अपना प्रकार बताता है। किसी ट्रांज़ैक्शन को हर शर्त पूरी करनी होती है; उन्हें अलग तरह से जोड़ने के लिए and, or और not फ़िल्टर नेस्ट करें। कम से कम एक। खाता प्रकार बताने वाला account_type फ़िल्टर केवल पैटर्न नियम पर काम करता है; ट्रांज़ैक्शन नियम पर उसे 400 के साथ अस्वीकार कर दिया जाता है।
ruleScopeवैकल्पिक: transaction, डिफ़ॉल्ट, ट्रांज़ैक्शन को एक-एक करके जाँचता है। pattern कई ट्रांज़ैक्शन में एक पैटर्न पहचानता है — जैसे बार-बार होने वाला कोई चार्ज, या ट्रांसफ़र की एक जोड़ी — जिसे patternSpec बताता है।
patternSpecवैकल्पिक: पैटर्न नियम के लिए, खोजा जाने वाला पैटर्न, टाइप किए गए ऑब्जेक्ट के रूप में। ruleScope के pattern होने पर ज़रूरी।
windowDaysवैकल्पिक: पैटर्न नियम के लिए, पैटर्न का बाक़ी हिस्सा खोजने के लिए कितने दिन पीछे देखना है, 1 से 365 के बीच। ruleScope के pattern होने पर ज़रूरी।

रिस्पॉन्स · 200

{
  "matchCount": 12,
  "totalEvaluated": 418,
  "matchingGroupKeys": ["utgr_5d0e2b77", … ],
  "sampleMatches": [
    {
      "groupKey": "utgr_5d0e2b77",
      "merchantName": "Blue Bottle Coffee",
      "amount": -6.25,
      "currency": "USD",
      "transactionDate": "2026-09-12"
    },
    …
  ]
}

नियम बदलें

नियम की परिभाषा को आपकी भेजी परिभाषा से बदल देता है, इसलिए हर वह फ़ील्ड भेजें जो आप रखना चाहते हैं — सिर्फ़ बदले जाने वाले नहीं। पाथ में दिया ruleId वही id है जो नियमों की सूची लौटाती है, और version वही होना चाहिए जो आपने आख़िरी बार पढ़ा था। Era की लाइब्रेरी वाले नियम में सिर्फ़ userOverrides बदल सकता है: बाक़ी सब कुछ वैसे ही वापस भेजें जैसे सूची ने लौटाया था। इसके लिए banking:read की जगह banking:write चाहिए, लेकिन यह सिर्फ़ Era में आपके नियम और ट्रांज़ैक्शन बदलता है: आपके बैंक में कुछ नहीं बदलता।

PUT/banking/rules/{ruleId}

ज़रूरी स्कोपbanking:write

रिक्वेस्ट बॉडी

versionवैकल्पिक: नियम का वह वर्ज़न जो आपने आख़िरी बार पढ़ा था। यह नियम के मौजूदा वर्ज़न से मेल खाना चाहिए, वरना कॉल 409 के साथ मना कर दी जाती है — इसलिए इसे छोड़ने से जाँच छूटती नहीं, बल्कि विफल हो जाती है।
ruleName: नियम का एक नाम।
descriptionवैकल्पिक: नियम किस लिए है, इस पर एक वैकल्पिक नोट।
priorityवैकल्पिक: आपके दूसरे नियमों के बीच यह नियम कहाँ चलता है: ऊँचा पहले चलता है, और जब दो नियम एक ही ट्रांज़ैक्शन पर एक ही चीज़ सेट करें, तो ऊँचा जीतता है। डिफ़ॉल्ट रूप से शून्य।
filters: शर्तें, टाइप किए गए फ़िल्टर ऑब्जेक्ट की सूची के रूप में — हर एक type फ़ील्ड में अपना प्रकार बताता है। किसी ट्रांज़ैक्शन को हर शर्त पूरी करनी होती है; उन्हें अलग तरह से जोड़ने के लिए and, or और not फ़िल्टर नेस्ट करें। कम से कम एक। खाता प्रकार बताने वाला account_type फ़िल्टर केवल पैटर्न नियम पर काम करता है; ट्रांज़ैक्शन नियम पर उसे 400 के साथ अस्वीकार कर दिया जाता है।
actions: नियम से मेल खाने वाले हर ट्रांज़ैक्शन के साथ क्या होता है, टाइप किए गए एक्शन ऑब्जेक्ट की सूची के रूप में: कैटेगरी सेट करना, टैग जोड़ना या हटाना, व्यापारी का नाम बदलना, विवरण फिर से लिखना, समीक्षा-स्थिति सेट करना, उसे छिपाना, या उसे ट्रांसफ़र के रूप में चिह्नित करना। कम से कम एक, और टैग एक्शन को छोड़कर हर प्रकार का ज़्यादा से ज़्यादा एक। हर टैग पहले से मौजूद होना चाहिए, और एक ही बार आ सकता है।
applyRetroactivelyवैकल्पिक: बदले हुए नियम को आपके पहले से मौजूद ट्रांज़ैक्शन पर फिर से चलाता है, पहले पुराने वर्ज़न का किया पलटकर। डिफ़ॉल्ट रूप से false।
appliesFromवैकल्पिक: सिर्फ़ इस तारीख़ या उसके बाद के ट्रांज़ैक्शन।
appliesToवैकल्पिक: सिर्फ़ इस तारीख़ या उससे पहले के ट्रांज़ैक्शन।
applicationScopeवैकल्पिक: नियम कब चलता है: prospective सिर्फ़ नए ट्रांज़ैक्शन पर, retroactive जब इसे मौजूदा ट्रांज़ैक्शन पर चलाया जाए, या both। डिफ़ॉल्ट रूप से both।
userOverridesवैकल्पिक: Era की लाइब्रेरी वाले नियम पर, उन सेटिंग के लिए आपके अपने मान जिन्हें वह बदलने देता है, नियम के पैटर्न जैसे ही प्रकार के टाइप किए गए ऑब्जेक्ट के रूप में। आपके बनाए नियमों पर इसे अनदेखा किया जाता है।
groupवैकल्पिक: वह ग्रुप जिसमें नियम रखा जाए, उसी सूची से जो बनाते समय मिलती है। बदलाव पूरी परिभाषा बदल देता है, इसलिए इसे छोड़ने पर नियम का ग्रुप हट जाता है — ग्रुप रखने के लिए उसका मौजूदा ग्रुप भेजें। Era की लाइब्रेरी वाले नियम पर, इसे छोड़ दें या वही ग्रुप भेजें जो उसके पास पहले से है।

रिस्पॉन्स · 200

{
  "rule": { … },
  "retroactiveStatus": null,
  "affectedTransactionCount": 0
}

नियम चालू करें

नियम को फिर से चालू करता है, ताकि वह नए ट्रांज़ैक्शन पर फिर चले। पहले से चालू नियम को चालू करने से कुछ नहीं बदलता। Era की लाइब्रेरी वाले नियम भी आपके अपने नियमों की तरह चालू और बंद किए जा सकते हैं। इसके लिए banking:read की जगह banking:write चाहिए, लेकिन यह सिर्फ़ Era में आपके नियम और ट्रांज़ैक्शन बदलता है: आपके बैंक में कुछ नहीं बदलता।

POST/banking/rules/{ruleId}/enable

ज़रूरी स्कोपbanking:write

क्वेरी पैरामीटर

versionवैकल्पिक: नियम का वह वर्ज़न जो आपने आख़िरी बार पढ़ा था। जाँच छोड़ने के लिए इसे न भेजें; भेजने पर, अगर तब से नियम बदल गया है तो कॉल 409 के साथ मना कर दी जाती है।

रिस्पॉन्स · 200

{
  "rule": { … },
  "retroactiveStatus": null,
  "affectedTransactionCount": 0
}

नियम बंद करें

नियम को बंद करता है, ताकि वह नए ट्रांज़ैक्शन पर न चले। उसकी परिभाषा बनी रहती है, और उसने जो पहले ही किया है वह तब तक रहता है जब तक आप revert_retroactively से उसे वापस न मांगें। पहले से बंद नियम को बंद करने पर वह बंद ही रहता है। इसके लिए banking:read की जगह banking:write चाहिए, लेकिन यह सिर्फ़ Era में आपके नियम और ट्रांज़ैक्शन बदलता है: आपके बैंक में कुछ नहीं बदलता।

POST/banking/rules/{ruleId}/disable

ज़रूरी स्कोपbanking:write

क्वेरी पैरामीटर

versionवैकल्पिक: नियम का वह वर्ज़न जो आपने आख़िरी बार पढ़ा था। जाँच छोड़ने के लिए इसे न भेजें; भेजने पर, अगर तब से नियम बदल गया है तो कॉल 409 के साथ मना कर दी जाती है।
revert_retroactivelyवैकल्पिक: नियम ने आपके ट्रांज़ैक्शन पर जो पहले ही किया है, उसे भी पलट देता है — उसकी लगाई कैटेगरी, टैग और दूसरे बदलाव। डिफ़ॉल्ट रूप से false, जिससे वे बदलाव जस के तस रहते हैं।

रिस्पॉन्स · 200

{
  "rule": { … },
  "retroactiveStatus": null,
  "affectedTransactionCount": 0
}

नियम हटाएँ

नियम को हमेशा के लिए हटा देता है। नियम को खोए बिना रोकने के लिए, उसे बंद कर दें। पाथ में दिया ruleId वही id है जो नियमों की सूची लौटाती है, और version वही होना चाहिए जो आपने आख़िरी बार पढ़ा था। Era की लाइब्रेरी वाले नियम हटाए नहीं जा सकते, सिर्फ़ बंद किए जा सकते हैं। इसके लिए banking:read की जगह banking:write चाहिए, लेकिन यह सिर्फ़ Era में आपके नियम और ट्रांज़ैक्शन बदलता है: आपके बैंक में कुछ नहीं बदलता। डिलीट के साथ revert_retroactively माँगना सिर्फ़ एक कोशिश है: अगर जवाब queue_full आए, तो नियम पहले ही हट चुका है और दोबारा कोशिश करने के लिए कुछ बचा नहीं। किसी नियम को हटाने और उसके किए को पलटने के लिए, पहले उसे revert_retroactively के साथ बंद करें — स्वीकार होने तक आप इसे दोहरा सकते हैं — फिर उसे हटाएँ।

DELETE/banking/rules/{ruleId}

ज़रूरी स्कोपbanking:write

क्वेरी पैरामीटर

versionवैकल्पिक: नियम का वह वर्ज़न जो आपने आख़िरी बार पढ़ा था। यह नियम के मौजूदा वर्ज़न से मेल खाना चाहिए, वरना कॉल 409 के साथ मना कर दी जाती है — इसलिए इसे छोड़ने से जाँच छूटती नहीं, बल्कि विफल हो जाती है।
revert_retroactivelyवैकल्पिक: नियम ने आपके ट्रांज़ैक्शन पर जो पहले ही किया है, उसे भी पलट देता है — उसकी लगाई कैटेगरी, टैग और दूसरे बदलाव। डिफ़ॉल्ट रूप से false, जिससे वे बदलाव जस के तस रहते हैं।

रिस्पॉन्स · 200

{
  "success": true,
  "retroactiveStatus": null,
  "affectedTransactionCount": 0
}