# A native Flow Registry Client for Apache NiFi 2, built for Gitea's actual API

**URL:** <https://forum.gitea.com/t/a-native-flow-registry-client-for-apache-nifi-2-built-for-giteas-actual-api/12376>\
**Category:** Ecosystem\
**Created:** [August 20, 2026, 1:05pm UTC](https://forum.gitea.com/t/a-native-flow-registry-client-for-apache-nifi-2-built-for-giteas-actual-api/12376 "2026-08-20T13:05:51Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Vinz2168](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.gitea.com/vinz2168/32/7501_2.png) [@Vinz2168](https://forum.gitea.com/u/Vinz2168)\
**Post date:** [August 20, 2026, 1:05pm UTC](https://forum.gitea.com/t/a-native-flow-registry-client-for-apache-nifi-2-built-for-giteas-actual-api/12376/1 "2026-08-20T13:05:51Z")

</div>

Apache NiFi Registry is being removed in NiFi 3.0, and NiFi 2 already supports Git-based Flow Registry Clients (currently GitHub, GitLab, Bitbucket, Azure DevOps officially). I wanted a self-hosted backend, so I tried pointing NiFi’s `GitHubFlowRegistryClient` at a Gitea instance, relying on Gitea’s GitHub API compatibility.

It mostly worked — repository access, tokens, authentication all checked out — until branch listing consistently failed with “no read access”, even though `GET /repos/{owner}/{repo}` clearly returned full read/write/admin permissions.

Root cause: the `/collaborators/{username}/permission` endpoint. GitHub’s version only ever returns `admin`, `write`, `read`, or `none`. Gitea returns `"owner"` for the repository owner — a distinct role above admin in Gitea’s permission model (only the owner can transfer/delete a repo). NiFi’s GitHub client has no case for that value and silently treats it as no access.

Rather than patch Gitea to remap that one string (and carry a fork across every future upgrade), I wrote a native Flow Registry Client against Gitea’s real API instead — same `AbstractFlowRegistryClient` SPI the GitHub/GitLab/Bitbucket clients use, but with access validation based on the boolean `permissions.pull/push/admin` fields from the repo endpoint, skipping the incompatible collaborators/permission check entirely.

Tested on NiFi 2.11: flow creation, versioning, pushing new snapshots, and restoring previous versions all work end to end.

Repo: [GitHub - Vinz2168/nifi-gitea-bundle: A native GiteaFlowRegistryClient for Apache NiFi 2.11, speaking Gitea's own REST API v1 · GitHub](https://github.com/Vinz2168/nifi-gitea-bundle)

Full writeup with the debugging process (including the curl output that exposed the `"owner"` vs `admin/write/read/none` mismatch): [link all’articolo LinkedIn]

Curious whether this is a known gap for anyone else who’s tried wiring GitHub-compatible clients against Gitea, or if there’s appetite for upstreaming a native Gitea client into `apache/nifi` directly.