Native plugin routes
Enabled plugins register provider protocol paths throughmeta.routes. JSON / form / multipart requests, response fields, and query paths depend on each plugin. Use gateway Bearer credentials. Paths may have provider prefixes; replacing the provider hostname is insufficient. Obtain the plugin key, version, model, actual routes, and a valid request from the operator. An installed plugin list is not a guarantee for every deployment.
Native routes differ from /v1/tasks/{plugin_key}: native routes run native decoders and presenters, while the latter is a legacy generic entry for normalized JSON. A third surface consists of host protocols /v1/responses, /v1/images/*, and /v1/videos, explicitly claimed by plugins. Responses sync / stream / background support is declared separately.
Use returned IDs with tasks for status and artifacts. Retrieval is not guaranteed for discarded results. Private provider IDs, dashboard database row IDs, and public task IDs are not interchangeable. There is no uniform webhook guarantee; use bounded polling.
Coverage checks
scripts/route-coverage.json inventories core relay, video, task, and host protocol routes with links to bilingual references or explicit boundaries. In the main repository, check:content compares route declarations and fails on additions or removals to prompt mapping updates. After export to a standalone docs repository, it still checks inventory/page links but explicitly skips source comparison when backend files are absent. It does not prove complete DTO, plugin, or runtime compatibility.
See API coverage for unimplemented features. Management APIs, organizations, account authentication, and plugin authoring are outside inference integration documentation.
阅读中文版
Prompt caching · Reasoning models · Context management