canonical: https://jentic.com/apis/gotify.net/gotify

# Gotify REST-API

Jentic publishes the only available OpenAPI specification for Gotify REST-API, keeping it validated and agent-ready. Gotify is a self-hosted push notification server, and this REST API exposes 32 endpoints to send messages, manage applications and clients, configure plugins, and administer users. Two token types govern access: appTokens (used by senders such as scripts and services) and clientTokens (used by receivers such as the Android app). Tokens may travel in the X-Gotify-Key header, the token query parameter, or as a Bearer Authorization header.

## For AI agents

Send push messages to a self-hosted Gotify server, manage application and client tokens, and configure plugins for personal or fleet alerting.

## Scope

Does not handle SMS, email, or hosted push delivery - use for self-hosted Gotify message delivery and server administration only.

## Capabilities

- Send a push message to a specific application using an appToken
- Create or rotate application tokens for a service or shell script
- Create client tokens for receiving devices such as the Android app
- List and delete delivered messages from the server backlog
- Upload an application icon to brand notifications in the receiver UI
- Enable, disable, or configure server plugins via /plugin endpoints
- Update the current user's password and inspect the server health endpoint

## Use cases

### Self-Hosted Server and Job Alerts

Send push notifications from cron jobs, CI pipelines, or systemd units to a self-hosted Gotify server, then receive them on phone or desktop without depending on a third-party push provider. POST /message with an appToken and priority drives the alert; clientTokens authenticate the receiving devices.

Example prompt: POST /message with title 'Backup failed', message 'Daily backup exited with code 2', priority 8, using the appToken bound to the 'backups' application.

### Application and Token Management

Provision a new appToken per service or script so the operator can rotate or revoke tokens individually without rebooting the whole alert pipeline. The /application endpoints create, update, and delete applications, while /client endpoints manage receiving devices. Icons can be uploaded per application for visual triage in the receiver UI.

Example prompt: Create a new application named 'home-assistant', capture the returned appToken, upload icon ha.png to `/application/{id}/image`, and store the token in the secret manager.

### Plugin-Driven Workflows

Use Gotify plugins to extend the server with bridges (matrix, telegram, pushover) or transform messages in flight. The /plugin endpoints list installed plugins, enable or disable them per user, and accept configuration updates so workflows can be re-tuned without restarting the server.

Example prompt: Enable plugin id 3 ('telegram-bridge') for the current user, then PUT `/plugin/3/config` with the chat_id and bot_token configuration.

### AI Agent Personal Alerts

An AI agent that monitors logs, prices, or feeds can push direct alerts to the operator's Gotify server. Through Jentic, the agent finds POST /message by intent and uses a vault-stored appToken, so a long-lived push key never appears in the agent's prompt or tool list.

Example prompt: When an agent monitor detects a price drop on watch_id 42, POST /message with priority 5 and title 'Price drop' to the 'watcher' application.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/message` | Send a push message |
| GET | `/message` | List recent messages |
| POST | `/application` | Create an application (sender) |
| POST | `/application/{id}/image` | Upload an application icon |
| POST | `/client` | Create a client (receiver) |
| GET | `/health` | Check server health |
| GET | `/plugin` | List installed plugins |
| POST | `/plugin/{id}/enable` | Enable a plugin |

## Key resources

- **Messages** — Send, list, and delete push messages
- **Applications** — Sender entities with their own appTokens and icons
- **Clients** — Receiver entities and their clientTokens
- **Users** — Manage server users and passwords (admin)
- **Plugins** — Inspect, enable, disable, and configure plugins
- **Health** — Server liveness and readiness probe

## Why Jentic

- **Setup:** Wiring Gotify by hand means pointing at your own self-hosted server, choosing between its app-token, client-token, and basic auth schemes, and setting the X-Gotify-Key header correctly per call. Through Jentic you install once, import Gotify from the API Directory, store the token once, and your agent calls it.
- **Permission scoping:** Gotify puts the application and plugin id in the URL path (`/application/{id}`, `/plugin/{id}/enable`), so a rule can pin your agent to one application. You choose the operations it may call, so destructive ones like application deletion are not included unless you add them.
- **Credential handling:** Your Gotify app or client token is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'send a push notification to my phone' or 'create a new application', and Jentic returns the matching Gotify operation with its input schema so the agent calls the right endpoint without reading the reference docs.

## Related APIs

- **Pushover** — Hosted push notification service for individuals and teams
- **Pushbullet** — Cross-device push and clipboard sharing
- **Firebase Cloud Messaging** — Google's hosted push platform for mobile and web at scale

## FAQ

### Why is there no official OpenAPI spec for Gotify REST-API?

Gotify does not publish an OpenAPI specification through a centralized catalogue. Jentic generates and maintains this spec so that AI agents and developers can call Gotify REST-API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Gotify REST-API use?

Two token types: appTokens for senders (scripts, services) and clientTokens for receivers (apps, browsers). Tokens travel in the X-Gotify-Key header, the token query parameter, or a Bearer Authorization header. Basic auth is also accepted, mainly for creating an initial clientToken. Jentic stores tokens in the encrypted vault.

### How do I send a push notification with the Gotify REST-API?

POST /message with the appToken in X-Gotify-Key, supplying message, optional title, and optional priority (0 silent through 10 highest). The server distributes the message to all clientTokens registered with that user, and connected receivers see it instantly via WebSocket.

### Can I rotate Gotify application tokens through the API?

Yes. Create a new application via POST /application to receive a fresh appToken, update senders to use the new token, then DELETE the old application. This pattern lets each script have its own scoped token without restarting the Gotify server.

### How do I integrate the Gotify REST-API with an AI agent through Jentic?

Run pip install jentic, search 'send a push notification' to find POST /message, load the schema, and execute. Jentic injects the appToken header from the vault. Get started with Jentic One, the self-hosted execution layer.

### Can I limit what my agent is allowed to do with the Gotify REST-API?

Yes. Because you run Jentic One yourself, you decide which Gotify operations your agent may call, so you can expose POST /message for sending alerts while leaving destructive calls like DELETE /application out unless you choose to add them. Gotify carries the application and plugin id in the URL path, as in `/application/{id}` and `/plugin/{id}/enable`, so your own rules can pin the agent to a single application rather than the whole server. Your appToken or clientToken is stored once by your instance and injected only at execution time, so the agent never sees the raw credential.