Camunda Community Hub extension proposal
Extension description
camunda-8-connector-livetennis is a Camunda 8 outbound connector for the
Live Tennis API, a commercial REST API for live and historical
tennis data. It exposes six read-only operations on a single BPMN service task, so a process
can read live scores, matches, players and fixtures without anyone writing and operating a
custom job worker.
Operations (each an @Operation on one OutboundConnectorProvider, selected by the
operation dropdown in the element template):
| Operation |
Call |
| List matches |
GET /matches?status=live|upcoming|completed&tour=&limit= |
| Get match by ID |
GET /matches/{id} |
| Get live score for a match |
GET /matches/{id}/score |
| Search players |
GET /players?search=&limit= |
| Get player by ID |
GET /players/{id} |
| List fixtures |
GET /fixtures?limit= |
Everything is a GET; the connector cannot mutate anything.
Disclosure — vendor: I am part of the team that operates the Live Tennis API. This connector
is therefore a first-party integration for a commercial API with a free tier. I have no
affiliation with Camunda. The connector is Apache-2.0 and contains no telemetry, no analytics,
and no calls to any host other than the API base URL configured on the task (which defaults to
https://api.livetennisapi.com/api/public/v1 and is overridable, primarily so it can be pointed
at a mock in tests). Flagging this up front so the DevRel team can weigh vendor-authored
extensions however it prefers.
Disclosure — AI assistance: this connector was written with substantial help from an AI
coding assistant (Claude). Every line has been read, built and tested by a human; the build,
the 21 tests and the element-template schema validation described below are real, reproducible
commands, not generated prose. I could not find any Camunda or Community Hub policy on
AI-assisted contributions, so I am disclosing voluntarily — happy to follow whatever convention
the team prefers, and happy to walk through any part of the code.
Repository (already built, tested and public — per step 4 of
creating-new-extensions.md):
<REPO_URL>
Current state:
- Connector SDK 8.9.6, Java 21,
OutboundConnectorProvider + @Operation (the current SDK
style, mirroring camunda/connector-template and camunda-8-connector-couchbase).
org.camunda.community groupId with the community-hub-release-parent:2.1.0 parent POM, as
required by groupId.md;
release workflow already wired to camunda-community-hub/community-action-maven-release@v2.- Element template generated from the annotations by
element-template-generator-maven-plugin and committed at
element-templates/livetennis-connector.json.
mvn clean verify is green: 21 tests, 0 failures, 0 errors.
Suggested use case
The recurring pattern is "wait for a real-world event, then continue the process", which is
awkward to express without either a connector or a bespoke worker:
- Poll a live match until it finishes. A service task calls Get live score for a match in
a loop with an intermediate timer; a gateway on response.body decides whether to continue
waiting or move on. Typical for settlement, notification and content-publishing workflows.
- Enrich a process instance. Search players / Get player by ID to attach player detail
to a case (media production, sponsorship approval, ticketing).
- Schedule work from fixtures. List fixtures at the start of a day to spawn one
subprocess per upcoming match.
- Human-in-the-loop review of live data. List matches with
status=live to populate a
user task form for an operator.
Anyone doing 1–4 today writes a job worker, redeploys it to change a filter, and owns its
retry/backoff behaviour. The connector moves all of that into the model.
Configuration
Runtime secret. The API key is sent as the x-api-key header. The element template's
API key property defaults to {{secrets.LIVE_TENNIS_API_KEY}}, so the key is resolved by
the connector runtime's secret provider and never stored in the BPMN file. Self-managed:
Current state, stated plainly: the connector is built and green locally — mvn clean verify succeeds, 21 tests pass (16 of them WireMock tests driving the real SDK dispatch path, covering header/query construction, {{secrets.*}} resolution and 401/404/429/503 error mapping), and the element template validates against Camunda's published JSON schema on two independent stacks (Java networknt in-build and Python jsonschema against the live-fetched schema).
The source repo is not public yet. I know creating-new-extensions.md puts repo creation before the proposal, and that repos enter the org by transfer rather than through this issue — I'm opening the conversation first because I'd rather hear that a tennis-data connector isn't wanted before publishing a repo and asking anyone to review a transfer. Say the word and I'll publish it and open the transfer request.
Disclosures: I'm the vendor of the Live Tennis API, so this is a first-party connector. The implementation was written with AI assistance (Claude Code) and human-reviewed. Neither appears to be required disclosure here — I couldn't find any AI policy in this repo or in camunda/camunda — but both seem worth saying up front. I have not yet signed the CLA; I'll do that when it's actually needed (its full text is behind a login, and I'd like to read it first).
Camunda Community Hub extension proposal
Extension description
camunda-8-connector-livetennisis a Camunda 8 outbound connector for theLive Tennis API, a commercial REST API for live and historical
tennis data. It exposes six read-only operations on a single BPMN service task, so a process
can read live scores, matches, players and fixtures without anyone writing and operating a
custom job worker.
Operations (each an
@Operationon oneOutboundConnectorProvider, selected by theoperationdropdown in the element template):GET /matches?status=live|upcoming|completed&tour=&limit=GET /matches/{id}GET /matches/{id}/scoreGET /players?search=&limit=GET /players/{id}GET /fixtures?limit=Everything is a
GET; the connector cannot mutate anything.Disclosure — vendor: I am part of the team that operates the Live Tennis API. This connector
is therefore a first-party integration for a commercial API with a free tier. I have no
affiliation with Camunda. The connector is Apache-2.0 and contains no telemetry, no analytics,
and no calls to any host other than the API base URL configured on the task (which defaults to
https://api.livetennisapi.com/api/public/v1and is overridable, primarily so it can be pointedat a mock in tests). Flagging this up front so the DevRel team can weigh vendor-authored
extensions however it prefers.
Disclosure — AI assistance: this connector was written with substantial help from an AI
coding assistant (Claude). Every line has been read, built and tested by a human; the build,
the 21 tests and the element-template schema validation described below are real, reproducible
commands, not generated prose. I could not find any Camunda or Community Hub policy on
AI-assisted contributions, so I am disclosing voluntarily — happy to follow whatever convention
the team prefers, and happy to walk through any part of the code.
Repository (already built, tested and public — per step 4 of
creating-new-extensions.md):
<REPO_URL>
Current state:
OutboundConnectorProvider+@Operation(the current SDKstyle, mirroring
camunda/connector-templateandcamunda-8-connector-couchbase).org.camunda.communitygroupId with thecommunity-hub-release-parent:2.1.0parent POM, asrequired by groupId.md;
release workflow already wired to
camunda-community-hub/community-action-maven-release@v2.element-template-generator-maven-pluginand committed atelement-templates/livetennis-connector.json.mvn clean verifyis green: 21 tests, 0 failures, 0 errors.Suggested use case
The recurring pattern is "wait for a real-world event, then continue the process", which is
awkward to express without either a connector or a bespoke worker:
a loop with an intermediate timer; a gateway on
response.bodydecides whether to continuewaiting or move on. Typical for settlement, notification and content-publishing workflows.
to a case (media production, sponsorship approval, ticketing).
subprocess per upcoming match.
status=liveto populate auser task form for an operator.
Anyone doing 1–4 today writes a job worker, redeploys it to change a filter, and owns its
retry/backoff behaviour. The connector moves all of that into the model.
Configuration
Runtime secret. The API key is sent as the
x-api-keyheader. The element template'sAPI key property defaults to
{{secrets.LIVE_TENNIS_API_KEY}}, so the key is resolved bythe connector runtime's secret provider and never stored in the BPMN file. Self-managed:
Current state, stated plainly: the connector is built and green locally —
mvn clean verifysucceeds, 21 tests pass (16 of them WireMock tests driving the real SDK dispatch path, covering header/query construction,{{secrets.*}}resolution and 401/404/429/503 error mapping), and the element template validates against Camunda's published JSON schema on two independent stacks (Javanetworkntin-build and Pythonjsonschemaagainst the live-fetched schema).The source repo is not public yet. I know
creating-new-extensions.mdputs repo creation before the proposal, and that repos enter the org by transfer rather than through this issue — I'm opening the conversation first because I'd rather hear that a tennis-data connector isn't wanted before publishing a repo and asking anyone to review a transfer. Say the word and I'll publish it and open the transfer request.Disclosures: I'm the vendor of the Live Tennis API, so this is a first-party connector. The implementation was written with AI assistance (Claude Code) and human-reviewed. Neither appears to be required disclosure here — I couldn't find any AI policy in this repo or in
camunda/camunda— but both seem worth saying up front. I have not yet signed the CLA; I'll do that when it's actually needed (its full text is behind a login, and I'd like to read it first).