OpenClaw Connector Marketplace and BYO SDK for workflow automation

TL;DR

OpenClaw now includes a Connector Marketplace and a Bring Your Own Connector SDK so teams can publish, discover, and govern integrations in one place. The release shortens time to value by standardizing auth, schema validation, and rollout controls while keeping deployment predictable. It is built to serve workflow automation and the enterprise review process without slowing developers down. If you can describe an API with OpenAPI and a manifest, you can ship a production grade connector quickly.

What we launched

The Connector Marketplace is a curated catalog of ready to install integrations covering ads, analytics, messaging, storage, and CRM systems. It ships alongside a BYO Connector SDK that lets your developers author new integrations using a small set of interfaces and a manifest that declares permissions, actions, and events. Together they deliver a consistent install experience, enforce security policies by default, and eliminate copy paste scripts that tend to sprawl over time.

For teams already running OpenClaw inside ButterGrow, this release reduces the time required to wire a new data source or destination into your campaigns. Instead of building one off HTTP nodes, you define a connector once and reuse it across playbooks, tenants, and environments with version pins and change notes.

The marketplace experience is designed for operators and developers. Operators get approvals, risk scores, and audit trails. Developers get a modern SDK with local tooling, typed schemas, and a straightforward publishing flow.

Why this matters for growth teams

Marketing stacks evolve quickly. New ad units, identity changes, channel policies, and consent requirements keep the integration surface shifting. Teams often patch gaps with brittle scripts and untracked credentials. The marketplace replaces these pockets of fragility with standardized, reviewable components that update cleanly, roll back cleanly, and carry their own telemetry.

From a cost and reliability perspective, connectors make reusability the default. A single well built integration can serve many playbooks and many teams. When something breaks, you fix it once and roll the version out gradually instead of hard patching every automation.

How the marketplace works

The marketplace centers on a verified catalog and a clear separation of concerns between publisher, reviewer, and installer. The workflow keeps velocity high without trading away control.

Step 1Author and declare

Developers use the CLI to scaffold a project and implement a small contract. Each action has a handler, a request schema, a response schema, and a policy section describing scopes and rate limits. The manifest also declares events the connector can emit, such as webhook notifications or poll based changes.

Step 2Validate and test

Before submission, a static check runs contract tests against the schema registry, verifies required metadata, and ensures that every action has a documented retry policy. The local runner executes unit scenarios with mock tokens and can replay captured traffic for debugging. Traces and logs are produced in the same format as production so issues reproduce consistently.

Step 3Submit for review

Submission packages a signed artifact and publishes it to a staging lane. Reviewers assess scopes, data residency settings, and third party dependencies. Automated checks run linting for common security footguns, such as storing tokens in memory beyond the request lifecycle or logging secrets. When the review passes, the connector becomes installable in the catalog with a security profile and publisher information.

Step 4Install and govern

Administrators install a connector into a workspace with clear prompts for credentials and scope grants. Policies can restrict installation to specific projects, require additional approvers, or block actions that conflict with internal rules. Every install, update, and rollback shows up in audit logs with timestamps and operator identity so compliance teams can trace changes.

Step 5Roll out safely

Publishers can promote a new version to a canary lane, watch error budgets, and then expand to a larger slice of installs. If an issue appears, rollbacks are immediate and documented. Change notes are distributed to installers with links to the differences that matter, including deprecations and new capabilities.

The BYO Connector SDK

The SDK focuses on a familiar developer experience. You implement handlers in TypeScript or Python, declare schemas, and use helpers for common patterns like OAuth, incremental syncs, and retryable HTTP.

// example: minimal TypeScript action
import { defineConnector, action } from "@openclaw/connector";

export default defineConnector({
  id: "acme.ads",
  name: "Acme Ads",
  auth: { type: "oauth2", scopes: ["ads.read", "ads.manage"] },
  actions: {
    upsertAudience: action({
      request: {
        type: "object",
        properties: {
          audienceId: { type: "string" },
          users: { type: "array", items: { type: "string" } }
        },
        required: ["audienceId", "users"]
      },
      response: { type: "object", properties: { status: { type: "string" } } },
      run: async ({ http, input }) => {
        const res = await http.post("/v1/audiences", input);
        return { status: res.statusText };
      }
    })
  }
});

The example shows the essential pieces. The manifest declares identity, scopes, and actions. The request and response schemas validate inputs and outputs. The generated client handles token refresh, exponential backoff, idempotency headers, and structured errors so the handler code stays focused on business logic.

Auth that scales without secrets drift

Connectors never embed long lived tokens. At install time, the catalog prompts for a named credential and binds it to the workspace. The runtime injects short lived tokens on each invocation and refreshes them transparently. Secret rotation happens out of band. Operators can rotate credentials and invalidate refresh tokens without shipping a new connector version.

Contracts you can trust

Contracts are enforced by the same registry that validates playbooks. If a handler returns a payload that does not match its declared schema, the call fails fast with a clear error and a trace for support. The practical outcome is fewer silent data corruptions and faster mean time to recovery.

For background on contracts and compatibility, you can read our overview of schema registry and contract enforcement in OpenClaw. It explains the guardrails that keep integrations predictable as they evolve.

Typed events and idempotent syncs

Many marketing systems paginate and throttle aggressively. The SDK ships with a pager and a cursor store so you can implement incremental syncs without reinventing the pattern for every API. Incoming events declare a type with a stable ID so playbooks can deduplicate delivery by key instead of by timestamp.

Local tooling and productivity

The CLI includes generators for scaffolds, a validator that catches missing fields, and a test harness that records HTTP interactions. The harness replays sessions in an offline mode, which means you can develop without hitting rate limits or violating real consent policies in a shared sandbox.

Security, review, and compliance built in

Security and compliance do not need to slow developers. The marketplace review checklist looks at OAuth scopes, token storage, field level redaction, and data residency. It also checks for logging of sensitive fields. If a connector logs a value marked as protected, the submission fails and points to the line and handler that needs to change.

Installation scope is controllable. Admins can restrict an integration to projects that have a legitimate need, block use in production until a test passes, and require a second approver for high risk scopes. All of this is tracked in audit logs for later review.

Monitoring, alerts, and change management

Every connector emits standardized metrics. Success rate, p95 latency, error categories, and retries show up in dashboards. Operators can create alerts on error budgets, and during a rollout the dashboards break down error rates by version so you can decide to advance or pause. When a connector changes behavior, the change note and manifest diff are visible in the install view so the person on call has context.

Comparison: one off scripts vs reusable connectors

The table below summarizes tradeoffs we see in the field when teams move from ad hoc scripts to reusable connectors.

Aspect	One off scripts	Reusable connectors
Auth and secrets	Stored inline or in env files, hard to rotate	Managed credentials with short lived tokens
Validation	Best effort or absent	Enforced request and response schemas
Observability	Basic logs, no traces	Standardized metrics and correlated traces
Rollouts	Manual updates across jobs	Version pins, canary, and quick rollbacks
Governance	Mixed, hard to audit	Approvals, audit logs, and policy checks

How this fits with ButterGrow

ButterGrow is the hosted OpenClaw assistant that brings connectors to non technical teams without losing control. Product managers can install catalog integrations directly into their projects, while administrators keep install scope and approvals in place. For a tour of the feature set, start with the overview of AI marketing automation features and how ButterGrow organizes capabilities for different roles.

When you need repeatable campaign logic, pair connectors with versioned templates. If you want to compare your options for integration work, the see the side by side comparison section covers how our approach differs from generic automation tools and connectors that lack governance.

Getting started

Below is an outline of the first path many teams take when building their first integration. It emphasizes practice over theory.

Step 1Install the CLI and scaffold

Install the OpenClaw CLI and run a scaffold command. This creates a project with a manifest, a handler file, and a test harness. Add an action for a simple task such as creating a contact in your CRM.

Step 2Describe your API

Write or import an OpenAPI document that covers the endpoints you will call. Use the validator to find incomplete fields such as missing response schemas. The goal is not a perfect document. The goal is a stable contract that the handler and test harness can rely on.

Step 3Implement a handler and test

Write the handler and run the local runner. Record a HTTP session and replay it offline. Confirm that the handler returns a payload that matches the declared response. Add a retry policy and ensure idempotent behavior by setting the idempotency key header.

Step 4Add auth and scopes

Declare OAuth scopes in the manifest and request a named credential at install. Verify that sensitive fields are not logged. If a test fails due to a sensitive field, fix the logging and rerun the check.

Step 5Submit and roll out

Submit the connector for review. After approval, install it in a development workspace and exercise the actions in a staging playbook. Promote to canary, watch metrics and traces, then expand rollout.

If you want to try this in your stack, you can get started in minutes with the hosted experience or bring the SDK into your own environment. The answers to common questions section covers install scope and review flow.

References

• OAuth 2.0 authorization framework RFC 6749 . reference for token based authorization flows in connectors.
• OpenAPI Specification 3.1 . official specification describing how to declare REST interfaces for code generation and validation.
• OWASP API Security Top 10 . guidance on common risks and controls for building and reviewing integrations.