46 lines
1.7 KiB
Markdown
46 lines
1.7 KiB
Markdown
|
# OpenWebUI Community API Patterns
|
||
|
|
|
||
|
|
## Post Data Structure Variations
|
||
|
|
|
||
|
|
When fetching posts from the OpenWebUI Community API (`https://api.openwebui.com/api/v1/posts/...`), the structure of the `data` field varies significantly depending on the `type` of the post.
|
||
|
|
|
||
|
|
### Observed Mappings
|
||
|
|
|
||
|
|
| Post Type | Data Key (under `data`) | Usual Content |
|
||
|
|
|-----------|-------------------------|---------------|
|
||
|
|
| `action` | `function` | Plugin code and metadata |
|
||
|
|
| `filter` | `function` | Filter logic and metadata |
|
||
|
|
| `pipe` | `function` | Pipe logic and metadata |
|
||
|
|
| `tool` | `tool` | Tool definition and logic |
|
||
|
|
| `prompt` | `prompt` | Prompt template strings |
|
||
|
|
| `model` | `model` | Model configuration |
|
||
|
|
|
||
|
|
### Implementation Workaround
|
||
|
|
|
||
|
|
To robustly extract metadata (like `version` or `description`) regardless of the post type, the following heuristic logic is recommended:
|
||
|
|
|
||
|
|
```python
|
||
|
|
def _get_plugin_obj(post: dict) -> dict:
|
||
|
|
data = post.get("data", {}) or {}
|
||
|
|
post_type = post.get("type")
|
||
|
|
|
||
|
|
# Priority 1: Use specific type key
|
||
|
|
if post_type in data:
|
||
|
|
return data[post_type]
|
||
|
|
|
||
|
|
# Priority 2: Fallback to common keys
|
||
|
|
for k in ["function", "tool", "pipe"]:
|
||
|
|
if k in data:
|
||
|
|
return data[k]
|
||
|
|
|
||
|
|
# Priority 3: First available key
|
||
|
|
if data:
|
||
|
|
return list(data.values())[0]
|
||
|
|
|
||
|
|
return {}
|
||
|
|
```
|
||
|
|
|
||
|
|
### Gotchas
|
||
|
|
- Some older posts or different categories might not have a `version` field in `manifest`, leading to empty strings or `N/A` in reports.
|
||
|
|
- `slug` should be used as the unique identifier rather than `title` when tracking stats across history.
|