Update Live Tennis API plugin to v0.0.2

[bensynapse]

Plugin Submission

Plugin information

• Author: livetennisapi
• Plugin name: livetennisapi
• Version: 0.0.2
• Source repository: https://github.com/livetennisapi/livetennisapi-dify-plugin
• Contact: support@livetennisapi.com

Submission type

• New plugin
• Version update

What changed

Version update, 0.0.1 → 0.0.2. This release narrows the plugin to the Live
Tennis API's six documented public endpoints, one tool each, and fixes two
defects in 0.0.1. Twelve tools become six.

Tool	Endpoint
get_matches	GET /matches?status=&tour=&limit=
get_match	GET /matches/{id}
get_match_score	GET /matches/{id}/score
search_players	GET /players?search=&limit=
get_player	GET /players/{id}
get_fixtures	GET /fixtures?limit=

Removed (they wrapped endpoints outside the documented public surface, or
inferred state by trial): get_match_events, get_match_odds,
get_match_analysis, check_api_status. The market and analysis data is not
lost — the API embeds both in GET /matches/{id}, and get_match still returns
them.

Merged: get_live_matches, get_upcoming_matches and get_recent_results
become the single get_matches with a status parameter, because they were
three tools over one endpoint. (get_recent_results was additionally reading a
different, undocumented path.)

Added: the documented tour filter (atp / wta / challenger / itf)
on get_matches.

Changed — the API key is now sent in the x-api-key header. 0.0.1 sent
Authorization: Bearer, inherited from the client library's default. Both work:
the API accepts Authorization: Bearer, a raw Authorization value, and
x-api-key. So this is an alignment with the documented convention, not a
fix for a broken 0.0.1 — 0.0.1 authenticates correctly today. The header is now
set explicitly rather than inherited, and the test suite asserts it on the wire
so a library default can't silently move it. PRIVACY.md is updated to match.

Fixed — get_match's declared output_schema was structurally wrong. A
mis-indented block left market.prices.items null and leaked two junk keys into
market.properties. It was valid YAML, so it parsed; it just parsed into the
wrong shape, and a workflow reading the schema saw the wrong contract.

This is a breaking change for existing 0.0.1 workflows — tool names change.
The shipped README carries a migration section.

Every tool is a GET. The plugin has no write path of any kind.

Two things worth a reviewer's attention:

1. No tool raises. A rejected key, an unknown id, a rate limit, a tier wall
   or an unusable parameter all return ok: false with a reason and a
   plain-English message, so a workflow node never dies on a state the author
   should be branching on. Handed a bare 403, an agent invents a reason or
   retries pointlessly; handed a sentence, it relays the remedy and moves on.
2. Each tool emits both halves: a text message for a model to read, and a
   JSON message with the identical facts for a workflow to consume without
   re-parsing English. Both are declared in each tool's output_schema.

Risk level

• Low risk
• Medium risk
• High risk

Required checks

• I have read and followed the Marketplace submission requirements.
• I have read and comply with the Plugin Developer Agreement.
• I tested this plugin on Dify Community Edition and Dify Cloud, or documented any limitation below. — limitation documented in Reviewer notes
• The package contains only files needed at runtime.
• The package does not contain secrets, local credentials, .env files, .git directories, virtual environments, caches, logs, or IDE files.
• The package does not contain executables or bundled binaries, or I explained why they are required below.
• The plugin README includes setup steps, usage instructions, required APIs or credentials, connection requirements, and the source repository link.
• The plugin includes PRIVACY.md or a hosted privacy policy, and manifest.yaml references it.
• All user-facing text is primarily in English, with any localized README files following the i18n guidance.

Security and privacy notes

Vendor disclosure. I am the operator of the Live Tennis API, the service this
plugin wraps, and the publisher of the livetennisapi PyPI package it depends
on. This is a first-party integration, not a third-party wrapper. Stating it
plainly so the dependency and the risk classification can be judged with that in
view.

Network destinations. One, fixed and documented:
https://api.livetennisapi.com/api/public/v1. It is a module constant in
livetennisapi_client.py, deliberately not exposed as a credential or a
tool parameter, so the destination cannot be redirected by a user, a workflow or
a model. No arbitrary URL fetching, proxying, crawling or webhook forwarding.

Sensitive capabilities: none. No command or code execution, no shell, no
SQL, no database access, no SSH/SFTP, no filesystem operations, no browser
automation, no bundled binaries. Every tool issues a GET and formats the
response.

Credentials. A single api_key (secret-input), sent in the x-api-key
header to the one host above. It is never logged, never included in an error
message, and never returned in tool output. The plugin writes no files and keeps
no cache or state between invocations.

Input constraints. limit is coerced and clamped to 1–200 (the API's own
ceiling) rather than rejected. status and tour are case-folded and matched
against a fixed allow-list, falling back to a default instead of being forwarded.
Id parameters are coerced to integers and answered with a normal result if
unusable — no request leaves the plugin for a bad parameter. Requests carry a
30-second timeout.

Note on the previous version's risk profile. 0.0.1 included a
get_match_odds tool reporting match-winner market prices, which I flagged for
re-classification at the time. That tool is removed in 0.0.2. Market prices
now appear only as an optional embedded block inside get_match, still
read-only reporting of publicly published prices. The plugin cannot place,
modify, settle or transact anything and moves no money or assets; there is no
write path to any venue. I have kept the Low risk label on that basis — happy for
it to be raised if you read it differently.

Data returned is public professional-sport information: player names,
nationalities, rankings, handedness, dates of birth, match results and scores. No
Dify user identity, conversation content, prompt or workflow variable is sent
anywhere. See PRIVACY.md.

Dependencies: two lines.

[crazywoola]

✅ LGTM

Decision: Approve

Local Check Results

Check	Status	Detail	Required action
PR content language	✅ Pass	PR title/body CJK ratio=0.0% (zh=0, en=5220, ignored_zh=0, allowed_zh<=0)	None.
Project structure	✅ Pass	All expected files present: manifest.yaml, README.md, PRIVACY.md. _assets/: yes.	None.
Manifest author	✅ Pass	author is valid.	None.
Icon validation	✅ Pass	icon exists: _assets/icon.png	None.
Version check	✅ Pass	version 0.0.2 is available.	None.
README language	✅ Pass	README.md CJK ratio=0.0% (zh=0, en=3574, allowed_zh<=0)	None.
PRIVACY.md	✅ Pass	PRIVACY.md exists and is non-empty.	None.
Dependency install	✅ Pass	requirements installed successfully.	None.
dify_plugin version	✅ Pass	dify_plugin version 0.10.0 satisfies >= 0.9.0.	None.
Install test	✅ Pass	plugin install test passed.	None.
Packaging test	✅ Pass	packaging check passed.	None.