3U

Plugin Overview

How plugins work in ThreeU — remote HTTP integrations, manifests, providers, and the plugin lifecycle.

Plugin Architecture

Plugins are the primary mechanism for third-party service integration in ThreeU. They enable external providers (shipping companies, payment gateways, analytics tools, etc.) to integrate with ThreeU merchants.

The key architectural principle: ThreeU never runs third-party code in-process. Plugin developers host their own services, and ThreeU communicates with them through signed HTTPS calls.

Core Platform Principle

ThreeU never runs third-party code in-process. All plugin logic executes on developer-hosted infrastructure, communicated via signed HTTPS calls through the RemoteHttpProvider.

Plugin Communication Flows

Path A — Inbound Webhook
Your Serviceany stack
POST /api/plugins/{id}/webhook
ThreeU API
HMAC verified
Brand Store

Your service notifies ThreeU of events. Signed with per-install webhook secret.

Path B — Gateway Action (User Triggered)
Merchant / POS
Bearer token
ThreeU Gatewayauth + permissions
forward action
Your Service

Dashboard or POS triggers an action. ThreeU validates permissions, then forwards to your endpoint.

Path C — Outbound Action (ThreeU Triggered)
ThreeU Coreautomated
HMAC-SHA256 signed
Your Servicebase_url + path
JSON response
ThreeU Core

ThreeU calls your manifest-defined endpoint directly. Uses RemoteHttpProvider with configurable timeout.

Developer Service
ThreeU Platform
Merchant / Brand
User-triggered

Plugin Lifecycle

  1. Development — Build and test your plugin locally
  2. Registration — Create a plugin entry in the Developer Console
  3. Manifest — Define the plugin manifest with actions, permissions, and endpoints
  4. Health Check — ThreeU verifies your service is reachable
  5. Review — Submit for marketplace review (public plugins)
  6. Installation — Merchants install and configure your plugin
  7. Operation — ThreeU calls your endpoints when actions are triggered
  8. Monitoring — Track webhook delivery, errors, and usage

Provider Types

ProviderDescriptionWho Uses It
remote_httpSigned HTTPS calls to developer-hosted serviceThird-party developers (default)
nativeInternal ThreeU moduleThreeU only
iframe_appEmbedded UI in admin panelApp developers
theme_extensionTheme component extensionTheme developers
webhook_onlyInbound webhooks onlyEvent receivers
manual_gatewayUser-triggered actionsManual integrations

For third-party developers, remote_http is the default and recommended provider type.