native-trigger

Implements native trigger integrations for Windmill across Rust backend and Svelte frontend.

Updated May 28, 2026
One-click install
npx skills add https://github.com/kma-core/windmill --skill native-trigger-kma-core
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: native-trigger
Source: https://github.com/kma-core/windmill/tree/main/.agents/skills/native-trigger
Command: npx skills add https://github.com/kma-core/windmill --skill native-trigger-kma-core

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Adding a new native trigger service to Windmill requires coordinated changes across database migrations, Rust backend crates, and Svelte frontend components, and missing any step breaks the integration. ## Core Features & Use Cases - Step-by-step implementation guide: Covers 18 steps from SQL enum migrations through the External trait implementation to frontend registry updates. - Architectural patterns: Documents the three-table OAuth token storage, create lifecycle paths (short vs. update+get), channel renewal, and external state reconciliation. - Use Case: When adding a new webhook-based service like a file storage provider to Windmill, follow this guide to implement the Rust service module, register routes, wire up OAuth, and build the Svelte configuration form. ## Quick Start Use the native-trigger skill to add a new native trigger service integration to Windmill.

Frequently Asked Questions about native-trigger

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I add a new native trigger service to Windmill?

Create a SQL migration adding the service to the native_trigger_service, TRIGGER_KIND, and job_trigger_kind enums, implement the External trait in a new module under backend/windmill-native-triggers/src, register routes and sync logic, then add frontend registry entries and a Svelte form component.

What is the External trait in windmill-native-triggers?

The External trait defines the contract every native trigger service implements, including create, update, get, delete, exists, and maintain_triggers methods plus associated types for service config, trigger data, and OAuth data. It lives in backend/windmill-native-triggers/src/lib.rs.

How are OAuth tokens stored for Windmill native triggers?

OAuth tokens use a three-table pattern: workspace_integrations holds base_url and client credentials metadata, the variable table stores the encrypted access_token, and the account table stores the refresh_token. The decrypt_oauth_data() function assembles these into a unified OAuthConfig struct.

When should a trigger service use the update+get pattern versus the short create path?

Use the short path by overriding service_config_from_create_response() to return Some(config) when the external_id is known before creation, as Google does. Use the default update+get pattern when the remote service assigns the external_id and the webhook URL must be corrected afterward, as Nextcloud does.

How does background sync work for expiring webhook channels?

Services with expiring channels implement renewal logic in maintain_triggers() instead of using reconcile_with_external_state(). For example, Google Drive channels expire in 24 hours and are renewed when under one hour remains, while Calendar channels renew when under one day remains.