Adapters & products
Every product PowerExecutor operates has its own adapter spec — a YAML file that IS the integration. You list, create and edit adapters entirely from the console's Adapters view.
Prerequisites to onboard a product
An adapter works like a plugin: once its spec is complete and its connection is configured, the product is automatically part of execution — the Dashboard, Approvals, Permissions, reports and the daily scheduler all pick it up. Nothing else to integrate. Before onboarding, make sure:
| # | Prerequisite | Why |
|---|---|---|
| 1 | The product exposes an HTTP(S) API reachable from PowerExecutor's network | The adapter drives the product through its API. |
| 2 | Credentials for that API (login, token, or none) | Declared in the spec's auth + config, filled in on the Configuration page. |
| 3 | At least one signal to observe | Without observations there is nothing to reason about. |
| 4 | At least one capability, each with a verify call (and sample_params when its path has placeholders) | Required by adapter certification before any cycle runs. |
| 5 | Connection settings filled in on the Configuration page | The adapter can't log in without them. |
Add a new product
Create it
Adapters view → + New product → give it an id (lowercase letters, digits,
-or_). A starter adapter spec is created and the editor opens.Fill in the adapter — guided form
The editor opens as a form (no YAML knowledge needed): connection & login method, the settings the operator will fill in, the signals to watch, and the capabilities it may use — each with risk, rollback and inline help. Advanced users can switch to the YAML tab to edit the raw spec.
Save
Save validates the YAML server-side (schema + product-name match) and rejects bad specs with the exact reason. Changes take effect next cycle — no redeploy.
Configure & enable
On Configuration, fill in the product's connection settings (the fields your spec declared under
config:). Add the product to Enabled products to include it in the daily schedule. It appears on the Dashboard, starts at 👁 Watch only, and earns freedom like any other product.
/data/specs), so products you create or edit in the console survive redeploys.Activate, deactivate, update or delete
Activate / Deactivate: each Dashboard card has a toggle. A deactivated product is skipped by the daily scheduler but keeps all its data, permissions and settings — you can still run cycles manually, and re-activate anytime.
Update: Adapters view → Edit → change it in the form (or the YAML tab) → Save adapter. Validation runs server-side; changes take effect next cycle. Connection values are edited on the Configuration page (not in the spec — the spec only declares the fields).
Delete: Adapters view → Delete → type the product name to confirm. This removes the adapter spec, its permissions, pending approvals, reports, twin state and connection settings, and takes it out of the daily schedule. Receipts are kept — they are the immutable audit trail of everything that was ever executed.
Spec reference
| Section | What it declares |
|---|---|
product / sdk_version | Product id (must match the file name) and adapter SDK version. |
api.base_url | The product's API. Overridable per environment with the <PRODUCT>_BASE_URL env var. |
api.auth | login (username/password → bearer token, e.g. PowerMarketing), bearer/header (static token from token_env), or omit for none. |
api.default_query | Query params added to every call, mapped from config values (e.g. brand_id). |
cadence | schedule: daily. |
config | Connection fields the operator fills on the Configuration page (key, label, help, secret, optional env fallback). |
signals | What to observe: id, poll (method + path), means. |
capabilities | What it may do: id, call, risk, reversibility (reversible needs capture_state+compensate; irreversible always requires approval), verify, sample_params, optional response_params. |
Example capability
capabilities:
- id: update_post
call: { method: PATCH, path: "/api/posts/{post_id}" }
risk: low
reversibility: reversible
capture_state: { method: GET, path: "/api/posts/{post_id}" }
compensate: { method: PATCH, path: "/api/posts/{post_id}" }
verify: { method: GET, path: "/api/posts/{post_id}" }
sample_params: { post_id: 1 }