FINERACT-2081: add api verification workflow

[budaidev]

Description

Describe the changes made and why they were made. (Ignore if these details are present on the associated Apache Fineract JIRA ticket.)

Checklist

Please make sure these boxes are checked before submitting your pull request - thanks!

• Write the commit message as per our guidelines
• Acknowledge that we will not review PRs that are not passing the build ("green") - it is your responsibility to get a proposed PR to pass the build, not primarily the project's maintainers.
• Create/update unit or integration tests for verifying the changes made.
• Follow our coding conventions.
• Add required Swagger annotation and update API documentation at fineract-provider/src/main/resources/static/legacy-docs/apiLive.htm with details of any API changes
• This PR must not be a "code dump". Large changes can be made in a branch, with assistance. Ask for help on the developer mailing list.

Your assigned reviewer(s) will follow our guidelines for code reviews.

[vidakovic]

@budaidev how do we fix then when something in the current openapi descriptor when some entryreally doesn't make any sense? how's that then supposed to work? I understand that this plugin is supposed to halt everything if there is a diff between the baseline and the current descriptor... but this covers the whole thing... and there are some corners that are really in need of some touch ups. I agree applying this to the critical path endpoints... but let's say SMS campaign? thanks

[budaidev]

@vidakovic that's an excellent question. The basic idea, that this check is not a strict must-have check, but more like an informative check. If we break a working API solution, we should be aware of it.
However there are still different options to tackle this problem, if we want to have a green pipeline:

1. we could exclude certain pathes, for example:

swaggerBrake {
      excludedPaths = [
          '/v1/smscampaigns',
          '/v1/email',
          '/v1/twofactor',
      ]
  }

2. We can mark unstable APIs as beta in swagger. This makes the script skip these endpoints.
3. It is also possible to add a list of allowed breaking changes in the configuration, which is a possibility, however not the best for long term.

You can choose any of these solutions listed, or you can decide to just ignore this error as a whole. It's a good idea to include this topic to the documentation once it is ready.

[Aman-Mittal]

I really like the breaking part, curious to see how it shows comment as an example. Like temporarily pushing breaking change to trigger check?

[budaidev]

The comment part ia tricky because it doesn't have permission in this PR, only after the merge. I tested the breaking change and the summary worked fine.
You can also make a commit to check and revert after you see the result, it won't break anything in the end.

[Aman-Mittal]

Understandable as it will show only after merge, but is there is any PR you created in your fork so that i can cross verify.

[budaidev]

You can check it on the fork directly (now the develop is out sync, so it shows error):
openMF#191

[Aman-Mittal]

Thanks for sharing

…

On Sun, Feb 22, 2026, 2:24 AM budaidev ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In .github/workflows/verify-api-backward-compatibility.yml <#5515 (comment)>: > + body = '\n'.join(lines) + + with open(os.environ['GITHUB_OUTPUT'], 'a') as f: + f.write('has_report=true\n') + + report_file = '${GITHUB_WORKSPACE}/breaking-changes-report.md' + with open(report_file, 'w') as f: + f.write('## Breaking API Changes Detected\n\n') + f.write(body) + f.write('\n\n> **Note:** This check is informational only and does not block the PR.\n') + + # Also write to step summary + with open(os.environ['GITHUB_STEP_SUMMARY'], 'a') as f: + f.write('## Breaking API Changes Detected\n\n') + f.write(body) + f.write('\n\n> **Note:** This check is informational only and does not block the PR.\n') You can check it on the fork directly (now the develop is out sync, so it shows error): openMF#191 <openMF#191> — Reply to this email directly, view it on GitHub <#5515 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHV6TAZMY5BRKI3SVQMJF3D4NDAWRAVCNFSM6AAAAACVTN4DKSVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTQMZWGAYDONBVG4> . You are receiving this because you commented.Message ID: ***@***.***>

[adamsaghy]

LGTM