Connector Manifests: The Secret to Onboarding Channels Without a Thousand Checkboxes

A connector isn’t “just an API client”.

It has:

• authentication requirements
• required and optional settings
• supported capabilities (read, write, update-only, webhooks…)
• constraints (batch size, rate limits, required identifiers)
• and sometimes UI configuration that differs per channel

If every connector encodes that knowledge only in code or tribal memory, you get:

• brittle onboarding
• inconsistent setups
• and support tickets that start with “did you set the correct storefront?”

A Connector Manifest is a structured description of:

• who the connector is
• what it supports
• what it needs to run
• how users should configure it

Once the platform has that information, it can do useful things automatically:

• render configuration screens dynamically
• validate settings before you hit “save”
• guide users through onboarding steps
• keep docs and UI in sync

This is how onboarding becomes a product feature – not a scavenger hunt.

Conceptually, a manifest covers:

1) Identity & version

• name
• version
• compatibility range

2) Authentication

• supported auth types (API key, OAuth2, etc.)
• required secrets (stored in credential management)
• scope requirements

3) Settings schema

• keys, types, defaults
• required fields
• validation rules
• UI hints (labels, help text, grouping)

4) Capabilities & limits

• supported operations (e.g., offer.update, product.sync, order.import)
• batch constraints
• known rate-limit behavior
• “update-only” vs “create + update” semantics

Agencies don’t want “one-off integrations”.

They want repeatable delivery:

• fewer surprises
• faster onboarding
• predictable handover

Manifests help because they turn connector configuration into something you can standardize:

• onboarding checklists become consistent
• configuration can be validated and exported
• documentation can be generated from the same source of truth

This is also how you build an ecosystem where partners can ship connectors without forcing every end user to become an expert on that channel’s quirks.

Here’s a simplified pseudo-manifest, just to show the shape:

{
  "name": "MarketplaceConnector",
  "version": "1.2.0",
  "auth": { "type": "apiKey", "credentialKey": "marketplace_api_key" },
  "settings": [
    { "key": "storefront", "type": "enum", "values": ["de","cz","sk"], "required": true },
    { "key": "mode", "type": "enum", "values": ["updateOnly","fullSync"], "required": true }
  ],
  "limits": { "maxBatchSize": 150 }
}

Now the platform can:

• show only relevant fields
• enforce max batch size
• prevent invalid configurations before the first run

That’s onboarding maturity.

Manifests only work if secrets are handled properly.

That’s why this ties directly into:

• credential management
• permissioned access (who can use which secret)
• audit logs (who changed what)
• and safe rotation

You get speed and governance.

Developers

Less custom UI. Less glue code. More time spent on real problems.

Agencies & integrators

Faster delivery and fewer onboarding surprises.
You can scale services without scaling chaos.

Merchants

Onboarding becomes predictable, and “go-live” stops being a heroic act.

Investors

Ecosystem extensibility increases TAM (total addressable market).
A platform that can onboard channels efficiently can grow faster.

Documentation matters.
But the best documentation is the kind that can’t go out of date.

Manifests are “docs that compile”.