Skip to content

App Marketplace

The Sprigr App Marketplace is an extension system that lets you create custom tools your AI agents can use during conversations and workflows. Instead of waiting for platform-level integrations, you can write code that connects your agents to any API, database, or external system — and share those tools across your organisation or with the wider Sprigr community.

Think of marketplace tools as plugins for your agents. A tool might check inventory levels in your warehouse management system, pull invoice data from your accounting platform, generate compliance documents from templates, or fetch weather forecasts for scheduling outdoor jobs. If you can call an API or process data with code, you can turn it into a tool your agents can use.

Every marketplace listing is one of three kinds:

  • Tool apps — Bundles of one or more tools your agents can call. Most marketplace apps are this kind.
  • Integration apps — Apps that connect to an external account. After installing one, you are taken to its Configure page to connect the account (usually via OAuth) before the tools work.
  • Agent templates — Complete AI agents with curated training data and a pre-configured persona. See Shared Agents.

The Apps page has top-level Apps and Agents tabs so you can browse tools and agent templates separately.

Every app in the marketplace belongs to a trust tier that controls who can see and install it. Three tiers are in use today:

Private

Visible only to your company. Use this for internal tools that connect to proprietary systems or contain business logic you do not want to share. This is the default for all new apps.

Shared

Visible to specific companies you invite via a private share link. Shared apps do not appear in the public catalog — the link authorises the receiving company to view and install the app. Useful when you work with partners, franchises, or affiliated businesses that would benefit from the same tooling without making it public.

Listed

Published to the public marketplace catalog. Anyone on Sprigr Team can browse, install, and use your app. Listed apps go through a basic review to ensure they meet quality and security standards.

A fourth tier, certified, is reserved for apps that pass a deeper platform security and quality review. It is not yet available: there is no certification process today and no app carries the badge.

Apps start private. When you are ready to distribute one, open its detail page: Share generates a private invite link (the shared tier; once a link exists the button reads Copy Share Link), and List publicly puts the app in the public marketplace catalog.

Building and deploying a marketplace tool follows a straightforward process:

  1. Write your code — Click Create App on the Apps page and fill in the app’s name, description, tool details, and starter code. Then open the app in the built-in App IDE: a Monaco code editor with a file tree, syntax highlighting, and a test console. Write a handler function that accepts structured input and returns output your agent can use.

  2. Test it — Use the Test tab to provide sample input and run your tool in a sandbox environment. Check the console output, verify the response shape, and iterate until it works correctly.

  3. Deploy it — Click Deploy to bundle your code and make it available to agents. Each deployment creates a new version, so you can roll back if needed. Installations that track the latest version pick up the new version automatically (installers can instead pin to a specific version). Full apps built with the app kit are published from the terminal instead, with sprigr app validate, sprigr app dev, and sprigr app publish.

  4. Agents use it — Once deployed, any agent with the tool installed can call it during conversations and workflows. The agent sees the tool’s name, description, and input schema, and decides when to use it based on the conversation context.

The marketplace uses a tag-based system to help you find the right tools quickly. Every tool can be tagged across three dimensions:

  • Industry tags — Target specific verticals like trades, plumbing, HVAC, electrical, pest control, landscaping, cleaning, construction, real estate, healthcare, retail, hospitality, professional services, education, SaaS, or field service.
  • Integration tags — Indicate which external systems a tool connects to, such as simPRO, Gorgias, Xero, Shopify, Slack, Gmail, Google Calendar, QuickBooks, MYOB, ServiceM8, or Stripe.
  • Purpose tags — Describe what the tool does: scheduling, invoicing, quoting, CRM, analytics, reporting, communication, automation, data sync, customer support, project management, AI, or workflow.

Publishers can also add custom tags outside these groups — they appear under an “Other” heading in the filter sidebar. When browsing the marketplace, you can filter by any combination of tags. Looking for a tool that connects to simPRO and handles scheduling for HVAC businesses? Filter by all three tag types to narrow the results.

Apps are not limited to standalone operations. An app can declare a dependency on specific tools from another marketplace app installed in the same organisation (app_dependencies in its manifest) and call them at runtime with env.SPRIGR.invoke(tool, args). It can likewise declare integration_dependencies and call your connected platform integrations through env.SPRIGR.integrations.invoke. Every such dependency is shown on the install consent screen and becomes a grant the installing organisation controls — see App Permissions and Grants.

For example, a “schedule outdoor job” app might depend on a weather forecast app to check conditions and on your calendar integration to find available slots, with each dependency maintained independently.

Beyond plain tools, the platform gives app builders a set of capabilities that show up in the product as a user:

  • Human approval on sensitive actions — An app can require a real human sign-off before a destructive or costly action runs (for example deleting a product in a connected store). The approval appears as a card in chat that names the specific record being changed, and many such actions can be undone afterwards from the same card. A lighter per-tool confirmation policy (tools[].confirmation) covers actions that only need the agent to double-check.
  • Interactive cards in chat — A tool result can carry an app card: images, labelled fields, a table, and action buttons that call the app’s tools directly when clicked, updating the card in place rather than stacking duplicates. Cards render for the person; the agent only sees the JSON answer.
  • Durable jobs and a scoped store — Multi-step background jobs that are resumable, retried, can sleep durably, and can wait on a human, plus a company- or publisher-scoped key-value store for state that outlives a single run.
  • Publisher-owned browser sessions — Stateful, cookie-persistent browser sessions for automating a login-walled portal that has no API. Available only to the app’s publisher running its own app.
  • Platform-routed AI — Apps can call an OpenAI-compatible endpoint through the platform with no key of their own; usage is billed to the installing company’s Sprigr account like any other agent usage.
  • Embedded app pages — Apps that ship their own pages run in an iframe inside the portal and talk to it through the App Bridge SDK (@sprigr/app-bridge): session hand-off, navigation, notifications, resizing, tool invocation, and event emission.

Every marketplace app runs inside its own isolated sandbox on Cloudflare’s Workers platform, deployed per installation. This means:

  • Isolation — Each install runs as its own Worker with its own per-install database. An app cannot read another install’s state, another company’s data, or the platform’s own storage.
  • Declared network domains — When you create an app, you declare which external domains it needs to reach. This list is declarative: it is used to validate OAuth hosts, to route agent requests to the right app, and to inform reviewers, but it is not enforced as a runtime firewall, so review it as documentation of intent rather than a sandbox boundary.
  • Rate limiting — Each tool is limited to 100 calls per minute per installation. This prevents runaway loops and protects both your systems and external APIs from being overwhelmed.
  • Circuit breakers — If a tool fails repeatedly (ten errors within five minutes), the platform stops calling it for five minutes and returns an error instead, rather than hammering the failing endpoint.
  • Secret management — API keys and credentials are stored encrypted and injected at runtime as environment bindings. They are never exposed in agent conversations, and the platform never hands an app a Sprigr API key: every call back to the platform uses a per-install token scoped to that company.

The marketplace is designed to be flexible. Here are some examples of what teams are building:

Inventory alerts

Connect to your warehouse or spreadsheet system and alert agents when stock falls below reorder thresholds. Agents can proactively notify customers about availability.

Custom CRM connectors

Pull customer records, update deal stages, or log interactions in CRMs that do not have a native Sprigr integration yet.

Compliance generators

Generate safety checklists, inspection reports, or regulatory documents from templates using job-specific data.

Weather-based scheduling

Fetch weather forecasts and factor conditions into scheduling recommendations for outdoor work like roofing, landscaping, or painting.

The marketplace is not limited to tools. You can also install shared agents — complete AI agents with curated training data and a pre-configured persona. While tools add capabilities to your existing agents, shared agents are ready-to-use specialists you install into your company.

For example, you might install an Ecommerce Advisor agent that already knows about conversion metrics, customer lifetime value, and cart abandonment strategies. Or a Support Agent that comes pre-loaded with customer service best practices and escalation workflows.

Shared agents come with versioned training data snapshots, so the publisher can continue improving the knowledge base without disrupting your installation. You can also add your own company-specific knowledge on top.

Some apps need permissions beyond their own sandbox — for example, an app published by a partner that reads stock levels from your data, or an app that writes back to your connected Shopify or Xero integration. These permissions are modelled as grants: each one names a single tool the app may call, and you consent to them at install time. You stay in control afterwards — grants can be paused, resumed, or revoked at any time, and new permissions added by an app update wait for your approval before they work. See App Permissions and Grants for details.

Ready to build your first app? Head to Creating Custom Apps for the handler contract, the runtime environment, the App IDE, and the app kit (@sprigr/apps-app-sdk and the sprigr app CLI).

Want to browse what is already available? Check out Installing Apps to learn how to find, install, and manage marketplace apps for your agents.

Looking for pre-built agents? See Shared Agents to learn how to install agent templates with curated training data.

Want to publish your own agent? Check Training Data for how to curate and manage knowledge bases for your agent templates.

You can also create and manage apps programmatically via MCP from your IDE — see MCP Overview for the create_app, install_app, and publish_version tools.