You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Bridge developer guide tells app developers to call /accounts?version=2, then says rate-limit warnings appear in the legacy "errors" array and that exceeding limits can disable Access Tokens.
That leaves v2 clients guessing:
should rate-limit warnings appear in errlist, errors, or both?
what errlist.code should a client expect for quota warnings?
should the protocol document this as part of GET /accounts, or is it Bridge-only behavior?
Max / client use case
I am integrating SimpleFIN into personal finance tooling. A sync scheduler needs to back off before it burns a user's Access Token. Today I can read the 24-requests/day guidance in the Bridge docs, but I cannot tell how a v2 client should detect warning vs disabled-token states without parsing deprecated errors text.
Evidence inspected
README.md: local build/serve only, no contribution policy.
No CONTRIBUTING or .github/ISSUE_TEMPLATE found in this repo.
protocol.md / live https://simplefin.org/protocol.html: GET /accounts documents 200, 402, and 403, plus v2 errlist, but not quota warnings, rate-limit backoff, disabled-token behavior, or a quota error code.
https://beta-bridge.simplefin.org/info/developers: tells developers to request /accounts?version=2, says /accounts responses include errlist, then says quota warnings appear in "errors" and exceeding limits disables Access Tokens.
Problem
The Bridge developer guide tells app developers to call
/accounts?version=2, then says rate-limit warnings appear in the legacy"errors"array and that exceeding limits can disable Access Tokens.That leaves v2 clients guessing:
errlist,errors, or both?errlist.codeshould a client expect for quota warnings?GET /accounts, or is it Bridge-only behavior?Max / client use case
I am integrating SimpleFIN into personal finance tooling. A sync scheduler needs to back off before it burns a user's Access Token. Today I can read the 24-requests/day guidance in the Bridge docs, but I cannot tell how a v2 client should detect warning vs disabled-token states without parsing deprecated
errorstext.Evidence inspected
README.md: local build/serve only, no contribution policy.CONTRIBUTINGor.github/ISSUE_TEMPLATEfound in this repo.protocol.md/ livehttps://simplefin.org/protocol.html:GET /accountsdocuments200,402, and403, plus v2errlist, but not quota warnings, rate-limit backoff, disabled-token behavior, or a quota error code.https://beta-bridge.simplefin.org/info/developers: tells developers to request/accounts?version=2, says/accountsresponses includeerrlist, then says quota warnings appear in"errors"and exceeding limits disables Access Tokens.balances-only, including Bridge-relevant sync behavior.Expected behavior
The docs should say how a v2 client detects quota warning and disabled-token states before user sync breaks.
Suggested implementation shape
errlistshape and error code, for example agen.*code.errorsis still emitted during migration, say whether clients should read botherrlistanderrors.Duplicate search
I searched the repo corpus with:
gh search issues --repo simplefin/simplefin.github.com --state open --include-prs --limit 200gh search issues --repo simplefin/simplefin.github.com --state closed --include-prs --limit 200The repo currently returns 13 open and 24 closed issues/PRs, so the 200-result limit exhausts both sets.
Specific terms checked:
rate limit,quota,warning messages,errors array,errlist rate,Access Tokens disabled,24 requests,90 days,start-date end-date 90,limits.Result: no covering issue found.
errors arrayonly found #38, which coveredmsgvsmessage, not quota semantics.Happy to open a small docs PR after the intended v2 behavior/code is confirmed.