Finkkle Igno

Build and Publish Custom Plugins for Finkkle Igno

Create custom plugins that wrap your own APIs, webhooks, or scripts and make them available as tools inside Finkkle Igno conversations.

The Personal segment of the Finkkle Igno plugin catalog is designed for custom plugins. A custom plugin wraps your own API endpoint, webhook listener, or script behind a declared schema — making it available to Igno as a callable tool in any conversation.

What you can build

  • API wrapper — expose a REST endpoint as a Igno tool (e.g., query your internal knowledge base, fetch live pricing, trigger a workflow)
  • Webhook listener — receive a Igno-generated payload and act on it in your own system
  • Local script — run a specific script in the Terminal Executor sandbox and surface its output

Create a custom plugin

  1. Describe the operation

    Write a clear, plain-language description of what your plugin does. Igno uses this to decide when the plugin is relevant: > *"Fetches the current inventory count for a given SKU from the warehouse API."*

  2. Declare inputs and outputs

    Define the plugin's schema: * Required inputs — fields the user must provide (e.g., sku, date_range) * Optional inputs — fields with defaults * Output format — what the plugin returns (JSON, Markdown, a file) * Failure responses — what Igno should show when the plugin errors

  3. Set permissions

    Choose the smallest set of permissions your plugin needs: | Permission type | Use when | | --------------- | ------------------------------------- | | Read | Fetching data without side effects | | Write | Creating or updating records | | Send | Dispatching messages or notifications | | Account | Accessing a connected user account | Default to read-only. Add write or send permissions only when necessary.

  4. Test in the builder sandbox

    Use the plugin builder sandbox to test with representative, non-sensitive data. Verify: * The input schema is correct * The output is understandable to someone other than the author * Error cases return actionable messages * The audit log entry is clear

  5. Publish

    Once the result and action log are clear and correct, publish the plugin to your personal catalog. It becomes available immediately in your Igno conversations.

Authentication

For plugins that call protected APIs, declare the authentication boundary in the schema:

  • API key — store the key in the plugin configuration, not in conversation prompts
  • OAuth — follow the standard OAuth authorization flow; Igno handles token storage
  • No auth — for public endpoints or local scripts
NoticeNever include API keys, tokens, or credentials in conversation prompts or plugin descriptions. Store credentials in the plugin's secure configuration, not in the schema or description text.

Best practices

  • Keep scope narrow — one plugin per logical operation. Avoid building a multi-purpose plugin; split it into focused tools instead.
  • Test with realistic data — use representative but non-sensitive samples in the sandbox.
  • Write clear error messages — when the plugin fails, the message should tell the user exactly what to fix.
  • Use draft-only for side effects — if your plugin creates or modifies records, default to draft mode so users approve before anything changes.
  • Document the output — describe what a successful result looks like so Igno and users both know what to expect.