@tangle-network/agent-integrations 0.29.0 → 0.31.0

package/dist/connectors/adapters/index.d.ts

@@ -1,5 +1,5 @@
-import { C as ConnectorAdapter } from '../../tangle-id-CTU4kGId.js';
-export { D as DEFAULT_TANGLE_PLATFORM_URL, v as TANGLE_API_KEY_PREFIX, w as TANGLE_SERVICE_TOKEN_PREFIX, b as TangleIdentityClient, T as TangleIdentityOptions, x as TangleIdentityUnreachableError, c as TangleTokenVerifyFailure, y as TangleTokenVerifyResult, a as TangleUserSummary, z as TangleWorkspaceSummary, F as createTangleIdentityClient, G as tangleIdentity } from '../../tangle-id-CTU4kGId.js';
+import { C as ConnectorAdapter } from '../../tangle-id-Dj0ipP4E.js';
+export { D as DEFAULT_TANGLE_PLATFORM_URL, v as TANGLE_API_KEY_PREFIX, w as TANGLE_SERVICE_TOKEN_PREFIX, b as TangleIdentityClient, T as TangleIdentityOptions, x as TangleIdentityUnreachableError, c as TangleTokenVerifyFailure, y as TangleTokenVerifyResult, a as TangleUserSummary, z as TangleWorkspaceSummary, F as createTangleIdentityClient, G as tangleIdentity } from '../../tangle-id-Dj0ipP4E.js';
 
 /**
  * Google Calendar connector — CAS reference implementation.
@@ -142,6 +142,8 @@ interface GoogleSheetsOptions {
 }
 declare function googleSheets(opts: GoogleSheetsOptions): ConnectorAdapter;
 
+declare const googleSlidesConnector: ConnectorAdapter;
+
 /**
  * @stable Gmail connector — email-triggered agent workflows.
  *
@@ -474,6 +476,43 @@ declare function declarativeRestConnector(spec: RestConnectorSpec): ConnectorAda
 
 declare const twilioSmsConnector: ConnectorAdapter;
 
+/**
+ * WhatsApp Business connector — Meta Graph API messaging surface.
+ *
+ *   send_text_message(to, body, previewUrl?)         → mutation; cas: 'none'
+ *   send_template_message(to, template, language)    → mutation; cas: 'none'
+ *   list_message_templates(limit?, status?)          → read
+ *   get_business_phone_number()                      → read
+ *
+ * Why `cas: 'none'` on sends:
+ * WhatsApp Business outbound messages are append-only and Meta does not
+ * expose a server-side idempotency key on /messages. MutationGuard's
+ * idempotency-key short-circuit (one level above the connector) is the
+ * dedup. We pin `defaultConsistencyModel: 'advisory'` to keep the
+ * validator happy — chat outbound is informational, not transactional.
+ *
+ * Auth: Facebook Login for Business (OAuth2). The OAuth response returns
+ * a `User Access Token`; the app then exchanges it via /debug_token for
+ * a long-lived (~60d) Business Token. We store the long-lived token as
+ * `accessToken`; no refresh_token because Meta does not issue one for
+ * business tokens — re-authorization is the recovery path.
+ *
+ * DataSource metadata (NOT secret, set at connect-time):
+ *   - phoneNumberId : the WABA-scoped Phone Number ID Meta assigned to
+ *     this connection (required for /messages calls).
+ *   - wabaId        : the WhatsApp Business Account ID (required for
+ *     /message_templates calls).
+ *
+ * Both come from the Embedded Signup callback; the operator wires them
+ * before invokeAction is ever called.
+ */
+
+interface WhatsappBusinessOptions {
+    clientId: string;
+    clientSecret: string;
+}
+declare function whatsappBusiness(opts: WhatsappBusinessOptions): ConnectorAdapter;
+
 /**
  * Stripe pack connector — single connector kind packing customer +
  * invoice + checkout + subscription management capabilities, validating
@@ -582,6 +621,8 @@ declare const slackEventsConnector: ConnectorAdapter;
 
 declare const githubConnector: ConnectorAdapter;
 
+declare const giteaConnector: ConnectorAdapter;
+
 declare const gitlabConnector: ConnectorAdapter;
 
 declare const airtableConnector: ConnectorAdapter;
@@ -590,4 +631,3893 @@ declare const asanaConnector: ConnectorAdapter;
 
 declare const salesforceConnector: ConnectorAdapter;
 
-export { type DocuSealOptions, type GmailOptions, type GoogleCalendarOptions, type GoogleDriveOptions, type GoogleSheetsOptions, type HubSpotOptions, type MicrosoftCalendarOptions, type NotionDatabaseOptions, type RestConnectorSpec, type RestCredentialPlacement, type RestOperationSpec, type RestRequestSpec, type SlackOptions, airtableConnector, asanaConnector, declarativeRestConnector, docuseal, githubConnector, gitlabConnector, gmail, googleCalendar, googleDrive, googleSheets, hubspot, microsoftCalendar, notionDatabase, salesforceConnector, slack, slackEventsConnector, stripePackConnector, stripeWebhookReceiverConnector, twilioSmsConnector, webhookConnector };
+/**
+ * Firebase / Cloud Firestore adapter.
+ *
+ * Surfaces Firestore document CRUD via the public REST API
+ * (https://firestore.googleapis.com/v1) using Google OAuth2 with the
+ * `datastore` scope, which Google Identity grants for Firestore + Datastore.
+ *
+ * Path parameter `documentPath` is the trailing portion after
+ * `databases/(default)/documents/` (e.g. `users/abc` or `orders/123/items/9`)
+ * so callers stay aware of Firestore's collection/document alternation rule.
+ *
+ * `body` for create/patch is a raw Firestore `Document` object — the caller
+ * supplies `fields` already typed via Firestore Value union (stringValue,
+ * integerValue, etc.). This adapter intentionally does not auto-convert
+ * primitives; callers using this from agent workflows pass the typed JSON
+ * directly so we never silently re-encode user data.
+ */
+declare const firebaseConnector: ConnectorAdapter;
+
+declare const twentyConnector: ConnectorAdapter;
+
+declare const supabaseConnector: ConnectorAdapter;
+
+declare const discordConnector: ConnectorAdapter;
+
+declare const facebookPagesConnector: ConnectorAdapter;
+
+/**
+ * Telegram Bot API connector — bot-token outbound messaging, inbound
+ * polling/webhook setup, and chat/member introspection.
+ *
+ * Auth shape
+ * ----------
+ * Telegram bots authenticate by embedding the bot token directly in the
+ * request URL path: `https://api.telegram.org/bot{TOKEN}/{method}`. There
+ * is no OAuth2 endpoint (the "Telegram Login Widget" is a separate
+ * HMAC-signed user-identity primitive, not an API access grant). Bots are
+ * issued out-of-band by BotFather; the token IS the credential. We model
+ * this as `api-key` with the raw bot token in `credentials.apiKey`. The
+ * declarative-REST helper can't express URL-path credential placement, so
+ * this adapter is hand-rolled, matching the twilio-sms pattern.
+ *
+ * Consistency model
+ * -----------------
+ * Telegram messages are append-only and advisory — no etag, no compare-
+ * and-swap on sendMessage. Edits and deletes use the (chat_id, message_id)
+ * pair as a natural idempotency anchor. We mark `advisory` so the planner
+ * does not promise transactional outcomes; sendMessage CAS is `none`,
+ * edits use `optimistic-read-verify`, and deletes / answerCallbackQuery /
+ * setWebhook use `native-idempotency` since replaying the same call is
+ * safe (same args ⇒ same end state).
+ *
+ * Capability surface (Bot API v7+)
+ * --------------------------------
+ *   reads       — getMe, getChat, getChatAdministrators, getChatMember,
+ *                 getChatMemberCount, getUpdates, getFile, getWebhookInfo
+ *   mutations   — sendMessage, sendPhoto, sendDocument, editMessageText,
+ *                 deleteMessage, forwardMessage, answerCallbackQuery,
+ *                 setWebhook, deleteWebhook
+ *
+ * Long-polling (`getUpdates`) and webhook receivers are both supported as
+ * read/mutation capabilities; full inbound `handleInboundEvent` wiring is
+ * left for the webhook layer to add once a `telegram-webhook-receiver`
+ * adapter lands (Telegram delivers updates as raw POST bodies with a
+ * `X-Telegram-Bot-Api-Secret-Token` header that the receiver verifies).
+ */
+
+declare const telegramConnector: ConnectorAdapter;
+/** Public file-download root. Callers that resolve `getFile` results into
+ *  download URLs build `${TELEGRAM_FILE_DOWNLOAD_ROOT}/bot<token>/<file_path>`;
+ *  exposed here so consumers don't reinvent the constant. */
+declare const TELEGRAM_FILE_DOWNLOAD_ROOT = "https://api.telegram.org/file";
+
+declare const pipedriveConnector: ConnectorAdapter;
+
+declare const closeConnector: ConnectorAdapter;
+
+declare const zohoCrmConnector: ConnectorAdapter;
+
+declare const zohoDeskConnector: ConnectorAdapter;
+
+declare const attioConnector: ConnectorAdapter;
+
+declare const quickbooksConnector: ConnectorAdapter;
+
+/**
+ * Xero accounting connector.
+ *
+ * Auth: OAuth2 (Authorization Code + PKCE) via the Xero Identity service. After
+ * consent the customer authorizes one or more Xero organizations ("tenants");
+ * the chosen tenant id is passed on every API call via the `xero-tenant-id`
+ * header. Because a single connection can span multiple tenants, the adapter
+ * requires `tenantId` as an explicit argument on each capability rather than
+ * pulling it from connection metadata — this mirrors how Salesforce requires
+ * `objectName` per call.
+ *
+ * Capability surface = the finance/accounting action pack: read+create+update
+ * for contacts and invoices, plus an account read for chart-of-accounts lookups.
+ * All operations target the Xero Accounting REST API v2.0.
+ */
+declare const xeroConnector: ConnectorAdapter;
+
+declare const gustoConnector: ConnectorAdapter;
+
+declare const bigcommerceConnector: ConnectorAdapter;
+
+declare const shopifyConnector: ConnectorAdapter;
+
+declare const ebayConnector: ConnectorAdapter;
+
+interface EtsyOptions {
+    /** OAuth2 client_id, also used as the `x-api-key` header on every request.
+     *  Etsy calls this the app "keystring". */
+    keystring: string;
+}
+declare function etsyConnector(opts: EtsyOptions): ConnectorAdapter;
+
+declare const quickzuConnector: ConnectorAdapter;
+
+declare const zagomailConnector: ConnectorAdapter;
+
+declare const zendeskConnector: ConnectorAdapter;
+
+declare const zendeskSellConnector: ConnectorAdapter;
+
+declare const intercomConnector: ConnectorAdapter;
+
+declare const helpscoutConnector: ConnectorAdapter;
+
+declare const frontConnector: ConnectorAdapter;
+
+declare const gorgiasConnector: ConnectorAdapter;
+
+/**
+ * Mailchimp Marketing API v3.0 — audience/list management, member upsert,
+ * campaign send. Auth is OAuth2 with a per-account datacenter prefix; after
+ * the token exchange callers MUST hit `https://login.mailchimp.com/oauth2/metadata`
+ * with the access token and persist `api_endpoint` (e.g. `https://us20.api.mailchimp.com`)
+ * into the data source `metadata.apiEndpoint` field. The declarative REST
+ * runtime then routes every request against that per-tenant base URL.
+ *
+ * Mailchimp OAuth2 does not use scopes — the grant is account-wide and the
+ * `scopes` array stays empty by design. We surface that explicitly in the
+ * manifest so the UI does not collect a value that the upstream will ignore.
+ *
+ * Member upserts use PUT against `/lists/{listId}/members/{subscriberHash}`
+ * where `subscriberHash` is the MD5 of the lowercase email — the caller is
+ * expected to pre-compute it and pass it in. That keeps this adapter pure
+ * declarative-REST and avoids smuggling crypto into the request layer.
+ */
+declare const mailchimpConnector: ConnectorAdapter;
+
+declare const klaviyoConnector: ConnectorAdapter;
+
+declare const sendgridConnector: ConnectorAdapter;
+
+/**
+ * SendPulse adapter — REST API at https://api.sendpulse.com/
+ *
+ * Auth: OAuth2 client credentials (clientId + clientSecret) exchanged for
+ * an access token. The token is forwarded as a Bearer token in the
+ * Authorization header on every call.
+ *
+ * Capabilities mirror the activepieces catalog entry for `sendpulse`:
+ * subscriber lifecycle (add, update, delete, unsubscribe), and variable
+ * management per subscriber.
+ */
+declare const sendpulseConnector: ConnectorAdapter;
+
+declare const postmarkConnector: ConnectorAdapter;
+
+/**
+ * Marketo REST API — lead lifecycle (search, get, upsert), static list
+ * membership, and campaign trigger. Every Marketo subscription has its own
+ * Munchkin-scoped REST endpoint (`https://{munchkinId}.mktorest.com`), so the
+ * adapter resolves `baseUrl` from `metadata.restEndpoint` populated during
+ * connection setup.
+ *
+ * Marketo's primary machine-to-machine auth is client_credentials against
+ * `/identity/oauth/token`. For embedded LaunchPoint apps the same identity
+ * service exposes a 3-legged authorize endpoint at `/identity/oauth/authorize`
+ * which we surface here so the hub OAuth handler can negotiate a per-user
+ * token. Marketo does not honour granular OAuth scopes — capability is gated
+ * by the service user's API Role in the Marketo Admin UI — so we leave the
+ * scope set empty and document the requirement in the auth hint via the
+ * description on each capability.
+ *
+ * Lead upserts use POST /rest/v1/leads.json with an `action` of
+ * `createOrUpdate`; Marketo returns per-row status (`created`, `updated`,
+ * `skipped`) under `result[]` and the call is naturally idempotent when the
+ * caller supplies a `lookupField` (default `email`).
+ */
+declare const marketoConnector: ConnectorAdapter;
+
+/**
+ * Braze REST API — customer lifecycle messaging (push / email / in-app / SMS).
+ *
+ * Auth: REST API key issued in the Braze dashboard (Settings → REST API Keys)
+ * with the per-endpoint permissions the agent will call. Braze accepts the key
+ * as a Bearer token, so the declarative REST runtime's default credential
+ * placement works as-is.
+ *
+ * Base URL is per-instance: every Braze workspace lives in one of the named
+ * REST endpoints (rest.iad-01.braze.com, rest.iad-02.braze.com,
+ * rest.eu-01.braze.com, etc.). The customer picks it once at connection time
+ * and we persist it on the data source `metadata.restEndpoint` field — the
+ * adapter routes every request against that per-tenant base URL. No
+ * fallback: a misconfigured connection fails loud at the first invocation
+ * rather than silently calling someone else's cluster.
+ *
+ * Capability surface covers the four flows agents actually need on Braze:
+ *   - `users.track`        — server-side event / attribute / purchase ingest
+ *   - `users.identify`     — alias→external_id reconciliation
+ *   - `users.export`       — read user profiles by external_id / braze_id / email
+ *   - `subscription.status.set` — manage marketing/transactional opt-state
+ *   - `campaigns.trigger.send` and `canvas.trigger.send` — API-triggered sends
+ *   - `email.blacklist`    — suppress an address from future sends
+ *
+ * Every mutation uses native idempotency where Braze supports it
+ * (`/users/track` is deterministic on `external_id`+`name`+`time`; campaign
+ * triggers accept a `dispatch_id` echo) and `external-effect: true` so the
+ * hub guard records the side effect even on replay.
+ */
+declare const brazeConnector: ConnectorAdapter;
+
+declare const customerIoConnector: ConnectorAdapter;
+
+declare const calComConnector: ConnectorAdapter;
+
+declare const calendlyConnector: ConnectorAdapter;
+
+declare const zohoBookingsConnector: ConnectorAdapter;
+
+/**
+ * @stable Contentful CMS connector — read and write entries through the
+ * Content Management API (CMA).
+ *
+ * Five capabilities, all scoped to a single `spaceId` + `environmentId`
+ * (callers pin the environment per-action so the same connection can target
+ * `master`, `staging`, etc. without re-auth):
+ *
+ *   entries.list(spaceId, environmentId, contentType?, query?, limit?, skip?)
+ *     → CMA entry collection envelope
+ *     Read. GET /spaces/{spaceId}/environments/{environmentId}/entries.
+ *
+ *   entries.get(spaceId, environmentId, entryId)
+ *     → CMA entry shape
+ *     Read. GET /spaces/{spaceId}/environments/{environmentId}/entries/{entryId}.
+ *
+ *   entries.create(spaceId, environmentId, contentType, fields)
+ *     → created CMA entry
+ *     Mutation. POST /spaces/{spaceId}/environments/{environmentId}/entries with
+ *     the `X-Contentful-Content-Type` header.
+ *
+ *   entries.update(spaceId, environmentId, entryId, version, fields)
+ *     → updated CMA entry
+ *     Mutation with CAS. PUT /spaces/{spaceId}/environments/{environmentId}/entries/{entryId}
+ *     with `X-Contentful-Version` set from the caller-supplied `version` so
+ *     concurrent edits surface as 409 conflict.
+ *
+ *   entries.publish(spaceId, environmentId, entryId, version)
+ *     → published entry
+ *     Mutation with CAS. PUT /spaces/{spaceId}/environments/{environmentId}/entries/{entryId}/published.
+ *
+ * Auth: OAuth2 (Contentful OAuth app + Bearer token). Scopes:
+ *   - `content_management_read` for read capabilities
+ *   - `content_management_manage` for write capabilities
+ *
+ * Versioning: Contentful does not emit HTTP ETag headers. Every entry body
+ * carries `sys.version`; callers thread it back as the `version` argument on
+ * mutations. The 409 surfaces through the shared declarative-rest helper as
+ * a `{ status: 'conflict', ... }` result row.
+ */
+declare const contentfulConnector: ConnectorAdapter;
+
+/**
+ * @stable Sanity Content Lake connector — query and mutate documents in a
+ * Sanity dataset through the public HTTP API.
+ *
+ * Five capabilities, scoped per-dataset (the connection holds the project
+ * host; the dataset is per-action so the same connection can target
+ * `production`, `staging`, etc.):
+ *
+ *   documents.query(dataset, query, params?, apiVersion?)
+ *     → { ms, query, result }
+ *     Read. GET /v{apiVersion}/data/query/{dataset}?query={GROQ}&%24<param>=…
+ *     The Sanity HTTP query API serializes GROQ params as `$<name>` query
+ *     keys with JSON-encoded values.
+ *
+ *   documents.get(dataset, documentId, apiVersion?)
+ *     → { ms, documents: [doc] }
+ *     Read. GET /v{apiVersion}/data/doc/{dataset}/{documentId}.
+ *
+ *   documents.create(dataset, document, apiVersion?)
+ *     → { transactionId, results: [...] }
+ *     Mutation. POST /v{apiVersion}/data/mutate/{dataset} with a single
+ *     `create` mutation. The caller passes the full document body including
+ *     `_type` and optional `_id`. We thread `inv.idempotencyKey` as the
+ *     `transactionId` query so retries collapse server-side.
+ *
+ *   documents.patch(dataset, documentId, patch, apiVersion?, ifRevisionId?)
+ *     → { transactionId, results: [...] }
+ *     Mutation with CAS. POST /v{apiVersion}/data/mutate/{dataset} with a
+ *     single `patch` mutation. The caller threads `_rev` back as
+ *     `ifRevisionId` so concurrent edits surface as 409.
+ *
+ *   documents.delete(dataset, documentId, apiVersion?)
+ *     → { transactionId, results: [...] }
+ *     Mutation. POST /v{apiVersion}/data/mutate/{dataset} with a single
+ *     `delete` mutation.
+ *
+ * Auth: OAuth2 (Sanity Manage OAuth app + Bearer token). Scopes:
+ *   - `read` for read capabilities
+ *   - `write` for write capabilities
+ *
+ * Base URL: per-project hostname `https://<projectId>.api.sanity.io`,
+ * persisted on the connection as `metadata.apiHost`. We do NOT default to
+ * the org-wide `api.sanity.io` because that endpoint refuses data-API calls.
+ *
+ * Versioning: Sanity does not emit HTTP ETag headers on data routes. Every
+ * document carries `_rev`; callers thread it back as the `ifRevisionId`
+ * argument on `documents.patch` so the mutation rejects with a 409 when the
+ * document has been edited since the read. The 409 surfaces through the
+ * shared declarative-rest helper as a `{ status: 'conflict', ... }` data
+ * row.
+ */
+declare const sanityConnector: ConnectorAdapter;
+
+declare const codaConnector: ConnectorAdapter;
+
+/**
+ * @stable Webflow CMS connector — read sites/collections/items and create or
+ * update collection items through the Webflow Data API v2.
+ *
+ * Webflow's data model is three levels deep: sites → collections → items.
+ * A single OAuth connection grants access to all authorized sites under the
+ * connected workspace; capability calls take the relevant `siteId` or
+ * `collectionId` as an explicit argument so one connection can drive many
+ * sites without re-auth.
+ *
+ * Capabilities:
+ *
+ *   sites.list()
+ *     → { sites: [...] }
+ *     Read. GET /v2/sites.
+ *
+ *   sites.get(siteId)
+ *     → site shape
+ *     Read. GET /v2/sites/{siteId}.
+ *
+ *   collections.list(siteId)
+ *     → { collections: [...] }
+ *     Read. GET /v2/sites/{siteId}/collections.
+ *
+ *   collections.get(collectionId)
+ *     → collection shape (includes field definitions)
+ *     Read. GET /v2/collections/{collectionId}.
+ *
+ *   items.list(collectionId, offset?, limit?, name?, slug?)
+ *     → { items: [...], pagination }
+ *     Read. GET /v2/collections/{collectionId}/items.
+ *
+ *   items.get(collectionId, itemId)
+ *     → CMS item shape
+ *     Read. GET /v2/collections/{collectionId}/items/{itemId}.
+ *
+ *   items.create(collectionId, fieldData, isArchived?, isDraft?)
+ *     → created item
+ *     Mutation. POST /v2/collections/{collectionId}/items with the item
+ *     wrapped under the `items` envelope.
+ *
+ *   items.update(collectionId, itemId, fieldData, isArchived?, isDraft?)
+ *     → updated item
+ *     Mutation. PATCH /v2/collections/{collectionId}/items/{itemId}.
+ *
+ *   items.delete(collectionId, itemId)
+ *     → empty
+ *     Mutation. DELETE /v2/collections/{collectionId}/items/{itemId}.
+ *
+ *   items.publish(collectionId, itemIds)
+ *     → { publishedItemIds, errors }
+ *     Mutation. POST /v2/collections/{collectionId}/items/publish to move
+ *     staged items live to the published site.
+ *
+ *   pages.list(siteId)
+ *     → { pages: [...], pagination }
+ *     Read. GET /v2/sites/{siteId}/pages.
+ *
+ *   forms.list(siteId)
+ *     → { forms: [...], pagination }
+ *     Read. GET /v2/sites/{siteId}/forms.
+ *
+ *   forms.submissions(formId)
+ *     → { formSubmissions: [...], pagination }
+ *     Read. GET /v2/forms/{formId}/submissions.
+ *
+ * Auth: OAuth2 (Webflow OAuth app + Bearer token). Webflow scopes use the
+ * `resource:action` shape (`sites:read`, `cms:write`, etc.); the connector
+ * requests the union of read+write across the resources the capability set
+ * touches.
+ *
+ * Versioning: Webflow does not emit HTTP ETag headers and does not implement
+ * If-Match semantics on the v2 Data API. Mutations rely on the
+ * `native-idempotency` model — the caller's idempotency key is forwarded by
+ * the declarative-REST runtime so retries collapse server-side. Concurrent
+ * field-data edits last-writer-wins; agents that need stronger ordering must
+ * serialize at the application layer.
+ */
+declare const webflowConnector: ConnectorAdapter;
+
+/**
+ * @stable WordPress.com connector — read, create, update, and delete posts,
+ * pages, media, and comments through the WordPress REST API as proxied by
+ * WordPress.com's public OAuth-protected endpoint.
+ *
+ * All capabilities are scoped to a single `site` identifier (the connection
+ * UI collects a WordPress.com domain like "example.wordpress.com" or a
+ * numeric site ID; both forms are accepted by `/wp/v2/sites/{site}/...`).
+ * The site identifier is passed per-action so a single OAuth connection can
+ * address every site the granting user has access to.
+ *
+ * Auth: OAuth2 against `public-api.wordpress.com`. Bearer-token access. Scopes
+ * requested:
+ *   - `posts`    — read + write posts, pages
+ *   - `media`    — upload + read media items
+ *   - `comments` — read + moderate comments
+ *
+ * Base URL: `https://public-api.wordpress.com`. The WordPress REST API lives
+ * under `/wp/v2/sites/{site}/...` and accepts JSON bodies on create/update.
+ *
+ * Versioning: WordPress doesn't surface HTTP ETags on REST resources, but
+ * every post/page response carries a `modified_gmt` timestamp. Mutations are
+ * marked `native-idempotency` because the API rejects identical create
+ * requests with the same `slug` and accepts repeated updates against a stable
+ * resource ID.
+ */
+declare const wordpressConnector: ConnectorAdapter;
+
+/**
+ * Atlassian Confluence Cloud connector.
+ *
+ * Auth: OAuth 2.0 (3LO) via auth.atlassian.com. After consent, a single
+ * connection may have access to multiple Atlassian sites; each is identified
+ * by a `cloudId` discoverable through
+ * `GET https://api.atlassian.com/oauth/token/accessible-resources`.
+ * The cloudId is passed in on every capability as an explicit argument
+ * (same pattern as Xero `tenantId` / Salesforce `objectName`) rather than
+ * baked into connection metadata, so a single connection can target any
+ * site the operator authorized.
+ *
+ * Base URL: `https://api.atlassian.com/ex/confluence/{cloudId}` — the gateway
+ * proxies through to the customer's Confluence site.
+ *
+ * Capability surface covers the v2 REST API (the v1 `/wiki/rest/api/...`
+ * surface is on Atlassian's deprecation track): pages list/get/create/update,
+ * spaces list, and CQL search via the v1 `/wiki/rest/api/search` endpoint
+ * which is still the only supported way to run CQL.
+ */
+declare const confluenceConnector: ConnectorAdapter;
+
+declare const docusignConnector: ConnectorAdapter;
+
+declare const figmaConnector: ConnectorAdapter;
+
+declare const figjamConnector: ConnectorAdapter;
+
+declare const miroConnector: ConnectorAdapter;
+
+/**
+ * @stable Canva Connect API connector — read designs/folders/brand-templates,
+ * create designs, post comments, kick off exports + autofill jobs.
+ *
+ * Canva's Connect API is REST + Bearer OAuth2 (PKCE-only on the auth side;
+ * confidential clients also send `client_secret` to the token endpoint). The
+ * declarative-rest runtime only sees the Bearer access token at execute time,
+ * so PKCE state is the host OAuth runtime's concern, not the adapter's.
+ *
+ * Endpoints (public docs — https://www.canva.dev/docs/connect/):
+ *   - Authorize: https://www.canva.com/api/oauth/authorize
+ *   - Token:     https://api.canva.com/rest/oauth/token
+ *   - REST base: https://api.canva.com/rest
+ *
+ * Scope model: Canva uses fine-grained `<resource>:<aspect>:<read|write>`
+ * scopes. We request the union covering the capability surface below:
+ *   - design.{content,meta,permission}.{read,write}
+ *   - asset.{read,write}
+ *   - brandtemplate.{content,meta}.read
+ *   - comment.{read,write}
+ *   - folder.{read,write}
+ *   - profile.read
+ * `app:read`/`app:write` are intentionally excluded — they govern Canva-app
+ * builder surfaces, not Connect data flows.
+ *
+ * Identifier nomenclature (from Canva's API reference):
+ *   - design_id        : the public `DAFxxxx` design id
+ *   - folder_id        : `FAFxxxx`; `root` is the user's top-level folder
+ *   - asset_id         : `Mxxxx` returned by uploads
+ *   - brand_template_id: returned from /v1/brand-templates
+ *   - comment_id       : returned from comment endpoints
+ *   - job_id           : returned by long-running endpoints
+ *                        (asset-uploads, exports, autofills, design-imports)
+ *
+ * Async jobs: every long-running endpoint returns `{ job: { id, status } }`
+ * and is polled via its sibling GET /v1/<resource>/{jobId}. The polling GET
+ * is exposed as a separate `read` capability so the agent can wait without
+ * holding a mutation in-flight.
+ */
+declare const canvaConnector: ConnectorAdapter;
+
+/**
+ * Box Content Cloud connector — standard OAuth2 with refresh tokens.
+ *
+ * Box's OAuth2 flow is the textbook RFC 6749 authorization-code grant:
+ *   - authorize at https://account.box.com/api/oauth2/authorize
+ *   - exchange at https://api.box.com/oauth2/token
+ *   - refresh at the same /oauth2/token endpoint
+ *
+ * Access tokens live 60 minutes; refresh tokens live 60 days and rotate on
+ * every refresh — callers must persist the new refresh_token on each
+ * exchange (the declarative adapter handles refresh through the shared
+ * oauth helpers, so the only contract here is the manifest URLs + scopes).
+ *
+ * Scope surface picked to cover the dominant "agent reads / files / folders
+ * and uploads or moves an item" pattern without pulling in the admin
+ * surfaces. `root_readwrite` is Box's coarse-grained app-folder scope; we
+ * keep it off the default list — adapters that want write access must
+ * request it explicitly via `requiredScopes` on the mutation capabilities.
+ *
+ * Action surface:
+ *   - folders.get        Read folder metadata + first page of items.
+ *   - folders.items      Paginated child enumeration with limit/offset.
+ *   - folders.create     Create a folder under a parent.
+ *   - files.get          Read file metadata (size, sha1, parent, version).
+ *   - files.update       Rename / move / restore-from-trash a file.
+ *   - files.copy         Server-side copy into a target folder.
+ *   - files.delete       Send a file to trash.
+ *   - search             Full-text + metadata search across the enterprise.
+ *   - users.me           Self-test endpoint (also exposed as `test`).
+ *
+ * Box does not implement ETag-style preconditions on every endpoint, but
+ * file/folder PUTs honor `If-Match` against the resource `etag` field;
+ * mutations are flagged `optimistic-read-verify` so the action guard
+ * round-trips the read before write. Creates use `native-idempotency`
+ * since Box derives uniqueness from (parent_id, name) and 409s on
+ * collisions, which the declarative layer surfaces as
+ * `{ status: 'conflict' }`.
+ */
+declare const boxConnector: ConnectorAdapter;
+
+/**
+ * Dropbox connector — standard OAuth2 against the Dropbox v2 RPC API.
+ *
+ * OAuth2 endpoints:
+ *   - authorize at https://www.dropbox.com/oauth2/authorize
+ *   - exchange / refresh at https://api.dropboxapi.com/oauth2/token
+ *
+ * Dropbox issues short-lived access tokens (4h) and long-lived refresh
+ * tokens when the authorization request is made with
+ * `token_access_type=offline`. The refresh tokens do NOT rotate per use
+ * (unlike Box), so the declarative adapter only needs to swap the access
+ * token through the shared OAuth helpers when 401s land — the manifest
+ * here just declares the contract.
+ *
+ * The Dropbox API is RPC-shaped (POST + JSON body) on api.dropboxapi.com
+ * for metadata operations; content upload/download lives on
+ * content.dropboxapi.com with the request payload tunneled through the
+ * `Dropbox-API-Arg` HTTP header. Because the declarative-REST adapter
+ * carries a single base URL and a JSON body, we keep this connector to
+ * the metadata + sharing surface — file content upload/download belongs
+ * in a content-stream-aware adapter, not here. That keeps every action
+ * on this adapter pure JSON-RPC with predictable error handling.
+ *
+ * Scope surface picked to match a typical "agent enumerates / searches /
+ * organizes / shares files" pattern. Read scopes are on the default
+ * authorization list; write/share scopes are pulled in per-capability so
+ * the action guard's least-privilege check stays meaningful.
+ *
+ * Action surface:
+ *   - users.get_current_account   Self-test endpoint (also exposed as `test`).
+ *   - users.get_space_usage       Account quota + used bytes.
+ *   - files.list_folder           List the children of a folder path.
+ *   - files.list_folder_continue  Cursor-based pagination of list_folder.
+ *   - files.get_metadata          Read metadata for a single path.
+ *   - files.search                Indexed full-text + filename search.
+ *   - files.create_folder_v2      Create a folder at a path.
+ *   - files.move_v2               Move / rename a file or folder.
+ *   - files.copy_v2               Server-side copy.
+ *   - files.delete_v2             Move to deleted/trash state.
+ *   - sharing.create_shared_link_with_settings
+ *                                 Mint a public shared link with options.
+ *   - sharing.list_shared_links   List existing shared links for a path.
+ *
+ * Dropbox's RPC endpoints are not ETag-shaped — most mutations key off
+ * the (parent, name) tuple or accept a `rev` for optimistic writes. The
+ * adapter marks creates / copies as `native-idempotency` (Dropbox 409s
+ * on duplicate paths with a structured `path/conflict/...` error) and
+ * destructive moves/deletes as `optimistic-read-verify` so the action
+ * guard round-trips a metadata read before issuing the mutation.
+ *
+ * Every Dropbox v2 endpoint is `POST`; "read" vs "mutation" here is
+ * about side-effect intent, not HTTP verb. `files.list_folder`,
+ * `files.search`, and `users.*` are stateless reads that just happen to
+ * be POSTed with a JSON arg body, which is the canonical Dropbox shape.
+ */
+declare const dropboxConnector: ConnectorAdapter;
+
+/**
+ * Adobe Creative Cloud connector — Adobe IMS (Identity Management Service)
+ * OAuth2 authorization-code flow against the publicly-documented Lightroom
+ * Services API at https://lr.adobe.io, plus the IMS userinfo endpoint for
+ * connection self-test.
+ *
+ * OAuth2 endpoints (Adobe IMS v2/v3):
+ *   - authorize at https://ims-na1.adobelogin.com/ims/authorize/v2
+ *   - exchange / refresh at https://ims-na1.adobelogin.com/ims/token/v3
+ *   - userinfo at https://ims-na1.adobelogin.com/ims/userinfo/v2
+ *
+ * Adobe IMS is a standard RFC 6749 authorization-code grant. Access tokens
+ * live ~24h and refresh tokens ~14 days; the declarative adapter routes
+ * refreshes through the shared OAuth helpers and only declares the
+ * authorize / token URLs here.
+ *
+ * The Creative Cloud surface is split across several distinct OpenAPI
+ * products; the Lightroom Services API is the canonical "creative asset"
+ * surface available to standard end-user OAuth clients (the Creative SDK,
+ * Photoshop scripting, and the Asset Browser APIs require additional
+ * partner programs). We scope this adapter to the public Lightroom +
+ * IMS userinfo surface so every action here is callable with a vanilla
+ * end-user Adobe ID + a self-service Developer Console OAuth Web App.
+ *
+ * Lightroom paths (https://lr.adobe.io) are catalog-scoped:
+ *   /v2/account                       — account-level metadata
+ *   /v2/catalogs                      — list catalogs the user owns
+ *   /v2/catalogs/{catalog_id}         — read one catalog
+ *   /v2/catalogs/{catalog_id}/albums  — list / create / update albums
+ *   /v2/catalogs/{catalog_id}/assets  — list / search assets
+ *   /v2/catalogs/{catalog_id}/assets/{asset_id}
+ *   /v2/catalogs/{catalog_id}/albums/{album_id}/assets
+ *
+ * Lightroom requires every request to carry both the bearer access token
+ * AND an `X-API-Key` header set to the OAuth client_id. The declarative
+ * adapter sends the bearer through the standard credential placement; the
+ * `X-API-Key` is templated into `defaultHeaders` using
+ * `{credentials.clientId}` which the runtime substitutes from the resolved
+ * data source. (See `declarative-rest.ts` for header templating.)
+ *
+ * Scope surface picked for the typical "agent enumerates the user's
+ * library, searches assets, and organizes them into albums" pattern:
+ *
+ *   openid, profile, email          — IMS userinfo self-test
+ *   offline_access                  — refresh token
+ *   lr_partner_apis                 — Lightroom catalog read / search
+ *   lr_partner_rendition_apis       — Lightroom rendition (preview) reads
+ *
+ * Adobe IMS scopes are comma-delimited at the authorize endpoint; the
+ * declarative oauth runtime handles the separator. Write scopes
+ * (album mutations) reuse `lr_partner_apis` — Adobe does not split read
+ * vs write at the scope layer for the Lightroom partner surface, so the
+ * action guard's least-privilege check keys off `requiredScopes` only
+ * for filtering by capability identity (read vs mutation class), not by
+ * a separate write scope.
+ *
+ * Action surface:
+ *   - ims.userinfo            Self-test; resolves the authenticated Adobe ID.
+ *   - account.get             Lightroom account metadata.
+ *   - catalogs.list           Enumerate the user's Lightroom catalogs.
+ *   - catalogs.get            Read one catalog.
+ *   - albums.list             List albums in a catalog.
+ *   - albums.get              Read one album.
+ *   - albums.create           Create an album under a catalog.
+ *   - albums.update           Rename / move / reparent an album.
+ *   - albums.delete           Delete an album (assets are not deleted).
+ *   - assets.list             Paginated catalog asset enumeration.
+ *   - assets.get              Read one asset's metadata + revision tree.
+ *   - assets.list_in_album    Assets attached to a specific album.
+ *
+ * Adobe Lightroom mutations are PUT-shaped with client-supplied UUIDs as
+ * the resource id, so creates are `native-idempotency` (re-issuing the
+ * same PUT with the same UUID is a no-op replay). Album updates are
+ * `etag-if-match` — Lightroom returns ETag headers and rejects PUTs that
+ * lack a matching `If-Match`. Deletes are `optimistic-read-verify` so the
+ * action guard round-trips a metadata read before the destructive call.
+ */
+declare const adobeCreativeCloudConnector: ConnectorAdapter;
+
+declare const linearConnector: ConnectorAdapter;
+
+/**
+ * Trello connector.
+ *
+ * Auth model: Trello's first-party authorization flow issues a per-user token
+ * bound to a developer API key. Calls to https://api.trello.com/1/* are
+ * authenticated by sending the user token as the `token` query parameter and
+ * the developer API key as the `key` query parameter. The framework places
+ * the user token via `credentialPlacement: { kind: 'query', parameter: 'token' }`;
+ * the developer API key travels on every invocation as the `key` argument
+ * (resolve once from connection metadata at the caller and forward).
+ *
+ * Token minting page (developer): https://trello.com/app-key
+ * Authorize a user token:         https://trello.com/1/authorize
+ *
+ * Trello's authorize endpoint returns a token directly (token-grant style);
+ * there is no separate `tokenUrl` to exchange a code at, so this adapter
+ * surfaces as `api-key` rather than `oauth2` to avoid implying a refresh-token
+ * lifecycle that Trello does not implement.
+ *
+ * REST reference: https://developer.atlassian.com/cloud/trello/rest/
+ */
+declare const trelloConnector: ConnectorAdapter;
+
+declare const mondayConnector: ConnectorAdapter;
+
+declare const clickupConnector: ConnectorAdapter;
+
+declare const basecampConnector: ConnectorAdapter;
+
+declare const clioConnector: ConnectorAdapter;
+
+declare const sentryConnector: ConnectorAdapter;
+
+/**
+ * Datadog — observability ingest surface (logs, metrics, events, service
+ * checks, validation).
+ *
+ * Auth model: Datadog uses two distinct credential headers — `DD-API-KEY`
+ * (org-scoped, identifies which Datadog account to bill / route to) and
+ * `DD-APPLICATION-KEY` (user-scoped, grants per-user RBAC across the
+ * management surface: monitors, dashboards, queries, downtimes, etc.). The
+ * declarative-rest runtime in this codebase carries exactly one credential
+ * per connection; modelling Datadog's full dual-key management surface here
+ * would require either packing both keys into one apiKey string (silently
+ * coupled and easy to misconfigure) or extending the framework's credential
+ * placement model. This adapter intentionally scopes itself to the
+ * single-header surface that takes only DD-API-KEY:
+ *
+ *   - POST /api/v2/logs            — log ingest
+ *   - POST /api/v2/series          — metric submission (v2)
+ *   - POST /api/v1/series          — metric submission (v1)
+ *   - POST /api/v1/distribution_points
+ *   - POST /api/v1/events          — post a custom event
+ *   - GET  /api/v1/events          — list events (DD-API-KEY only)
+ *   - POST /api/v1/check_run       — service check status
+ *   - GET  /api/v1/validate        — auth probe
+ *
+ * That set covers the agent-relevant case "push observability data into
+ * Datadog" cleanly and honestly. A separate `datadog-management` adapter is
+ * the right home for the DD-APPLICATION-KEY surface (monitors, dashboards,
+ * incidents, logs/metrics query). Do not silently extend this connector with
+ * endpoints that require DD-APPLICATION-KEY — they will return 403 at
+ * runtime and corrupt every signal downstream.
+ *
+ * Site routing: Datadog runs eight isolated regions (US1, US3, US5, EU,
+ * AP1, US1-FED, and the legacy US-LEGACY datadoghq.com). Each has its own
+ * intake hostname; the per-tenant intake URL lives on metadata.intakeUrl
+ * (e.g. https://api.datadoghq.com, https://api.us3.datadoghq.com,
+ * https://api.datadoghq.eu, https://api.ddog-gov.com, https://api.ap1.datadoghq.com).
+ * No fallback — a misconfigured connection fails loud at first invocation
+ * rather than silently shipping logs to the wrong region's compliance
+ * boundary.
+ */
+declare const datadogConnector: ConnectorAdapter;
+
+declare const pagerdutyConnector: ConnectorAdapter;
+
+declare const opsgenieConnector: ConnectorAdapter;
+
+/**
+ * Auth0 Management API connector.
+ *
+ * Auth0 tenants are per-customer subdomains (e.g. https://acme.us.auth0.com).
+ * The tenant base URL is supplied at connection time via metadata.tenantDomain
+ * (full origin, no trailing slash) so the same adapter works for every tenant
+ * without a per-tenant build.
+ *
+ * Authorization: OAuth2 with the Management API as the audience. The tenant
+ * authorization/token URLs are tenant-scoped; the global EU/US/AU/JP regions
+ * all share the same /authorize and /oauth/token path shape so we cannot bake
+ * one regional host into the connector. We point at Auth0's documented global
+ * "guardian" host — operators MUST override authorizationUrl/tokenUrl at
+ * client-registration time with the tenant's own URLs (the platform stores
+ * them as part of the OAuth client). The values below are the canonical
+ * documented shapes Auth0 publishes for the M2M (machine-to-machine) and
+ * authorization-code flows against the Management API.
+ *
+ * Docs:
+ *   - https://auth0.com/docs/api/management/v2
+ *   - https://auth0.com/docs/secure/tokens/access-tokens/management-api-access-tokens
+ *   - https://auth0.com/docs/api/authentication#client-credentials-flow
+ */
+declare const auth0Connector: ConnectorAdapter;
+
+declare const openaiConnector: ConnectorAdapter;
+
+declare const anthropicConnector: ConnectorAdapter;
+
+declare const googleGeminiConnector: ConnectorAdapter;
+
+/**
+ * Google Gemini — Generative Language API (v1beta).
+ *
+ * The public API at `generativelanguage.googleapis.com` accepts a Google AI
+ * Studio API key passed as the `?key=` query parameter. (Cloud-billed Vertex
+ * AI traffic uses a different host + OAuth2; that flow belongs in a separate
+ * connector because the request/response shapes diverge.)
+ *
+ * Endpoints follow Google's `:method` action-style URLs — e.g.
+ * `/v1beta/models/{model}:generateContent`. We model the colon segment as a
+ * literal in the path because `declarativeRestConnector` interpolates only
+ * `{name}` template segments.
+ *
+ * Capability surface chosen for agent-driven use:
+ *   - models.list / models.get  — discover what's available to the key.
+ *   - models.generateContent     — single-turn or multi-turn generation.
+ *   - models.streamGenerateContent — long-form streaming (returns SSE; we
+ *                                     surface the raw JSON array Google emits).
+ *   - models.countTokens         — pre-flight cost estimation.
+ *   - models.embedContent / batchEmbedContents — embeddings for retrieval.
+ *   - files.list / files.get / files.delete — File API (uploaded media that
+ *                                              `generateContent` can reference).
+ *   - cachedContents.{list,get,create,delete} — Context caching (cheaper
+ *                                                  repeated-prefix inference).
+ *
+ * Generation is a read in the consistency sense — it has no upstream mutation
+ * — but classifying it as `class: 'read'` would tell the agent runtime it
+ * has no external effect, which is wrong (it bills the customer). We model
+ * generation as a mutation with `cas: 'none'` + `externalEffect: true`. The
+ * connector defaults to `cache` consistency: Gemini outputs are not a source
+ * of truth, callers re-call to get fresh tokens.
+ *
+ * Credentials shape: the runtime supplies `{ kind: 'api-key', apiKey: string }`;
+ * `credentialPlacement` below puts the `apiKey` into `?key=` on every request.
+ */
+declare const geminiConnector: ConnectorAdapter;
+
+declare const huggingfaceConnector: ConnectorAdapter;
+
+/**
+ * Weaviate vector database connector.
+ *
+ * Authentication: API-key issued from a Weaviate Cloud cluster (or a
+ * self-hosted cluster running the api-key auth module). The key travels in a
+ * standard `Authorization: Bearer …` header, matching the declarative-rest
+ * default placement.
+ *
+ * Base URL: the per-cluster REST endpoint
+ * (e.g. https://<cluster>.weaviate.network). Stored on the DataSource as
+ * `clusterUrl` metadata so a single connector kind can serve many tenants /
+ * environments without re-issuing OAuth clients.
+ *
+ * Endpoint surface covered (v1 REST):
+ *   - Schema (classes / collections): list, get, create, delete.
+ *   - Objects: list, get-by-id, create, update (PATCH-merge), replace (PUT),
+ *     delete-by-id.
+ *   - Search: GraphQL `Get` body (vector / hybrid / bm25 are all expressed as
+ *     fields inside the same query), batch object insert.
+ *
+ * Capabilities that depend on multipart bodies, binary streams, or
+ * gRPC-only paths (e.g. `/v1/backups` streaming, gRPC batch insert) are
+ * intentionally omitted — they need a bespoke adapter, not declarative-rest.
+ */
+declare const weaviateConnector: ConnectorAdapter;
+
+declare const pineconeConnector: ConnectorAdapter;
+
+/**
+ * Qdrant vector database connector.
+ *
+ * Authentication: API key delivered in the `api-key` header. Qdrant Cloud
+ * issues per-cluster API keys (Console → Data Access Control → API Keys);
+ * self-hosted clusters set the same header value via service config. There is
+ * no OAuth surface — Qdrant Cloud's management plane uses keys end-to-end.
+ *
+ * Base URL is per-cluster (e.g. `https://xyz-uuid.us-east-1-0.aws.cloud.qdrant.io:6333`)
+ * and therefore resolved from connection metadata.qdrantUrl at invocation
+ * time, not baked into the adapter. The trailing `:6333` is part of the
+ * Qdrant REST port — callers MUST store the full origin including port.
+ *
+ * Endpoint surface covered: collection lifecycle (create / get / list / delete
+ * / update params), point lifecycle (upsert / get / delete / batch update),
+ * search and query primitives (single, batch, recommend, scroll, count),
+ * payload index management, and snapshot operations. Telemetry-only routes
+ * (`/telemetry`, `/metrics`) are intentionally omitted — they leak cluster
+ * internals and aren't useful to agent invocations.
+ */
+declare const qdrantConnector: ConnectorAdapter;
+
+declare const bamboohrConnector: ConnectorAdapter;
+
+/**
+ * Rippling Platform API connector.
+ *
+ * Rippling exposes a single workforce platform API at api.rippling.com that
+ * covers HRIS (employees, groups, departments, work locations), payroll
+ * reads, time-and-attendance, and the company directory. Access is granted
+ * by an admin installing a Rippling Marketplace app into their company; the
+ * resulting OAuth flow yields a workspace-scoped bearer token.
+ *
+ * OAuth (authorization-code, install-app shape):
+ *   - Authorize:  https://app.rippling.com/apps/{client_id}/install
+ *                 (the standard authorize/redirect endpoint Rippling publishes
+ *                  for marketplace apps; the client_id appears in the path
+ *                  rather than the query string, which is consistent with
+ *                  Rippling's documented install flow.)
+ *   - Token:      https://app.rippling.com/api/o/token/
+ *   - Refresh:    same token endpoint with grant_type=refresh_token
+ *
+ * Scopes:
+ *   Rippling uses the OAuth2 scope value `company:read` for the canonical
+ *   read surface and per-resource read/write scopes (employees:read, etc.)
+ *   for richer mutations. The default set below covers everything the
+ *   capabilities map exercises.
+ *
+ * Base URL: https://api.rippling.com (single global host; no tenant routing).
+ *
+ * Docs:
+ *   - https://developer.rippling.com/docs/rippling-api/getting-started
+ *   - https://developer.rippling.com/docs/rippling-api/authentication
+ *   - https://developer.rippling.com/docs/rippling-api/api-reference
+ */
+declare const ripplingConnector: ConnectorAdapter;
+
+/**
+ * Workday connector.
+ *
+ * Auth model: Workday exposes a public OAuth 2.0 authorization-code grant
+ * surfaced as an "API Client for Integrations" registered by a Workday
+ * tenant administrator. Three properties of that flow shape this adapter:
+ *
+ *   1. The authorize/token endpoints are tenant-scoped under the tenant's
+ *      Workday host:
+ *        - Authorize: https://{host}/ccx/oauth2/{tenant}/authorize
+ *        - Token:     https://{host}/ccx/oauth2/{tenant}/token
+ *      `host` is the Workday data center the tenant lives in (e.g.
+ *      `wd5.workday.com`, `wd2-impl-services1.workday.com`); `tenant` is
+ *      the customer's tenant id. The operator persists the tenant-resolved
+ *      values on the OAuth client record when they register an integration
+ *      for that tenant — the manifest below carries the documented URL
+ *      shape so the registration UI can prefill it. This mirrors how
+ *      Auth0's tenant-scoped Management API authorize/token URLs are
+ *      surfaced (see auth0.ts).
+ *
+ *   2. The REST base URL is ALSO tenant-scoped:
+ *        https://{host}/ccx/api/v1/{tenant}
+ *      with secondary surfaces at `/ccx/api/staffing/v1/{tenant}`,
+ *      `/ccx/api/absenceManagement/v1/{tenant}`, etc. The connection stores
+ *      the resolved tenant-scoped origin on `metadata.apiBaseUrl` so a
+ *      single OAuth client can fan out per tenant without a per-tenant
+ *      build; capability paths stay relative below.
+ *
+ *   3. Workday's scope vocabulary is "Functional Area" + access level
+ *      (Get / Put). The set requested below covers the read + maintain
+ *      surface the action pack exercises (workers, organizations,
+ *      time-off). Tenant admins enable the matching functional areas on
+ *      the API Client; the OAuth `scope` parameter narrows further at
+ *      runtime.
+ *
+ * Capability surface: Workers (list/get), Worker employment details,
+ * Organizations (list/get), Locations (list), Time Off (list types, list
+ * requests, submit a request) — the HRIS jobs an agent typically wires
+ * for onboarding lookups, headcount queries, and PTO workflows. Workday's
+ * payroll, recruiting, and absence-balance surfaces are deliberately not
+ * modeled here; they live on separate REST endpoints (Payroll, Recruiting,
+ * Absence Management) that warrant their own adapters as the action pack
+ * widens.
+ *
+ * Consistency model: `authoritative` — Workday is the system of record
+ * for HR data; downstream caches MUST defer to it on conflict.
+ *
+ * Docs:
+ *   - https://community.workday.com/sites/default/files/file-hosting/restapi/index.html
+ *   - https://doc.workday.com/admin-guide/en-us/integrations/integration-design/oauth-and-rest-api/dan1370797667399.html
+ *   - https://community.workday.com/api-clients-for-integrations
+ */
+declare const workdayConnector: ConnectorAdapter;
+
+/**
+ * Lever ATS connector.
+ *
+ * - OAuth2 (authorization code) — production host `auth.lever.co`,
+ *   sandbox host `sandbox-lever.auth0.com`. We default to production; callers
+ *   that need sandbox set metadata.authHost / metadata.apiHost (the
+ *   declarative-rest adapter only routes one baseUrl — we expose the prod API
+ *   here and let callers override via {metadataKey: 'apiBase', fallback: ...}).
+ * - REST API: https://api.lever.co/v1
+ * - Scopes: each resource has read + write variants (e.g. `opportunities:read:admin`,
+ *   `postings:write:admin`); offline_access is required for refresh tokens.
+ *   See https://hire.lever.co/developer/oauth.
+ */
+declare const leverConnector: ConnectorAdapter;
+
+declare const greenhouseConnector: ConnectorAdapter;
+
+declare const vercelConnector: ConnectorAdapter;
+
+/**
+ * Netlify adapter for the public Netlify REST API (api.netlify.com/api/v1).
+ *
+ * OAuth2 authorization endpoints come straight from the Netlify OAuth docs:
+ *   https://docs.netlify.com/api/get-started/#authentication
+ *   https://www.netlify.com/blog/2016/10/10/integrating-with-netlify-oauth2/
+ *
+ *   authorize: https://app.netlify.com/authorize
+ *   token:     https://api.netlify.com/oauth/token
+ *
+ * Netlify OAuth does not expose granular scopes — the issued access token is
+ * scoped to the authorizing user and inherits whatever the user can do on the
+ * sites/teams they belong to. We pass an empty `scopes` array so the SDK does
+ * not attempt to append `scope=...` query parameters that Netlify would
+ * silently ignore (and that some OAuth client libs treat as a grant
+ * mismatch).
+ *
+ * Access tokens are sent as `Authorization: Bearer <token>` against
+ * https://api.netlify.com/api/v1, which is the default base URL we ship.
+ * Operators running Netlify Enterprise can override `metadata.apiBaseUrl` on
+ * a DataSource to point at a private API surface without forking this
+ * adapter.
+ *
+ * Capability surface covers the deployment workflow that matters to an agent:
+ *   - inventory: list/get sites, list/get deploys, environment variables
+ *   - mutation: trigger build hooks, lock/unlock deploys, restore a deploy,
+ *     create/update/delete env vars, update site config, delete a site/deploy
+ *
+ * Every mutation declares `cas: 'native-idempotency'` (Netlify endpoints are
+ * idempotent on retry by deploy/site id and accept repeated PATCHes) or
+ * `'optimistic-read-verify'` for the update flows where Netlify will silently
+ * merge a stale PATCH if we did not read-before-write.
+ */
+declare const netlifyConnector: ConnectorAdapter;
+
+/**
+ * Typeform Create API — read forms + responses, mutate forms, register webhooks
+ * for response.received fan-out. OAuth2 against api.typeform.com; scopes are
+ * resource:read|write tuples plus the `offline` scope which Typeform requires
+ * to mint a refresh token (omit it and the integration becomes a 4-hour token).
+ *
+ * Base URL is a single global host (no per-tenant routing). Responses live on
+ * `/forms/{form_id}/responses` and are immutable from the API side; webhooks
+ * are how customers tail new submissions in near-real-time without polling.
+ */
+declare const typeformConnector: ConnectorAdapter;
+
+declare const smooveConnector: ConnectorAdapter;
+
+/**
+ * @stable Dropbox Sign (formerly HelloSign) connector — e-signature flows
+ * powered by reusable templates.
+ *
+ * Three capabilities + inbound webhook surface, modeled on Dropbox Sign's
+ * /v3/signature_request endpoints:
+ *
+ *   send_signature_request(templateIds, signers, subject?, message?, testMode?)
+ *     → {signatureRequestId, signatureUrlsBySigner?, isComplete:false, signers:[...]}
+ *     Mutation. POST /signature_request/send_with_template. The Dropbox Sign
+ *     API exposes neither an `idempotency_key` field nor an external_id on
+ *     this endpoint, so we encode a one-way fingerprint of the
+ *     idempotencyKey in the `metadata.tangle_idempotency_key` field and
+ *     refuse to retry until the SDK's MutationGuard has a record. CAS =
+ *     native-idempotency only because retry-on-network-error is gated by
+ *     MutationGuard's idempotency-key short-circuit; we do NOT trust
+ *     Dropbox Sign to dedupe.
+ *
+ *   get_signature_request(signatureRequestId)
+ *     → {signatureRequestId, isComplete, isCanceled, signers:[{email, name, status, signedAt?, lastReminderedAt?}]}
+ *     Read. GET /signature_request/:id.
+ *
+ *   cancel_signature_request(signatureRequestId)
+ *     → {signatureRequestId, status: 'canceled', canceledAt}
+ *     Mutation. POST /signature_request/cancel/:id. Idempotent by design —
+ *     Dropbox Sign returns 200 even if the request is already canceled, so
+ *     we surface `idempotentReplay: true` on the second call.
+ *
+ *   handleInboundEvent (webhook surface)
+ *     Dropbox Sign POSTs JSON to a customer-configured URL with the body
+ *     under a `json` form-field (multipart/form-data) OR as a plain JSON
+ *     body for newer apps. The payload carries `event.event_hash` which is
+ *     `HMAC_SHA256(api_key, event_time + event_type)` (hex). We verify by
+ *     recomputing the hash and comparing in constant time. There is no
+ *     dedicated signature header; the signature lives inside the body.
+ *
+ * Auth: OAuth2 (Dropbox Sign authorizes per-account access tokens). Every
+ * API endpoint accepts the access token via `Authorization: Bearer <token>`.
+ * The same access token doubles as the HMAC key for webhook verification
+ * because Dropbox Sign reuses the API credential — we lift it from the
+ * resolved OAuth credentials envelope, never from env.
+ *
+ * Error taxonomy (mapped via integrations/errors.ts):
+ *   401 → provider_auth_failed (CredentialsExpired) — refresh attempted once
+ *   404 → action_not_found (Error) — signature_request_id is unknown
+ *   409 → action_denied / ResourceContention when status guards (e.g.
+ *          cancel of a completed request)
+ *   429 → provider_rate_limited (status: 'rate-limited' result)
+ *   5xx → provider_unavailable
+ */
+
+/** OAuth client config the factory closes over. Caller resolves these at
+ *  construction time (env, DB, secret manager — package doesn't care). */
+interface HelloSignOptions {
+    clientId: string;
+    clientSecret: string;
+    /** Override the Dropbox Sign API base URL. Mainly for tests + EU residency. */
+    baseUrl?: string;
+    /** Default request timeout in ms. */
+    timeoutMs?: number;
+}
+declare function hellosign(opts: HelloSignOptions): ConnectorAdapter;
+
+/**
+ * @stable PandaDoc connector — contract/proposal workflows for sales agents.
+ *
+ * Five capabilities cover the agent's PandaDoc hot path: discover an
+ * existing document, read its current status, draft a new document from a
+ * template, send it for signature, and cancel an in-flight document.
+ *
+ *   search_documents(query?, status?, templateId?, limit?)
+ *     → {documents: [{id, name, status, dateCreated, dateModified, ...}], more}
+ *     Read. GET /public/v1/documents with `q`, `status`, `template_id`
+ *     query params. No CAS — list endpoints are not authoritative.
+ *
+ *   get_document(documentId)
+ *     → {documentId, name, status, dateCreated, dateModified, recipients,
+ *        tokens, fields, pricing}
+ *     Read. GET /public/v1/documents/:id/details — the only endpoint that
+ *     returns recipients + field values + pricing in a single call.
+ *
+ *   create_document(name, templateId, recipients, tokens?, fields?,
+ *                   pricingTables?, metadata?, tags?)
+ *     → {documentId, name, status: 'document.uploaded' | 'document.draft', ...}
+ *     Mutation. POST /public/v1/documents. PandaDoc has no native
+ *     idempotency-key on this endpoint, so we shape the agent contract
+ *     around an idempotent metadata fingerprint: the idempotencyKey is
+ *     written to `metadata.tangleIdempotencyKey` and we list-search by
+ *     that fingerprint before issuing the POST. Race window is acceptable
+ *     because the upstream PandaDoc UI is the source of truth — a
+ *     duplicated draft surfaces immediately to the human.
+ *
+ *   send_document(documentId, subject?, message?, sender?, silent?)
+ *     → {documentId, status: 'document.sent'}
+ *     Mutation. POST /public/v1/documents/:id/send. Append-only state
+ *     transition — re-sending an already-sent document returns 400 from
+ *     PandaDoc which we surface as a ResourceContention.
+ *
+ *   cancel_document(documentId, reason?)
+ *     → {documentId, status: 'document.voided', voidedAt}
+ *     Mutation. POST /public/v1/documents/:id/cancel with `reason` in the
+ *     body. Idempotent at the upstream — cancelling an already-cancelled
+ *     document is a no-op (200 with the same status), which we surface as
+ *     idempotentReplay=true.
+ *
+ * Auth: OAuth2 (PandaDoc uses `read` / `read+write` scopes). API keys are
+ * also supported by PandaDoc but our agent surface assumes the OAuth grant
+ * because the customer connects through the hub's OAuth UI.
+ *
+ * Error taxonomy (mapped via integrations/errors.ts):
+ *   401 → provider_auth_failed (CredentialsExpired)
+ *   404 → action_not_found (Error) — document/template id unknown
+ *   409 → action_denied / ResourceContention (already-sent, already-voided)
+ *   429 → provider_rate_limited (status: 'rate-limited' result)
+ *   5xx → provider_unavailable
+ */
+
+/** OAuth client config the factory closes over. Caller resolves these
+ *  at construction time (env, DB, secret manager — package doesn't care). */
+interface PandaDocOptions {
+    clientId: string;
+    clientSecret: string;
+    /** Override the API base URL (mocks, sandbox tenants). */
+    baseUrl?: string;
+    /** Default request timeout in ms. */
+    timeoutMs?: number;
+}
+declare function pandadoc(opts: PandaDocOptions): ConnectorAdapter;
+
+/**
+ * @stable Google Docs connector — read + draft surface for doc-flow agents.
+ *
+ * Three capabilities, picked to cover the "agent reads a doc the user
+ * pointed at, then composes a draft into a new doc" workflow without
+ * trying to expose Docs' full editing grammar (suggestions, comments,
+ * structured headings — all separate packs):
+ *
+ *   get_document(documentId)
+ *     → {documentId, title, body: { content: string }, revisionId}
+ *     Read. GET /v1/documents/{documentId}. We collapse the structured
+ *     `body.content[]` block stream into a single plaintext string so
+ *     the agent layer doesn't have to walk Docs' nested paragraph /
+ *     textRun / sectionBreak tree. The full structure is preserved at
+ *     `body.structured` for callers that need it.
+ *
+ *   create_document(title, body?)
+ *     → {documentId, title, revisionId}
+ *     Mutation. POST /v1/documents to create a fresh doc, then — if
+ *     `body` was supplied — POST /v1/documents/{id}:batchUpdate with a
+ *     single `insertText` request targeting index 1. Two-step because
+ *     documents.create only accepts `title`; everything else is a
+ *     batchUpdate. CAS: native-idempotency by way of MutationGuard's
+ *     idempotency-key short-circuit (Docs API has no requestId on
+ *     create, so retries above the connector are the prevention).
+ *
+ *   append_text(documentId, text, requiredRevisionId?)
+ *     → {documentId, revisionId}
+ *     Mutation. POST /v1/documents/{id}:batchUpdate with one
+ *     `insertText` request at the doc's end. When `requiredRevisionId`
+ *     is supplied we attach it to the batchUpdate request — Docs
+ *     rejects with 400 + status code FAILED_PRECONDITION if another
+ *     writer beat us, which we surface as ResourceContention. This is
+ *     real CAS at the Docs API level (writeControl.requiredRevisionId).
+ *
+ * Auth: OAuth2 with `documents` (read+write). We also include
+ * `drive.file` so create_document yields docs the connecting user can
+ * subsequently see in Drive — without it, Docs created via the API
+ * are owned by the user but invisible in their Drive UI (a Docs API
+ * documented quirk).
+ *
+ * Why no "find by title" capability: Docs API has no search endpoint;
+ * that surface belongs in the Google Drive connector
+ * (files.list with mimeType='application/vnd.google-apps.document').
+ * The two adapters compose at the agent layer.
+ */
+
+/** OAuth client config the factory closes over. */
+interface GoogleDocsOptions {
+    clientId: string;
+    clientSecret: string;
+    /** Default request timeout in ms. Applied per-fetch via AbortSignal. */
+    timeoutMs?: number;
+}
+declare function googleDocs(opts: GoogleDocsOptions): ConnectorAdapter;
+
+/**
+ * Google Forms connector — read a form's schema + paginate its responses.
+ *
+ * Two-pane surface aimed at the dominant agent workflow ("ingest this
+ * survey into the KB / route this lead based on the response that just
+ * came in"):
+ *
+ *   get_form(formId)
+ *     → {formId, info: {title, description, documentTitle}, items: [...],
+ *        revisionId, responderUri}
+ *     Read. GET /v1/forms/{formId}. The full Form resource, including the
+ *     item tree (questions, sections, page breaks). The agent layer uses
+ *     `items[]` to map raw response answers back to human-readable
+ *     questions; the alternative is hand-rolling the questionId→title
+ *     join every call. Includes `revisionId` so callers can detect a
+ *     schema change since the last ingest.
+ *
+ *   list_responses(formId, pageSize?, pageToken?, filter?)
+ *     → {responses: [{responseId, createTime, lastSubmittedTime,
+ *        respondentEmail?, answers: {questionId: {value: string[]}}}],
+ *        nextPageToken?}
+ *     Read. GET /v1/forms/{formId}/responses. Forms paginates with
+ *     pageToken/pageSize (max 5000 per Forms API docs). The optional
+ *     `filter` accepts the Forms `timestamp` filter grammar
+ *     (e.g. `timestamp > "2026-01-01T00:00:00Z"`) so incremental ingest
+ *     just needs to track the last-seen submission time. We collapse
+ *     each answer's `textAnswers.answers[].value` array into a single
+ *     `value: string[]` field — Forms nests responses three levels deep
+ *     (answers → textAnswers → answers[] → value); the original tree is
+ *     preserved at `raw` for callers that need fileUploadAnswers,
+ *     grade, etc.
+ *
+ *   get_response(formId, responseId)
+ *     → single-response variant of list_responses for webhook delivery
+ *     where the watch notification carries only the responseId.
+ *     Read. GET /v1/forms/{formId}/responses/{responseId}.
+ *
+ * Auth: OAuth2. We request `forms.body.readonly` for the schema and
+ * `forms.responses.readonly` for the submissions — both are
+ * non-sensitive read scopes that don't trigger Google's restricted-scope
+ * verification flow. We deliberately do NOT request `forms.body` (write):
+ * creating/mutating a form is a separate connector surface and would
+ * upgrade this connector to a restricted scope, which forces the
+ * customer's OAuth app through a security review.
+ *
+ * Why no `create_form` / `submit_response`:
+ *   - create_form requires the sensitive `forms.body` scope; out of
+ *     scope for an ingest connector.
+ *   - submit_response: the Forms API has no public endpoint for
+ *     programmatic submission; the only path is the public form URL
+ *     (formResponse), which the connector framework treats as a
+ *     generic webhook, not a Forms-API capability.
+ */
+
+/** OAuth client config the factory closes over. */
+interface GoogleFormsOptions {
+    clientId: string;
+    clientSecret: string;
+    /** Default request timeout in ms. Applied per-fetch via AbortSignal. */
+    timeoutMs?: number;
+}
+declare function googleForms(opts: GoogleFormsOptions): ConnectorAdapter;
+
+/**
+ * Microsoft Graph (identity / directory) connector.
+ *
+ * The Graph surface this adapter exposes is the M365 identity-and-directory
+ * subset — the "who works here, in what group, with what mailbox" queries
+ * an agent needs to resolve human ↔ tenant identifiers when the same user
+ * is referenced across Outlook, Teams, SharePoint, and OneDrive. The
+ * resource-specific surfaces (mail, calendar, chat, files) live in their
+ * own adapters; this one is the directory lookup substrate they all share.
+ *
+ * Why read-only:
+ *   Provisioning users / groups against Graph requires
+ *   `User.ReadWrite.All` or `Directory.ReadWrite.All`, which Microsoft only
+ *   issues under admin consent and rejects on delegated grants without an
+ *   Azure AD admin approval flow. Wiring that as an agent self-service
+ *   capability is a footgun, so this adapter declares no mutations. Tenants
+ *   that need provisioning compose Graph + a verified app registration with
+ *   their own admin consent — out of scope here.
+ *
+ * Auth quirks:
+ *   - Same login.microsoftonline.com v2.0 endpoints as the other M365
+ *     adapters (Calendar, Teams, Outlook). `offline_access` is mandatory on
+ *     v2.0 to receive a refresh_token; without it the connection silently
+ *     dies after the first hour.
+ *   - The directory scopes (`User.Read.All`, `Group.Read.All`,
+ *     `Organization.Read.All`) require tenant-admin consent. The connect
+ *     flow surfaces that to the operator; a delegated grant with only
+ *     `User.Read` works for the `get_me` capability but the rest 403.
+ *
+ * Conflict model: pure reads, no CAS. `defaultConsistencyModel:
+ * 'authoritative'` because every read goes straight to the directory.
+ */
+
+/** OAuth client config the factory closes over. Caller resolves these
+ *  at construction time (env, DB, secret manager — package doesn't care). */
+interface MicrosoftGraphOptions {
+    clientId: string;
+    clientSecret: string;
+}
+declare function microsoftGraph(opts: MicrosoftGraphOptions): ConnectorAdapter;
+
+/**
+ * Microsoft Graph Outlook Mail connector — the Microsoft 365 counterpart of
+ * the Gmail adapter. Four capabilities mirror the Gmail surface so an agent
+ * routes the same intent against either inbox:
+ *
+ *   list_messages(folder?, query?, top?)
+ *     → {messages: [{id, conversationId, subject, from, toRecipients,
+ *        receivedDateTime, bodyPreview, isRead, hasAttachments}], nextLink?}
+ *     Read. `GET /me/mailFolders/{folder}/messages` with `$select` pinned
+ *     to the fields above. `$search`/`$filter` translates the operator's
+ *     query. Default folder is the well-known `inbox`.
+ *
+ *   read_message(id)
+ *     → {id, conversationId, subject, from, toRecipients, ccRecipients,
+ *        receivedDateTime, body: {contentType, content}, attachments:
+ *        [{id, name, contentType, size}]}
+ *     Read. `GET /me/messages/{id}?$expand=attachments($select=id,name,...)`.
+ *     Attachment bytes are NOT inlined — caller follows up with
+ *     `/me/messages/{id}/attachments/{id}/$value` if needed.
+ *
+ *   send_reply(messageId, body, replyAll?, comment?)
+ *     → {sent: true, messageId}
+ *     Mutation. `POST /me/messages/{id}/createReply` (or `createReplyAll`)
+ *     returns a draft; we patch the body and `POST .../send`. The reply
+ *     inherits the original `internetMessageHeaders` so threading sticks.
+ *     CAS: native-idempotency. Graph exposes no `Idempotency-Key` header
+ *     on `send`, so we tag the draft with an `internetMessageHeaders`
+ *     entry `X-Tangle-Idempotency-Key: <key>` AND rely on the
+ *     MutationGuard's key short-circuit above the connector to prevent
+ *     duplicate sends on retry.
+ *
+ *   subscribe_folder(folder, notificationUrl, ttlMinutes?)
+ *     → {subscriptionId, expirationDateTime, clientState}
+ *     Mutation. `POST /subscriptions` registers a webhook for new mail in
+ *     a folder. Graph caps `expirationDateTime` at ~4230 minutes (~3
+ *     days) for mail; caller is responsible for re-issuing before then.
+ *
+ * Auth: OAuth2 with `Mail.Read` (list/read), `Mail.Send` (send),
+ * `Mail.ReadWrite` (subscriptions), and `offline_access` (required to
+ * get a refresh token from the v2.0 endpoint). Caller toggles which to
+ * include via the `scopes` option.
+ */
+
+interface OutlookMailOptions {
+    clientId: string;
+    clientSecret: string;
+    /** Scopes requested at connect-time. Default: read + send + read-write + offline. */
+    scopes?: string[];
+    /** Default request timeout in ms. */
+    timeoutMs?: number;
+}
+declare function outlookMail(opts: OutlookMailOptions): ConnectorAdapter;
+
+/**
+ * Microsoft Teams connector — Graph-backed messaging surface.
+ *
+ *   post_channel_message(teamId, channelId, content[, contentType])  → mutation; cas: 'none'
+ *   post_chat_message(chatId, content[, contentType])                → mutation; cas: 'none'
+ *   list_channel_messages(teamId, channelId[, top])                  → read
+ *   list_joined_teams()                                              → read
+ *   list_team_channels(teamId)                                       → read
+ *   lookup_user(email)                                               → read
+ *
+ * Conflict model mirrors slack: Teams chat is append-only and advisory —
+ * Graph does not expose ETag-CAS on `chatMessage` posts, and there is no
+ * server-side dedup analogue to Slack `client_msg_id`. We set
+ * `defaultConsistencyModel: 'advisory'` and use `cas: 'none'` on the
+ * mutation paths; the upstream `MutationGuard` short-circuits idempotency
+ * by key before the Graph call runs.
+ *
+ * Auth: standard OAuth2 against the v2.0 endpoint. `offline_access` is
+ * required to receive a refresh_token; without it the connection silently
+ * dies after the access token's first hour. Channel-message scopes
+ * (`ChannelMessage.Send`) are delegated permissions — the bot posts as
+ * the connected user, NOT as an application identity. Application
+ * messages would require a different grant flow (resource-specific
+ * consent + bot framework registration), out of scope for this adapter.
+ */
+
+/** OAuth client config the factory closes over. Caller resolves these
+ *  at construction time (env, DB, secret manager — package doesn't care). */
+interface MicrosoftTeamsOptions {
+    clientId: string;
+    clientSecret: string;
+}
+declare function microsoftTeams(opts: MicrosoftTeamsOptions): ConnectorAdapter;
+
+/**
+ * Microsoft OneDrive connector — the Graph half of the doc-flow-in pattern
+ * (mirror of `google-drive.ts`, swapping the upstream for `/me/drive/...`).
+ *
+ * Three capabilities, picked to cover "agent pulls a document the user
+ * dropped in a folder" without trying to expose all of OneDrive's surface:
+ *
+ *   list_files(folderId?, query?, top?, skipToken?)
+ *     → {files: [{id, name, eTag, lastModifiedDateTime, size, file?, folder?, parentReference}], nextLink?}
+ *     Read. `GET /me/drive/items/{folderId}/children` when folderId is
+ *     supplied, otherwise `GET /me/drive/root/children`. `query` is sent
+ *     through Graph `$search="…"` (KQL) with the required
+ *     `ConsistencyLevel: eventual` header — Graph 400s if you mix
+ *     `$search` with `$orderby`, so we suppress the order clause whenever
+ *     a search is active. Same shape Outlook Mail uses.
+ *
+ *   read_file(fileId)
+ *     → {name, mimeType, content: string | base64, encoding: 'utf-8' | 'base64', eTag?, lastModifiedDateTime?}
+ *     Read. Graph's content endpoint is `GET /me/drive/items/{id}/content`
+ *     which 302-redirects to a short-lived pre-signed download URL. fetch
+ *     follows the redirect transparently. Text-like mime types are
+ *     returned utf-8; everything else is base64.
+ *
+ *   watch_folder(folderId, notificationUrl, ttlMinutes?, clientState?)
+ *     → {subscriptionId, expirationDateTime, resource}
+ *     Mutation. `POST /subscriptions` with
+ *     `resource = "/me/drive/items/{folderId}"`. Graph caps OneDrive
+ *     subscription lifetime at ~30 days (we default to 4230 minutes ≈ 70
+ *     hours to match the Outlook Mail default, since callers usually
+ *     renew on the same cadence regardless of upstream). CAS:
+ *     `native-idempotency` via the SDK's idempotency-key short-circuit
+ *     above the connector — Graph does not have a request-id analogue on
+ *     `/subscriptions`, so re-issuing the call without dedup would
+ *     create a fresh subscription each time. We do not call `getSchedule`
+ *     here because subscriptions are not slot-allocated like calendar
+ *     events; there is no "two callers grabbed the same channel" race.
+ *
+ * Auth: OAuth2 v2.0 endpoint with `Files.Read` (list/read) and
+ * `Files.ReadWrite` (watch). `offline_access` is required to receive a
+ * refresh token; without it Graph hands back access tokens only and the
+ * connection silently dies after ~1 hour. We scope to readonly by
+ * default and require the operator to opt into the write scope only if
+ * they intend to use `watch_folder` — gated via `requiredScopes` on the
+ * capability so the agent's tool registry never surfaces it without the
+ * grant.
+ *
+ * Why no upload capability in v1: same reasoning as google-drive —
+ * resumable uploads are properly their own connector pack (write-doc
+ * workflows need an authoritative consistency model, a separate review
+ * path). Doc-flow-in is the load-bearing case.
+ */
+
+/** OAuth client config the factory closes over. Caller resolves these
+ *  at construction time (env, DB, secret manager — package doesn't care). */
+interface OneDriveOptions {
+    clientId: string;
+    clientSecret: string;
+    /** When true, request the broader `Files.ReadWrite` scope at
+     *  connect-time so the operator can use `watch_folder`. Default false —
+     *  request only `Files.Read` and gate `watch_folder` via
+     *  `requiredScopes`. */
+    includeWriteScope?: boolean;
+    /** Default request timeout in ms. Applied per-fetch via AbortSignal. */
+    timeoutMs?: number;
+}
+declare function oneDrive(opts: OneDriveOptions): ConnectorAdapter;
+
+/**
+ * Microsoft Graph SharePoint connector — file/site surface for the agent.
+ *
+ *   search_sites(query)                                   → read
+ *     `GET /sites?search=<query>` — find SharePoint sites the connected
+ *     user can see. Returns the minimum fields the agent needs to chain a
+ *     drive/file call: id (composite "host,site-id,web-id"), name, webUrl.
+ *
+ *   list_drive_items(siteId[, folderId])                  → read
+ *     `GET /sites/{siteId}/drive/root/children` (or `/items/{folderId}/children`).
+ *     Returns the children of a site's default document library, or a
+ *     subfolder if `folderId` is supplied. The agent uses this to walk
+ *     the tree before downloading or uploading.
+ *
+ *   search_drive(siteId, query)                           → read
+ *     `GET /sites/{siteId}/drive/root/search(q='<query>')` — server-side
+ *     content + filename search across a site's default drive.
+ *
+ *   get_item_content(siteId, itemId)                      → read
+ *     `GET /sites/{siteId}/drive/items/{itemId}/content` — pull the bytes
+ *     of a small text/json/csv file. We cap at 4 MiB and return decoded
+ *     UTF-8; binary or oversize → `{ binary: true, downloadUrl }` so the
+ *     caller can stream out-of-band.
+ *
+ *   upload_file(siteId, parentFolderId, filename, content[, contentType])
+ *                                                         → mutation; cas: 'native-idempotency'
+ *     `PUT /sites/{siteId}/drive/items/{parentFolderId}:/{filename}:/content`
+ *     — small-file upload (<= 4 MiB). Graph exposes `@odata.etag` on the
+ *     returned `DriveItem`, so we emit `etagAfter` for downstream CAS. No
+ *     `Idempotency-Key` header at the Graph layer — `MutationGuard` above
+ *     the connector handles dedup-on-retry by key.
+ *
+ *   create_folder(siteId, parentFolderId, name)           → mutation; cas: 'native-idempotency'
+ *     `POST /sites/{siteId}/drive/items/{parentFolderId}/children` with a
+ *     `folder` facet and `@microsoft.graph.conflictBehavior: 'fail'`. Graph
+ *     enforces sibling-name uniqueness within a parent, so (parentFolderId,
+ *     name) is the natural idempotency tuple — `MutationGuard` short-circuits
+ *     duplicate posts by key, and a true cross-tenant conflict surfaces as
+ *     `ResourceContention`.
+ *
+ * Auth: standard OAuth2 against the v2.0 endpoint, same client/secret as
+ * microsoft-calendar / microsoft-teams / outlook-mail (one M365 app). The
+ * `Sites.Read.All` scope is required for the read surface; `Files.ReadWrite.All`
+ * is required for upload + create-folder. `offline_access` is required to
+ * receive a `refresh_token` from v2.0 — without it the connection silently
+ * dies after the access token's first hour.
+ *
+ * Consistency model: 'authoritative'. SharePoint exposes etags on every
+ * DriveItem, so callers can chain a list/get → mutation under real CAS for
+ * follow-up patch/delete flows (those land in a follow-up — this adapter
+ * stays scoped to the create/upload/discovery surface that satisfies the
+ * Tier-1 storage pack on the catalog).
+ */
+
+/** OAuth client config the factory closes over. Caller resolves these
+ *  at construction time (env, DB, secret manager — package doesn't care). */
+interface SharePointOptions {
+    clientId: string;
+    clientSecret: string;
+}
+declare function sharepoint(opts: SharePointOptions): ConnectorAdapter;
+
+declare const activecampaignConnector: ConnectorAdapter;
+
+declare const kustomerConnector: ConnectorAdapter;
+
+declare const savvycalConnector: ConnectorAdapter;
+
+/**
+ * AirOps public API: workflows ("apps") are invoked sync or async by their
+ * app UUID; async runs return an execution UUID that can be polled via the
+ * executions endpoint. The API key is provisioned per workspace and presented
+ * as a Bearer token.
+ *
+ * Reference: https://app.airops.com/public_api
+ */
+declare const airOpsConnector: ConnectorAdapter;
+
+/**
+ * AgentX (https://www.agentx.so) is a hosted multi-agent platform that
+ * exposes conversation, message, and agent-search endpoints. The public REST
+ * surface is rooted at `/api/v1` and authenticated with a personal API key
+ * presented as `Authorization: Bearer <key>` (the same shape Activepieces
+ * uses for its piece-agentx connector).
+ *
+ * Capabilities mirror the upstream actions array verbatim:
+ *   - createConversationWithSingleAgent  → conversations.createWithSingleAgent
+ *   - sendMessageToExistingConversation  → conversations.sendMessage
+ *   - findMessage                        → messages.find
+ *   - searchAgents                       → agents.search
+ *   - findConversation                   → conversations.find
+ *
+ * Triggers (newAgent, newConversation) are surfaced upstream as Activepieces
+ * polling triggers; the declarative-REST connector models them as read
+ * capabilities so the agent can poll on its own schedule.
+ */
+declare const agentxConnector: ConnectorAdapter;
+
+/**
+ * Afforai connector.
+ *
+ * Afforai is a research assistant that lets users build chatbots over a
+ * private corpus of uploaded documents. The external integration surface
+ * is intentionally narrow: a single ask-the-chatbot endpoint that accepts
+ * a sessionID (the chatbot the user has provisioned in the Afforai UI),
+ * a chat-history array, and the next user turn, and returns the
+ * assistant response synthesized over the bot's document set.
+ *
+ * Auth is a tenant-issued API key delivered as a bearer token. There is
+ * no OAuth surface — Afforai does not expose a 3-legged flow.
+ *
+ * Consistency: chatbot responses are non-deterministic (LLM-backed) and
+ * carry external billing-class effects (each call is a metered query
+ * against the tenant's plan). CAS posture is therefore `none` — the
+ * caller owns dedupe — and `externalEffect: true` so the orchestrator's
+ * dry-run policy treats this as a side-effecting call.
+ */
+declare const afforaiConnector: ConnectorAdapter;
+
+/**
+ * Aidbase connector.
+ *
+ * Aidbase is an AI-powered customer-support platform (chatbot, ticketing,
+ * FAQ/knowledge-base). The public REST API is bearer-authenticated against
+ * `https://api.aidbase.ai/v1` with a workspace API key minted from the
+ * Aidbase dashboard.
+ *
+ * Surface covered: knowledge-source ingestion (add video / website / FAQ
+ * item), FAQ container creation, chatbot reply generation, and training
+ * job kickoff. All six declared capabilities map 1:1 to the activepieces
+ * `actions` array for the `aidbase` piece.
+ *
+ * Webhook-shaped triggers (email.received, ticket.created, …) are not
+ * modeled here because they are server-push, not client-pull — they belong
+ * in a webhook-subscription adapter and would not be invokable through the
+ * declarative-REST `executeRead` / `executeMutation` seam.
+ */
+declare const aidbaseConnector: ConnectorAdapter;
+
+/**
+ * Acumbamail adapter — REST/form API at https://acumbamail.com/api/1/.
+ *
+ * Auth: API key, forwarded as the `auth_token` query parameter on every
+ * call (Acumbamail does not honor Authorization headers).
+ *
+ * Actions mirror the activepieces catalog entry for `acumbamail`: subscriber
+ * lifecycle, list lifecycle, and template duplication. Response format is
+ * forced to JSON via the `response_type=json` query knob included on every
+ * request that supports it.
+ */
+declare const acumbamailConnector: ConnectorAdapter;
+
+/**
+ * AiPrise KYC / KYB / fraud-prevention connector.
+ *
+ * Authentication: workspace API key delivered in the `X-API-Key` header.
+ * AiPrise also runs a two-environment split (sandbox + live) gated by a
+ * separate key; environment selection is the caller's concern — the same
+ * declarative manifest works against either host because the spec only fixes
+ * the production hostname. Sandbox callers can override `baseUrl` at the
+ * source-metadata level once that surface is wired through.
+ *
+ * Capability surface mirrors the activepieces actions list one-for-one so the
+ * catalog → adapter mapping is verifiable:
+ *   - identity verifications (start, get URL, get result, get user input)
+ *   - business verifications (start, get result, get input)
+ *   - document checks
+ *   - profile CRUD (create / read business + user profiles, list business docs)
+ *   - decision override (update verification result)
+ *   - business directory search
+ */
+declare const aipriseConnector: ConnectorAdapter;
+
+declare const aircallConnector: ConnectorAdapter;
+
+declare const amazonBedrockConnector: ConnectorAdapter;
+
+declare const amazonSecretsManagerConnector: ConnectorAdapter;
+
+declare const airtopConnector: ConnectorAdapter;
+
+/**
+ * @stable Alai connector — AI-powered presentation generation.
+ *
+ * Alai is a REST + API-key product (header: `Authorization: Bearer <key>`).
+ * Public API base: https://api.getalai.com
+ *
+ * The activepieces catalog exposes five actions on the Alai surface:
+ *   - generate.presentation   (write)      POST /presentations/generate
+ *   - get.generation          (read)       GET  /generations/{generationId}
+ *   - export.presentation     (write)      POST /presentations/{presentationId}/export
+ *   - add.slide               (write)      POST /presentations/{presentationId}/slides
+ *   - delete.presentation     (destructive) DELETE /presentations/{presentationId}
+ *
+ * Consistency model is `authoritative`: Alai is the system of record for the
+ * presentations it generates, and read-after-write of a generation job returns
+ * Alai's own status — our adapter does not cache derived state.
+ */
+declare const alaiConnector: ConnectorAdapter;
+
+/**
+ * AltText.ai (https://alttext.ai) generates SEO-friendly, accessible alt text
+ * for images using AI vision models. The public REST API is rooted at
+ * `https://alttext.ai/api/v1` and authenticated with a personal API key
+ * presented as `X-API-Key: <key>` — the same shape Activepieces uses for
+ * `@activepieces/piece-alt-text-ai`.
+ *
+ * Capability surface mirrors the upstream `generateAltTextAction`:
+ *   - generateAltTextAction → images.generateAltText
+ *
+ * The upstream action exposes four input fields:
+ *   - image            (required) — URL or base64-encoded image bytes
+ *   - keywords         (optional) — phrases to bias the alt text toward
+ *   - negativeKeywords (optional) — phrases to exclude from the alt text
+ *   - keywordSource    (optional) — free text used to derive keywords
+ * which we forward verbatim to POST /images so downstream agents can pass
+ * the same field names the Activepieces piece accepts.
+ */
+declare const altTextAiConnector: ConnectorAdapter;
+
+declare const alttextifyConnector: ConnectorAdapter;
+
+declare const amazonSesConnector: ConnectorAdapter;
+
+declare const amazonSnsConnector: ConnectorAdapter;
+
+declare const amazonSqsConnector: ConnectorAdapter;
+
+declare const amazonTextractConnector: ConnectorAdapter;
+
+declare const apitemplateIoConnector: ConnectorAdapter;
+
+declare const ampecoConnector: ConnectorAdapter;
+
+declare const appfollowConnector: ConnectorAdapter;
+
+declare const apitableConnector: ConnectorAdapter;
+
+/**
+ * Aminos (Aminos One) adapter — self-hosted/per-tenant SaaS panel.
+ *
+ * Base URL is per-tenant and supplied via connection metadata under the
+ * `baseUrl` key (matches the catalog `base_url` auth field). The API key is
+ * the `access_token` field; default credential placement is the
+ * Authorization header.
+ *
+ * Catalog action surface: a single `createUser` mutation that provisions an
+ * Aminos One end-user under the connecting account's plan.
+ */
+declare const aminosConnector: ConnectorAdapter;
+
+declare const apolloConnector: ConnectorAdapter;
+
+/**
+ * Ashby ATS (https://developers.ashbyhq.com).
+ *
+ * Auth: HTTP Basic with the API key as the username and an empty password.
+ * The catalog entry lists no explicit actions, so the surface below maps the
+ * documented public API resources (candidate, job, application, offer,
+ * feedback, interview, interviewSchedule). All Ashby endpoints are HTTP POST
+ * with a JSON body — there are no GET reads — so query-class capabilities
+ * model `*.list` / `*.info` calls as POSTs with a body envelope.
+ */
+declare const ashbyConnector: ConnectorAdapter;
+
+/**
+ * AssemblyAI connector — speech-to-text, audio intelligence, and LeMUR LLM
+ * operations over a stored transcript.
+ *
+ * Authentication: workspace API key delivered in the `Authorization` header
+ * verbatim (no `Bearer` prefix — AssemblyAI's API accepts the raw key). The
+ * declarative-rest engine's header placement with an empty prefix matches
+ * the vendor's documented contract.
+ *
+ * Endpoint surface: transcript submit + poll + list + delete, paragraph and
+ * sentence views over a finished transcript, subtitle export (SRT/VTT), word
+ * search, redacted-audio retrieval, and the LeMUR generation endpoints
+ * (summary, Q&A, action items, free-form task) keyed by transcript ids.
+ *
+ * Multipart audio UPLOAD against POST /v2/upload is intentionally not declared
+ * here — the declarative-rest engine JSON-encodes bodies and would corrupt a
+ * raw binary payload. Callers should either pass a public `audio_url` to
+ * `transcripts.submit` or use a bespoke upload adapter.
+ */
+declare const assemblyaiConnector: ConnectorAdapter;
+
+/**
+ * @stable Avian connector — OpenAI-compatible chat completions on api.avian.io.
+ *
+ * Avian exposes an OpenAI-compatible inference surface for hosted language
+ * models. The activepieces piece-avian publishes a single `askAvian` action;
+ * underneath it is a `POST /v1/chat/completions` call with the standard
+ * OpenAI request shape (model, messages, temperature, top_p, frequency_penalty,
+ * presence_penalty, max_tokens, response_format).
+ *
+ * API base : https://api.avian.io
+ * Auth     : `Authorization: Bearer <api-key>` (api-key credential).
+ * Docs     : https://docs.avian.io
+ *
+ * Consistency model is `authoritative`: Avian is the system of record for
+ * the completions it returns — adapters do not cache or replay them.
+ */
+declare const avianConnector: ConnectorAdapter;
+
+declare const asknewsConnector: ConnectorAdapter;
+
+declare const avomaConnector: ConnectorAdapter;
+
+declare const azureCommunicationServicesConnector: ConnectorAdapter;
+
+declare const autocallsConnector: ConnectorAdapter;
+
+/**
+ * Microsoft Entra ID (Azure Active Directory) connector backed by Microsoft Graph v1.0.
+ *
+ * Auth: OAuth2 (authorization code or client credentials) against the v2.0 endpoint.
+ * The tenant id (`common`, `organizations`, or a directory id / verified domain) is
+ * substituted into the authorize/token URLs at client-registration time when the
+ * caller wants to scope the connection to a single tenant. The default endpoints
+ * below use `common` so the same connector serves multi-tenant SaaS app registrations;
+ * single-tenant operators override authorizationUrl/tokenUrl with their own tenant id.
+ *
+ * Docs:
+ *   - https://learn.microsoft.com/graph/api/overview?view=graph-rest-1.0
+ *   - https://learn.microsoft.com/entra/identity-platform/v2-oauth2-auth-code-flow
+ *   - https://learn.microsoft.com/graph/permissions-reference
+ */
+declare const azureAdConnector: ConnectorAdapter;
+
+declare const barcodeLookupConnector: ConnectorAdapter;
+
+declare const azureOpenaiConnector: ConnectorAdapter;
+
+/**
+ * Backblaze B2 connector — S3-compatible object storage.
+ *
+ * The activepieces catalog entry models Backblaze as an api-key connector
+ * with four wiring fields: accessKeyId, secretAccessKey, bucket, and region
+ * (endpoint is optional and computed from region when omitted). That maps
+ * directly onto Backblaze B2's S3-compatible REST surface, which lives at
+ *   https://s3.{region}.backblazeb2.com
+ * (e.g. s3.us-west-001.backblazeb2.com) and accepts AWS SigV4-signed
+ * requests against the bucket as a virtual-hosted-style or path-style
+ * resource. Because the declarative-REST adapter carries one base URL per
+ * connector and does not own request-time signing, the manifest here
+ * captures the action surface; SigV4 signing is layered on by the runtime
+ * once it sees the api-key credential bundle (accessKeyId + secretAccessKey).
+ *
+ * Action surface mirrors the activepieces catalog 1:1:
+ *   - files.read         Read object bytes / metadata from a key in the bucket.
+ *   - files.s3_upload    Upload an object to a key (or folderPath/fileName).
+ *
+ * Triggers (catalog "new.back.blaze.file") are not modeled on the
+ * declarative-REST adapter — Backblaze does not emit native webhooks for
+ * object events; the activepieces trigger polls the bucket. Polling-style
+ * triggers belong in a poller adapter, not a request/response adapter,
+ * so they're intentionally omitted here.
+ *
+ * Consistency model is `authoritative`: B2's bucket APIs return canonical
+ * post-write state (the upload response carries the assigned fileId, sha1,
+ * and content metadata), so a successful 2xx is the source of truth.
+ *
+ * CAS:
+ *   - files.read is a plain read.
+ *   - files.s3_upload is marked `native-idempotency` because B2 lets the
+ *     client supply an `X-Bz-Content-Sha1` (or use the S3 `If-None-Match: *`
+ *     header on the PUT) to make the upload conditional / dedupable on the
+ *     destination key.
+ */
+declare const backblazeConnector: ConnectorAdapter;
+
+declare const baremetricsConnector: ConnectorAdapter;
+
+/**
+ * Beamer connector.
+ *
+ * Beamer is an in-app announcement / changelog / feedback-board product. The
+ * public REST API is at `https://api.getbeamer.com/v0` and is authenticated by
+ * sending the workspace API key in the `Beamer-Api-Key` request header. Keys
+ * are minted from the Beamer dashboard → Settings → REST API.
+ *
+ * The activepieces `beamer` piece exposes four `actions` and zero `triggers`:
+ *   - createComment           → POST   /feature-requests/{id}/comments
+ *   - createNewFeatureRequest → POST   /feature-requests
+ *   - createBeamerPost        → POST   /posts
+ *   - createVote              → POST   /feature-requests/{id}/votes
+ *
+ * Each maps 1:1 to a `mutation` capability below. Read-side capabilities are
+ * added on top because they are the obvious companions for any LLM agent
+ * (pulling the existing post / feature-request list before deciding what to
+ * mutate). Webhooks / SSE triggers are not modeled — they belong in a
+ * subscription adapter, not the declarative-REST request/response seam.
+ */
+declare const beamerConnector: ConnectorAdapter;
+
+declare const bettermodeConnector: ConnectorAdapter;
+
+declare const blandAiConnector: ConnectorAdapter;
+
+declare const bitlyConnector: ConnectorAdapter;
+
+declare const biginByZohoConnector: ConnectorAdapter;
+
+declare const billplzConnector: ConnectorAdapter;
+
+declare const bonjoroConnector: ConnectorAdapter;
+
+/**
+ * Bluesky / AT Protocol adapter.
+ *
+ * The piece authenticates by calling `com.atproto.server.createSession` with an
+ * identifier (handle or email) and an app password. The returned access JWT is
+ * then used as a bearer token against the same PDS host for the remaining
+ * `app.bsky.*` XRPC endpoints. The connector framework treats the resolved
+ * bearer token as the api-key credential and surfaces the PDS host through the
+ * baseUrl + per-action XRPC paths.
+ *
+ * Default PDS host: https://bsky.social
+ */
+declare const blueskyConnector: ConnectorAdapter;
+
+declare const bolnaConnector: ConnectorAdapter;
+
+declare const bexioConnector: ConnectorAdapter;
+
+declare const bookedinConnector: ConnectorAdapter;
+
+declare const browseAiConnector: ConnectorAdapter;
+
+/**
+ * Brilliant Directories adapter — per-tenant REST API hosted on each
+ * customer's directory instance (e.g. https://example.com/api). The base
+ * URL is supplied at connect time via `source.metadata.siteUrl`; the API
+ * key is the `X-Api-Key` header generated from the admin panel at
+ * https://ww2.managemydirectory.com/admin/apiSettings.
+ *
+ * Actions mirror the activepieces catalog entry for `brilliant-directories`,
+ * which exposes a single write action: createNewUser.
+ */
+declare const brilliantDirectoriesConnector: ConnectorAdapter;
+
+declare const campaignMonitorConnector: ConnectorAdapter;
+
+declare const braveSearchConnector: ConnectorAdapter;
+
+declare const captainDataConnector: ConnectorAdapter;
+
+declare const certopusConnector: ConnectorAdapter;
+
+declare const chainalysisApiConnector: ConnectorAdapter;
+
+declare const cannyConnector: ConnectorAdapter;
+
+declare const capsuleCrmConnector: ConnectorAdapter;
+
+declare const cashfreePaymentsConnector: ConnectorAdapter;
+
+declare const chargebeeConnector: ConnectorAdapter;
+
+declare const chargekeepConnector: ConnectorAdapter;
+
+/**
+ * Chatling connector.
+ *
+ * Chatling lets tenants build AI chatbots trained on their own data
+ * (documents, URLs, custom Q&A). The integration surface exposes two
+ * write actions — sending a message to a configured chatbot and
+ * provisioning a new chatbot — and two event-shaped triggers that the
+ * SDK surfaces as read capabilities the orchestrator can poll
+ * (new-conversation, new-contact). Webhook-style push isn't part of
+ * the declarative-REST contract, so we model the trigger surface as
+ * authoritative reads.
+ *
+ * Auth is a tenant-issued API key delivered as a bearer token. There
+ * is no OAuth flow — Chatling does not expose a 3-legged client.
+ *
+ * Consistency: send.message is non-deterministic (LLM-backed) and
+ * carries metered billing, so CAS is `none` and `externalEffect: true`.
+ * create.chatbot is a provisioning call against the tenant's account;
+ * Chatling does not honour a client-supplied idempotency key, so the
+ * caller owns dedupe. The read-shaped triggers are authoritative —
+ * Chatling is the source of truth for its conversation log.
+ */
+declare const chatlingConnector: ConnectorAdapter;
+
+declare const chatbaseConnector: ConnectorAdapter;
+
+declare const chartlyConnector: ConnectorAdapter;
+
+/**
+ * Chatwoot — open-source customer engagement platform.
+ *
+ * Auth: per-user API access token (Profile Settings → API Access Token),
+ * sent as the `api_access_token` header on every request. The instance
+ * URL is configurable because Chatwoot is self-hostable; the cloud-hosted
+ * default is `https://app.chatwoot.com`.
+ *
+ * Surface covered:
+ * - send.message (mirrors the upstream `sendMessage` action — POST a
+ *   message into an existing conversation, optionally as a private note)
+ */
+declare const chatwootConnector: ConnectorAdapter;
+
+/**
+ * Chat Data connector.
+ *
+ * Chat Data is a chatbot-as-a-service platform: create AI chatbots backed by
+ * model providers + custom training material (scraped URLs, free-form text,
+ * uploaded files, Q&A pairs, product catalogs) and drive conversations with
+ * them through a REST API. Optional integrations cover live-chat escalation
+ * and custom backend dispatch.
+ *
+ * The public REST API is bearer-authenticated against
+ * `https://api.chat-data.com/api/v2` with a workspace API key minted from the
+ * Chat Data dashboard. All six declared capabilities map 1:1 to the
+ * activepieces `actions` array for the `chat-data` piece — there are no
+ * read-class endpoints in the activepieces surface (every action is risk
+ * `write` or `destructive`).
+ *
+ * The `chat` category in the activepieces catalog has no analogue in our
+ * `Manifest.category` enum, so we map to `comms` — the closest matching
+ * concept (conversation-oriented messaging surface).
+ */
+declare const chatDataConnector: ConnectorAdapter;
+
+declare const circleConnector: ConnectorAdapter;
+
+declare const checkoutConnector: ConnectorAdapter;
+
+/**
+ * ChatNode connector.
+ *
+ * ChatNode is a hosted no-code AI chatbot builder. Workspace owners train
+ * a bot against documents/URLs/FAQs, then expose it as a chat widget or a
+ * REST endpoint that takes a user message and returns a generated reply
+ * against the trained corpus.
+ *
+ * The public REST API is bearer-authenticated against
+ * `https://www.chatnode.ai/api/v2`. The API key is workspace-scoped and
+ * minted from the ChatNode dashboard. Each call also requires a `botId`
+ * identifying which trained bot to query; the activepieces piece exposes
+ * `botId` as an authField — we keep it as an explicit per-call parameter
+ * here so a single credential can address multiple bots in the same
+ * workspace without re-binding the connection.
+ *
+ * The activepieces `chatnode` piece ships exactly one action,
+ * `askChatbotAction`, which we model as `chatbot.ask`. It is a write-class
+ * action on the activepieces side because each call mutates the chat
+ * session transcript on the ChatNode side (the answer is persisted under
+ * the `chatSessionId`). There are no read actions and no triggers in the
+ * upstream piece.
+ */
+declare const chatnodeConnector: ConnectorAdapter;
+
+declare const cloudinaryConnector: ConnectorAdapter;
+
+declare const clockodoConnector: ConnectorAdapter;
+
+declare const clockifyConnector: ConnectorAdapter;
+
+declare const cloutlyConnector: ConnectorAdapter;
+
+/**
+ * Clearout adapter — email verification REST API at https://api.clearout.io.
+ *
+ * Auth: API token issued from the Clearout dashboard, sent as a Bearer token
+ * on the Authorization header (the placement Clearout documents for its v2
+ * REST surface).
+ *
+ * The activepieces catalog ships a single action — `instant.verify` — backed
+ * by `POST /v2/email_verify/instant`, which scores a single email address in
+ * real time. We classify it as a mutation because each call is metered and
+ * consumes account credits; CAS is `native-idempotency` since the API treats
+ * repeat lookups of the same address as cache hits within the verification
+ * window.
+ */
+declare const clearoutConnector: ConnectorAdapter;
+
+declare const clicdataConnector: ConnectorAdapter;
+
+declare const cognitoFormsConnector: ConnectorAdapter;
+
+declare const cohereConnector: ConnectorAdapter;
+
+declare const cloudconvertConnector: ConnectorAdapter;
+
+/**
+ * CometAPI connector.
+ *
+ * CometAPI is a unified inference gateway that fronts multiple model
+ * providers (OpenAI, Anthropic, Google, Meta, Mistral, …) behind a single
+ * OpenAI-compatible REST surface. A single bearer API key authenticates every
+ * call; routing to a specific underlying provider is done by the `model`
+ * field on the request body — there is no per-provider endpoint.
+ *
+ * The activepieces catalog ships a single high-level action (`ask.comet.api`)
+ * which is a thin wrapper over the chat-completions endpoint. We expose that
+ * as the primary `chat.completions.create` capability and add the rest of the
+ * OpenAI-compatible surface CometAPI documents (models list, embeddings,
+ * images) so the agent has a real tool kit, not just one knob.
+ *
+ * Consistency model: `advisory`. Every mutation here is a stateless
+ * generation call — replaying it yields a different sample, never the same
+ * record, so authoritative semantics would be a lie. The caller's
+ * MutationGuard owns at-most-once delivery via an idempotency token if it
+ * cares.
+ */
+declare const cometapiConnector: ConnectorAdapter;
+
+/**
+ * Comfy.ICU adapter — hosted ComfyUI runner at https://comfy.icu/api/v1/.
+ *
+ * Auth: API key, forwarded as `Authorization: Bearer <token>` per Comfy.ICU's
+ * REST docs. The catalog maps four actions and three triggers; only actions
+ * are surfaced as capabilities here (triggers are out-of-band webhooks
+ * configured by the user in the Comfy.ICU UI).
+ *
+ * Capability slugs mirror the upstream `id` fields verbatim so trace events
+ * cross-reference the activepieces catalog one-to-one.
+ */
+declare const comfyicuConnector: ConnectorAdapter;
+
+declare const constantContactConnector: ConnectorAdapter;
+
+declare const crispConnector: ConnectorAdapter;
+
+declare const convertkitConnector: ConnectorAdapter;
+
+/**
+ * Dashworks connector.
+ *
+ * Dashworks is an enterprise answer engine that lets workspace users build
+ * "Bots" backed by federated search over connected SaaS sources (Notion,
+ * Slack, Confluence, Drive, etc.). The public Bots API exposes a single
+ * synthesize-an-answer endpoint that targets a specific bot by ID and
+ * returns a grounded response with optional inline source citations.
+ *
+ * Auth is a tenant-issued API key delivered as a bearer token; there is no
+ * documented OAuth surface for the Bots API.
+ *
+ * Consistency: answers are LLM-synthesized over a non-deterministic
+ * retrieval pass and each call is a metered query against the tenant's
+ * Dashworks plan. CAS posture is therefore `none` — the caller owns
+ * dedupe — and `externalEffect: true` so the orchestrator's dry-run
+ * policy treats this as a side-effecting call.
+ */
+declare const dashworksConnector: ConnectorAdapter;
+
+/**
+ * Copy.ai connector.
+ *
+ * Copy.ai exposes a Workflows API: tenants design a workflow in the Copy.ai
+ * UI (a chain of prompt + retrieval steps that produces marketing copy or
+ * other structured text output), then external callers trigger that
+ * workflow with a JSON input payload, poll the run for status, and read
+ * the final outputs.
+ *
+ * Catalog action surface (Activepieces piece-copy-ai 0.1.3):
+ *   - run.workflow              -> runWorkflowAction
+ *   - get.workflow.run.status   -> getWorkflowRunStatusAction
+ *   - get.workflow.run.outputs  -> getWorkflowRunOutputsAction
+ * The catalog also declares a workflowRunCompletedTrigger which the
+ * vendor implements as polling, not webhooks; surfacing it here would
+ * require a poll-driver capability that this declarative-REST shape does
+ * not model, so triggers are intentionally not exposed and the runtime
+ * must compose status polling on top of the read capabilities below.
+ *
+ * Auth: tenant-issued API key, sent via the `x-copy-ai-api-key` header on
+ * every request (Copy.ai does not accept Bearer placement).
+ *
+ * Consistency:
+ *   - run.workflow is LLM-backed, non-deterministic, and bills the tenant
+ *     on every invocation. CAS = `none`, externalEffect = true so the
+ *     orchestrator's dry-run policy treats it as side-effecting and
+ *     callers own dedupe (workflowRunId is server-issued so we cannot
+ *     supply a client idempotency key).
+ *   - status/outputs reads are advisory snapshots of an in-flight run.
+ */
+declare const copyAiConnector: ConnectorAdapter;
+
+declare const datafuelConnector: ConnectorAdapter;
+
+/**
+ * Cryptolens adapter — Software Licensing as a Service (SLaaS).
+ *
+ * Auth: API key (Cryptolens access token), forwarded as the `token` form
+ * parameter on every Web API call. The Cryptolens Web API is form-encoded
+ * (not JSON) and exposes endpoints under https://api.cryptolens.io/api/.
+ *
+ * Actions mirror the activepieces catalog entry for `cryptolens`:
+ *   - add.customer  → POST /api/customer/AddCustomer
+ *   - block.key     → POST /api/key/BlockKey
+ *   - create.key    → POST /api/key/CreateKey
+ *
+ * The catalog also lists a `new.api.event` trigger; triggers are out of
+ * scope for declarative-REST adapters (the connector contract is action
+ * surface, not webhook intake), so it is omitted here.
+ */
+declare const cryptolensConnector: ConnectorAdapter;
+
+declare const copperConnector: ConnectorAdapter;
+
+/**
+ * CustomGPT (https://app.customgpt.ai) hosts no-code RAG chatbots backed by
+ * customer-supplied corpora (sitemaps, file uploads). The public REST surface
+ * is rooted at `/api/v1`, authenticated with a workspace API token presented
+ * as `Authorization: Bearer <key>` — the same shape the Activepieces
+ * piece-customgpt connector uses.
+ *
+ * Capabilities mirror the upstream actions array verbatim:
+ *   - createAgent        → agents.create
+ *   - updateAgent        → agents.update
+ *   - deleteAgent        → agents.delete
+ *   - updateSettings     → agents.updateSettings
+ *   - createConversation → conversations.create
+ *   - sendMessage        → conversations.sendMessage
+ *   - findConversation   → conversations.find
+ *   - exportConversation → conversations.export
+ *
+ * The `newConversation` polling trigger upstream is modelled as the read
+ * capability `conversations.list.recent` so the agent can poll on its own
+ * cadence without leaving the declarative-REST contract.
+ */
+declare const customgptConnector: ConnectorAdapter;
+
+declare const deepseekConnector: ConnectorAdapter;
+
+/**
+ * Denser.ai connector.
+ *
+ * Denser.ai hosts retrieval-augmented chatbots over a tenant-supplied
+ * document/website corpus. The external integration surface exposed by
+ * the activepieces catalog is a single chat-query endpoint that accepts
+ * a question, the target `chatbotId` from the Denser dashboard, and a
+ * small set of optional generation knobs (model selection, system
+ * prompt, citation inclusion) and returns the chatbot's synthesized
+ * answer.
+ *
+ * Auth is a workspace API key delivered as a bearer token. There is no
+ * OAuth flow — Denser does not document a 3-legged authorization grant.
+ *
+ * Consistency: chatbot responses are non-deterministic (LLM-backed) and
+ * carry external billing-class effects (each call is a metered query
+ * against the tenant's Denser plan). CAS posture is therefore `none` —
+ * the caller owns dedupe — and `externalEffect: true` so the orchestrator
+ * treats the call as side-effecting under dry-run policy.
+ */
+declare const denserAiConnector: ConnectorAdapter;
+
+declare const devinConnector: ConnectorAdapter;
+
+/**
+ * Descript public API connector.
+ *
+ * Capability set mirrors the activepieces `@activepieces/piece-descript` piece:
+ *   - descript.agent.edit       → POST /agent/jobs        (Underlord prompt run on a project)
+ *   - descript.get.job.status   → GET  /agent/jobs/{id}   (read job state + result URL)
+ *   - descript.get.project      → GET  /projects/{id}     (single project fetch)
+ *   - descript.import.media     → POST /projects/{id}/media (URL-import + optional composition)
+ *   - descript.list.projects    → GET  /projects          (filter/sort)
+ *   - descript.publish.project  → POST /projects/{id}/publish (export + share)
+ *
+ * Auth is an API key (Descript "Personal API token" in workspace settings),
+ * sent as `Authorization: Bearer <token>` — matched by the piece's
+ * `PieceAuth.SecretText` shape.
+ */
+declare const descriptConnector: ConnectorAdapter;
+
+/**
+ * DatoCMS Content Management API (https://www.datocms.com/docs/content-management-api).
+ *
+ * Auth: Bearer API token (project full-access or CMA token). The activepieces
+ * catalog entry exposes an `apiKey` + optional `environment` (sandbox env name)
+ * field; we model the bearer here and document the sandbox-environment header
+ * on each capability that supports it. The CMA requires `X-Api-Version: 3` and
+ * `Accept: application/json` on every request.
+ *
+ * The catalog `actions` array is empty (the activepieces piece is currently a
+ * stub), so the capability surface below covers the documented CMA resources
+ * we care about for an agent integration: items (records), item types
+ * (models), uploads, environments, users, and webhooks. Reads use plural
+ * `*.list` / singular `*.get`; mutations use REST verbs (POST/PUT/DELETE) on
+ * the canonical CMA paths.
+ */
+declare const datocmsConnector: ConnectorAdapter;
+
+declare const dittofeedConnector: ConnectorAdapter;
+
+declare const documergeConnector: ConnectorAdapter;
+
+/**
+ * Doctly AI document conversion API.
+ *
+ * Doctly turns PDFs into markdown via an async job:
+ *   1. POST /documents/ to upload — returns `{ id, status }`.
+ *   2. GET  /documents/{id} polls — terminal states are `COMPLETED` / `FAILED`.
+ *      A completed job exposes `output_file_url` for the markdown payload.
+ *
+ * Activepieces ships one curated action (`convertPdfToTextAction`) which
+ * bundles the upload + polling loop. We expose the two real REST steps as
+ * separate capabilities so the agent can orchestrate the poll itself (and so
+ * a long-running upload doesn't hold a single tool call open for minutes).
+ *
+ * Notes:
+ *   - The `documents.create` upload is `multipart/form-data` in Activepieces.
+ *     Doctly also accepts a JSON body with a base64 `file` field (this is what
+ *     their hosted dashboard SDK calls — see api.doctly.ai/redoc). We use the
+ *     JSON path because the declarative REST runtime is JSON-only; multipart
+ *     would need a bespoke executor and the JSON variant is the same
+ *     resource.
+ *   - Bearer auth is the same Doctly secret-text API key the catalog declares.
+ */
+declare const doctlyConnector: ConnectorAdapter;
+
+declare const dumplingAiConnector: ConnectorAdapter;
+
+declare const dubConnector: ConnectorAdapter;
+
+/**
+ * DocumentPro connector.
+ *
+ * DocumentPro is an AI-powered document-processing service that extracts
+ * structured fields from uploaded PDFs / images using either templated
+ * Workflows or a general OCR + LLM pipeline. The customer first uploads
+ * a file (multipart POST /v1/documents), then runs an extract Workflow
+ * against the document_id returned by upload
+ * (GET /v1/documents/{id}/run_parser?template_id=...).
+ *
+ * Auth is a per-tenant API key delivered as the `x-api-key` header — no
+ * OAuth surface exists. The key is sent on every call.
+ *
+ * Why only `run.extract` is modeled here:
+ *   The activepieces piece exposes two actions, `uploaddocument` and
+ *   `run.extract`. Upload is multipart/form-data; the declarative-REST
+ *   adapter only serializes JSON bodies, so wiring upload through this
+ *   adapter would silently corrupt the request. Upload belongs in a
+ *   bespoke adapter (binary body + Blob) rather than a fake JSON shim.
+ *   `run.extract` is a clean GET with query parameters and maps directly.
+ *
+ * Consistency: extraction is non-deterministic (LLM-backed), each call
+ * is metered, and there is no idempotency key on the upstream — so CAS
+ * posture is `none` and `externalEffect: true` to keep the orchestrator
+ * out of accidental dry-run replays. The connector advertises an
+ * `advisory` default consistency model: a previous extract's output is
+ * cacheable for read-after-write within a session, but the upstream is
+ * not the authoritative store of the parsed value (the Workflow owner is).
+ */
+declare const documentproConnector: ConnectorAdapter;
+
+declare const elasticEmailConnector: ConnectorAdapter;
+
+/**
+ * Eden AI connector.
+ *
+ * Eden AI is an aggregator API that proxies a uniform request shape to many
+ * underlying providers (OpenAI, Cohere, Google, AWS, Microsoft, etc.). Each
+ * endpoint accepts a `providers` field whose value is a comma-separated list
+ * of provider keys; the first entry is the primary and any following entries
+ * are fallbacks tried in order.
+ *
+ * Auth: workspace API key sent as a Bearer token on the Authorization header.
+ * Eden does not expose an OAuth surface; the only credential is the key
+ * minted from the dashboard at https://app.edenai.run/admin/api-settings.
+ *
+ * Consistency model: `advisory`. Every action mutates state on third-party
+ * provider backends (text generated, audio synthesized, OCR billed) and Eden
+ * does not honour an idempotency key on the aggregation endpoints, so replay
+ * yields a fresh charge and a fresh sample. Callers own dedupe.
+ */
+declare const edenAiConnector: ConnectorAdapter;
+
+/**
+ * Easy-Peasy.AI connector.
+ *
+ * Easy-Peasy.AI exposes a small REST surface for AI generation tasks:
+ *   - Custom text generation through tenant-defined generators
+ *   - AI image generation across multiple model backends
+ *   - Asynchronous audio transcription against a hosted audio URL
+ *
+ * Catalog action surface (Activepieces piece-easy-peasy-ai 0.1.4):
+ *   - custom.generator.text  -> customGeneratorText
+ *   - generate.ai.image      -> generateAiImage
+ *   - get.ai.transcription   -> getAiTranscription
+ *
+ * Auth: tenant-issued API key, sent in the Authorization header as
+ * `Bearer <key>` on every request.
+ *
+ * Consistency:
+ *   - All three operations are LLM/model-backed, non-deterministic, and
+ *     billed per call. CAS = `none`, externalEffect = true so the
+ *     orchestrator treats them as side-effecting and the caller owns
+ *     dedupe (Easy-Peasy.AI does not accept a client idempotency key).
+ *   - Transcription returns asynchronously: the create call returns a job
+ *     handle and the read capability is used to poll the result.
+ */
+declare const easyPeasyAiConnector: ConnectorAdapter;
+
+declare const dustConnector: ConnectorAdapter;
+
+declare const emailoctopusConnector: ConnectorAdapter;
+
+declare const emailitConnector: ConnectorAdapter;
+
+declare const esignaturesConnector: ConnectorAdapter;
+
+declare const firefliesAiConnector: ConnectorAdapter;
+
+declare const firecrawlConnector: ConnectorAdapter;
+
+declare const fathomAnalyticsConnector: ConnectorAdapter;
+
+declare const enrichlayerConnector: ConnectorAdapter;
+
+declare const fathomConnector: ConnectorAdapter;
+
+declare const filloutFormsConnector: ConnectorAdapter;
+
+declare const facebookLeadsConnector: ConnectorAdapter;
+
+declare const fireberryConnector: ConnectorAdapter;
+
+declare const flowluConnector: ConnectorAdapter;
+
+declare const flowiseConnector: ConnectorAdapter;
+
+/**
+ * Flipando AI connector.
+ *
+ * Flipando is a no-code platform for assembling LLM-backed "Apps" — small
+ * prompt-and-tool pipelines a workspace owner has provisioned in the
+ * Flipando UI. The external surface lets a caller list the workspace's
+ * apps, run a configured app against an input payload, poll the resulting
+ * async task, and (for the generator surface) ask Flipando to scaffold a
+ * brand-new app from a high-level description.
+ *
+ * Auth is a tenant-issued API key delivered as a bearer token; there is no
+ * OAuth flow. The category in the activepieces catalog is "workflow", which
+ * the connector manifest does not enumerate, so the closest accurate UI
+ * bucket is `other`.
+ *
+ * Consistency: `runApp`, `runAppGenerator`, and any path that triggers an
+ * LLM call is non-deterministic, metered, and externally-effecting. CAS
+ * posture is `none` (the caller owns dedupe) and `externalEffect: true`
+ * so the orchestrator's dry-run policy refuses to execute these in
+ * preview mode. `getTask` and `getAllApps` are pure reads.
+ */
+declare const flipandoConnector: ConnectorAdapter;
+
+declare const folkConnector: ConnectorAdapter;
+
+declare const formbricksConnector: ConnectorAdapter;
+
+declare const formstackConnector: ConnectorAdapter;
+
+/**
+ * Foreplay.co (https://public.api.foreplay.co/api).
+ *
+ * Foreplay is a creative ad library / "swipe file" tool for marketers: it
+ * archives Facebook, Instagram, TikTok, and YouTube ads, lets users save them
+ * into boards ("swipe files"), and tracks competitor brands via "Spyder".
+ *
+ * Auth: a single API key, passed in the `Authorization` header. The
+ * activepieces catalog entry exposes only the auth shape — no actions or
+ * triggers — so the surface below maps the documented public REST resources:
+ * discovery (ad search), ad detail lookup, brand search and ad-by-brand
+ * fetches, swipe-files (boards) listing and item membership, and Spyder
+ * (tracked brand) management.
+ */
+declare const foreplayCoConnector: ConnectorAdapter;
+
+/**
+ * Fountain ATS (https://developer.fountain.com).
+ *
+ * HR hiring + onboarding platform. Auth is an API key obtained from
+ * Profile > Manage API Keys (or Settings > Integrations & API Keys),
+ * sent as `X-ACCESS-TOKEN: <apiKey>` per Fountain's REST conventions.
+ *
+ * Default base URL is https://api.fountain.com/v2; the catalog notes
+ * regional deployments such as us-2.fountain.com/api/v2 — callers that
+ * need a regional host should override via metadata.baseUrl.
+ */
+declare const fountainConnector: ConnectorAdapter;
+
+declare const mailercheckConnector: ConnectorAdapter;
+
+declare const freshsalesConnector: ConnectorAdapter;
+
+/**
+ * Frame.io (Adobe) collaborative video-review workspace
+ * (https://developer.frame.io). The activepieces catalog entry lists no
+ * explicit actions, so the surface below maps the documented v2 REST API
+ * (https://api.frame.io/v2): account/team/project navigation, asset CRUD,
+ * comments, and review links.
+ *
+ * Auth is api-key — Frame.io developer tokens are personal-access tokens
+ * sent as `Authorization: Bearer <token>`. The catalog records
+ * account_id + team_id auth fields so callers can scope subsequent
+ * project/asset operations to a single workspace.
+ */
+declare const frameConnector: ConnectorAdapter;
+
+declare const fragmentConnector: ConnectorAdapter;
+
+/**
+ * Gameball adapter — REST API at https://api.gameball.co/api/v3.0.
+ *
+ * Auth: API key forwarded in the `apiKey` request header. Gameball does not
+ * accept Authorization bearer tokens for the integration endpoints.
+ *
+ * Actions mirror the activepieces catalog entry for `gameball`: a single
+ * `send.event` mutation that posts an event tied to a player. The catalog
+ * exposes only one upstream action (`sendEvent`); additional reads here
+ * (player lookup, balance) are intentionally omitted to stay 1:1 with the
+ * catalog surface.
+ */
+declare const gameballConnector: ConnectorAdapter;
+
+declare const freeAgentConnector: ConnectorAdapter;
+
+declare const freshserviceConnector: ConnectorAdapter;
+
+declare const ghostcmsConnector: ConnectorAdapter;
+
+/**
+ * Gistly connector.
+ *
+ * Gistly (gist.ly) is a hosted YouTube-transcript API. A caller hands it a
+ * YouTube video URL and receives the transcript either as timestamped chunks
+ * or merged into a single text blob.
+ *
+ * Auth: a tenant-issued API key delivered in the `x-api-key` request header.
+ * No OAuth, no refresh — the key is long-lived and rotated out-of-band in the
+ * Gistly dashboard.
+ *
+ * Category: the activepieces catalog labels Gistly as `workflow`, which the
+ * connector manifest does not enumerate. The closest accurate UI bucket is
+ * `other`.
+ *
+ * Consistency: every action is a pure read against a third-party transcript
+ * cache. There is no resource we own that needs CAS, and the upstream YouTube
+ * transcript content is what it is — repeated calls return the same payload.
+ * `authoritative` is correct because Gistly's response is the source of truth
+ * for the transcript value at the time of the call; there is no local mirror
+ * to reconcile.
+ */
+declare const gistlyConnector: ConnectorAdapter;
+
+/**
+ * Google Search Console — site verification, sitemap management, search analytics,
+ * and URL inspection over the Webmasters / Search Console API.
+ *
+ * Auth model: standard Google OAuth2 with the `webmasters` scope. Search Console
+ * exposes two scopes: `webmasters.readonly` (read everything) and `webmasters`
+ * (read + sitemap management + site add/delete). The activepieces piece covers
+ * destructive actions (addSite, deleteSite, submitSitemap), so we request the
+ * full `webmasters` scope. URL Inspection has its own implicit grant: the
+ * inspection endpoint requires `webmasters.readonly` at minimum, and the
+ * `webmasters` scope is a superset.
+ *
+ * Site identifier: every Search Console endpoint is keyed by a `siteUrl` —
+ * either a URL-prefix property (e.g. `https://example.com/`) or a domain
+ * property (e.g. `sc-domain:example.com`). The literal string is encoded into
+ * the path segment; callers pass it verbatim and the declarative-rest runtime
+ * URL-encodes the path segment substitution.
+ *
+ * Consistency: Search Console is an analytics surface backed by Google's
+ * indexing pipeline. Search Analytics data is typically delayed 2–3 days and
+ * the URL inspection result reflects the last time Googlebot crawled the URL,
+ * so we mark this connector as `cache` — agents should not treat its output
+ * as a real-time mirror of the live site.
+ */
+declare const googleSearchConsoleConnector: ConnectorAdapter;
+
+/**
+ * Google Cloud Storage connector — buckets, objects, and ACLs.
+ *
+ * Auth is Google's standard OAuth2 user-grant flow:
+ *   - authorize at https://accounts.google.com/o/oauth2/v2/auth
+ *   - exchange / refresh at https://oauth2.googleapis.com/token
+ *
+ * The activepieces catalog declares `auth: oauth2` with access_token +
+ * refresh_token credential fields, which maps onto the offline-access
+ * variant of the user-grant flow (refresh tokens are minted when the
+ * authorize call includes `access_type=offline&prompt=consent`).
+ *
+ * Scope picked: `devstorage.full_control`. The catalog exposes both
+ * read and write actions (createBucket, deleteEmptyBucket, cloneObject,
+ * deleteObject, createObjectAcl, deleteObjectAcl, createBucketAcl,
+ * deleteBucketAcl, createBucketDefaultObjectAcl,
+ * deleteBucketDefaultObjectAcl, searchObjects, searchBuckets) plus ACL
+ * mutations on both buckets and objects. `read_only` cannot satisfy the
+ * mutation surface, and `read_write` cannot satisfy the ACL surface;
+ * `full_control` is the smallest scope that covers everything declared
+ * in the catalog. Adapters that only need read access should override
+ * `requiredScopes` per-capability via the runtime grant model.
+ *
+ * Action surface mirrors the activepieces catalog 1:1:
+ *   Buckets:
+ *     - buckets.search                   List buckets in a project.
+ *     - buckets.create                   Insert a new bucket.
+ *     - buckets.delete_empty             Delete an empty bucket.
+ *   Objects:
+ *     - objects.search                   List objects in a bucket.
+ *     - objects.clone                    Server-side copy of an object.
+ *     - objects.delete                   Delete an object (or object version).
+ *   Bucket ACLs (the bucket-level ACL collection):
+ *     - bucket_acl.create
+ *     - bucket_acl.delete
+ *   Bucket default object ACLs (applied to newly-created objects):
+ *     - bucket_default_object_acl.create
+ *     - bucket_default_object_acl.delete
+ *   Object ACLs (per-object ACL collection):
+ *     - object_acl.create
+ *     - object_acl.delete
+ *
+ * Triggers (newObjectCreated, objectUpdated) are NOT modeled here. GCS
+ * does not push webhooks for object-change events to arbitrary HTTPS
+ * sinks without a Pub/Sub notification configuration; the activepieces
+ * triggers poll the bucket listing. Polling triggers belong in a poller
+ * adapter, not a request/response adapter, so they are intentionally
+ * omitted.
+ *
+ * Consistency model is `authoritative`: the GCS JSON API returns the
+ * canonical post-write resource representation on every successful 2xx,
+ * including the `generation` (object version) and `metageneration`
+ * counters used for optimistic concurrency. The adapter relies on the
+ * response body as the source of truth for write outcomes.
+ *
+ * CAS:
+ *   - Creates use `native-idempotency`. GCS's object insert accepts the
+ *     `ifGenerationMatch=0` precondition to make creation conditional on
+ *     the destination not already existing; bucket inserts surface 409
+ *     on (project, name) collisions, which the declarative layer maps to
+ *     `{ status: 'conflict' }`.
+ *   - Deletes use `etag-if-match`. Bucket and object deletes accept
+ *     `ifMetagenerationMatch` / `ifGenerationMatch` query preconditions;
+ *     when the runtime carries an `etag` from a prior read, it threads it
+ *     onto the delete request. ACL deletes are scoped by (bucket, entity)
+ *     so collisions are well-defined.
+ *
+ * Base URL is `https://storage.googleapis.com/storage/v1`. Cloud Storage
+ * also exposes an XML API at storage.googleapis.com root, but the
+ * activepieces piece (and the rest action set above) targets the JSON
+ * API exclusively.
+ */
+declare const googleCloudStorageConnector: ConnectorAdapter;
+
+/**
+ * Google BigQuery connector — Query, analyze, and stream data into BigQuery
+ * via the public bigquery.googleapis.com REST surface.
+ *
+ * Connection metadata required:
+ *   - projectId: the GCP project that owns the dataset.
+ *   - datasetId: the dataset (default scope for table-level operations).
+ *
+ * Authorization: OAuth2 against Google's standard endpoints with the
+ * BigQuery read/write scope. Refresh-token flow is handled by the
+ * declarative-rest runtime; the catalog's authFields (access_token /
+ * refresh_token) map to the oauth2 ConnectorCredentials variant.
+ *
+ * Capability naming maps onto the activepieces piece's actions:
+ *   run.query                 → query.run
+ *   create.row / create.rows  → rows.insert.one / rows.insert.many (tabledata.insertAll)
+ *   delete.rows               → rows.delete (DML)
+ *   update.rows               → rows.update (DML)
+ *   find.one.row              → rows.findOne
+ *   find.or.create.row        → rows.findOrCreate
+ *   get.rows.for.job          → jobs.getQueryResults
+ *   import.data               → jobs.load
+ *
+ * Docs:
+ *   - https://cloud.google.com/bigquery/docs/reference/rest
+ *   - https://developers.google.com/identity/protocols/oauth2/scopes#bigquery
+ */
+declare const googleBigqueryConnector: ConnectorAdapter;
+
+declare const googleSearchConnector: ConnectorAdapter;
+
+/**
+ * Google Contacts — OAuth2 Bearer against people.googleapis.com (People API v1).
+ *
+ * The People API is the supported successor to the deprecated Contacts API
+ * v3 and is the surface that Google's own "Contacts" UI, Gmail's address
+ * book, and Workspace's directory share. Every resource is keyed by
+ * `people/{contactId}` (for personal contacts) or `people/{directoryId}`
+ * (for directory entries the user can read). Mutating endpoints require
+ * an `updatePersonFields` mask (PATCH) or a typed body (POST/DELETE) and
+ * use the `Etag` field on the Person resource for optimistic concurrency.
+ *
+ * Scopes:
+ *   - contacts            — read + write personal contacts
+ *   - contacts.readonly   — read personal contacts (used for low-risk reads)
+ *   - contacts.other.readonly — read "Other contacts" auto-imported from
+ *                                Gmail / Calendar interactions
+ *   - directory.readonly  — read the Workspace directory (org users)
+ *   - userinfo.email      — used by the test request below
+ *
+ * See https://developers.google.com/people/api/rest/v1 .
+ */
+declare const googleContactsConnector: ConnectorAdapter;
+
+declare const googlechatConnector: ConnectorAdapter;
+
+declare const googleMyBusinessConnector: ConnectorAdapter;
+
+declare const googleTasksConnector: ConnectorAdapter;
+
+declare const greenptConnector: ConnectorAdapter;
+
+declare const greipConnector: ConnectorAdapter;
+
+/**
+ * GuideLite (https://guidelite.ai) is a hosted assistant platform that lets
+ * organizations build AI assistants and embed them in lead-capture and
+ * workflow surfaces. The public REST surface is rooted at `/api/v1` and
+ * authenticated with an API key presented as `Authorization: Bearer <key>` —
+ * the same shape the Activepieces `piece-guidelite` connector uses.
+ *
+ * Capabilities mirror the upstream actions array verbatim:
+ *   - sendAPrompt → assistant.sendPrompt
+ *
+ * The upstream `newLeadSubmission` trigger is a polling trigger; the
+ * declarative-REST connector models it as a read capability so the agent can
+ * poll for new lead submissions on its own schedule.
+ *
+ * The catalog category is "workflow", which is not a value in the connector
+ * manifest's category union — `other` is the documented fallback for hosted
+ * workflow platforms (matches AgentX and other Activepieces workflow pieces).
+ */
+declare const guideliteConnector: ConnectorAdapter;
+
+/**
+ * Hastewire (https://hastewire.com) is an AI-text humanizer service. The
+ * Activepieces piece exposes two actions backed by the public REST API:
+ *   - detectTextAction   → detect.text    (classify text as AI- vs human-written)
+ *   - humanizeTextAction → humanize.text  (rewrite AI-sounding text to read human)
+ *
+ * Both endpoints accept the input text in the request body and are authenticated
+ * with a personal API key delivered as `Authorization: Bearer <key>`, matching
+ * the api_key auth shape declared in the catalog. The catalog declares no
+ * triggers, so the manifest below is purely action-driven.
+ *
+ * The catalog category is "workflow" upstream; the connector category enum
+ * does not include `workflow`, so we map it to `other` (same choice the other
+ * AI-text utility adapters make — see avian, afforai, alttextify).
+ */
+declare const hastewireConnector: ConnectorAdapter;
+
+/**
+ * HeyGen connector.
+ *
+ * Authentication: workspace API key delivered via the `X-Api-Key` header. HeyGen
+ * does not publish a third-party OAuth surface, so api-key is the only honest
+ * placement; sending it as Bearer would silently 401 on the v1 endpoints.
+ *
+ * Endpoint surface: the public v1/v2 split is real — template generation and
+ * avatar/voice listing live under v2 while status, listing, translation, asset
+ * upload, and share-link minting live under v1. We declare the path version
+ * inline per capability to keep the wire contract auditable from this file.
+ *
+ * Async generation contract: `videos.createFromTemplate` and `videos.translate`
+ * both return a `video_id` (or `video_translate_id`) immediately; the actual
+ * rendered MP4 is produced by the downstream pipeline. Callers MUST poll the
+ * matching `*.status` capability — there is no synchronous result. The
+ * `cas: 'native-idempotency'` annotation reflects that submitting the same
+ * payload twice creates two render jobs, which is why the orchestrator must
+ * supply an idempotency token; HeyGen itself does not deduplicate.
+ */
+declare const heygenConnector: ConnectorAdapter;
+
+declare const hashiCorpVaultConnector: ConnectorAdapter;
+
+declare const harvestConnector: ConnectorAdapter;
+
+declare const heymarketSmsConnector: ConnectorAdapter;
+
+declare const housecallProConnector: ConnectorAdapter;
+
+declare const influencersClubConnector: ConnectorAdapter;
+
+declare const hunterConnector: ConnectorAdapter;
+
+/**
+ * Hugging Face Inference connector.
+ *
+ * Authentication: a user/workspace access token (`hf_…`) delivered as a
+ * `Bearer` credential in the `Authorization` header. There is no 3-legged
+ * OAuth surface on the inference endpoint.
+ *
+ * Endpoint surface: model-scoped task inference (`/models/{model_id}`) for
+ * the classic serverless Inference API, plus the OpenAI-compatible chat
+ * completions route exposed by the Hugging Face Inference Router. Every
+ * task is a `POST` against the per-model URL with a task-shaped JSON body.
+ *
+ * Mapping to the activepieces catalog actions (verified against
+ * `activepieces-catalog.json` → `id: "hugging-face"`):
+ *   - documentQuestionAnswering → document-question-answering
+ *   - languageTranslation       → translation
+ *   - textClassification        → text-classification
+ *   - textSummarization         → summarization
+ *   - chatCompletion            → router /v1/chat/completions
+ *   - createImage               → text-to-image
+ *   - objectDetection           → object-detection
+ *   - imageClassification       → image-classification
+ *
+ * Inference is non-idempotent (each call samples a fresh output) and has
+ * an external billing effect, so mutation capabilities declare `cas: 'none'`
+ * and `externalEffect: true`. Read-only metadata lookups against the Hub
+ * model registry are exposed as `read` capabilities.
+ */
+declare const huggingFaceConnector: ConnectorAdapter;
+
+declare const insightlyConnector: ConnectorAdapter;
+
+declare const instantlyAiConnector: ConnectorAdapter;
+
+/**
+ * ImageRouter connector.
+ *
+ * ImageRouter is a model-routing API that exposes many third-party image
+ * generation and image-edit models behind a single OpenAI-compatible surface.
+ * Authentication is a workspace API key delivered via the `Authorization:
+ * Bearer` header — the activepieces piece declares `auth: "api_key"`, and the
+ * upstream `/v1/openai/*` endpoints reject non-Bearer placements, so api-key
+ * with bearer placement is the only honest wiring.
+ *
+ * Endpoint surface mirrors the OpenAI Images API: `POST /v1/openai/images/generations`
+ * for text->image (`createImage`) and `POST /v1/openai/images/edits` for
+ * image->image (`imageToImage`). Both return a JSON envelope with a `data[]`
+ * array of `{ url }` or `{ b64_json }` objects depending on `response_format`.
+ *
+ * Mutation semantics: image generation is non-idempotent — re-submitting the
+ * same prompt produces a fresh render and burns credits. We declare
+ * `cas: 'native-idempotency'` so the orchestrator supplies an idempotency
+ * token; ImageRouter itself does not deduplicate. `externalEffect: true`
+ * because successful calls consume billable model credits even when the
+ * caller drops the response.
+ *
+ * The activepieces piece declares only write actions (no triggers, no reads);
+ * we additionally expose `models.list` because it is the canonical
+ * authenticated probe (cheap, no credit consumption) and the agent needs a
+ * concrete model id to populate `createImage.model`.
+ */
+declare const imageRouterConnector: ConnectorAdapter;
+
+declare const jinaAiConnector: ConnectorAdapter;
+
+declare const invoiceninjaConnector: ConnectorAdapter;
+
+declare const jiraDataCenterConnector: ConnectorAdapter;
+
+declare const justInvoiceConnector: ConnectorAdapter;
+
+declare const jiraCloudConnector: ConnectorAdapter;
+
+/**
+ * Jogg AI — AI-generated avatar video and product-content platform.
+ *
+ * Authentication: workspace API key delivered in the `x-api-key` header.
+ *
+ * The v1 surface covers four resource families:
+ *   - avatars / photos        (avatar.photo.create, avatar.video.create)
+ *   - product knowledge       (product.create.from_url, product.create.from_info, product.update)
+ *   - generated-video polling (video.get)
+ *   - media + template-driven video (media.upload, video.create.from_template)
+ *
+ * Video generation is asynchronous: the create.* mutations return a
+ * `video_id`; the caller polls `video.get` until status === completed.
+ * The webhook-style triggers (video.generated.successfully /
+ * video.generation.failed) are catalogued but not modelled here — the
+ * declarative-REST shape only carries request/response capabilities; webhook
+ * delivery is wired in the connector runtime layer.
+ */
+declare const joggAiConnector: ConnectorAdapter;
+
+declare const jotformConnector: ConnectorAdapter;
+
+declare const kizeoFormsConnector: ConnectorAdapter;
+
+declare const kapsoConnector: ConnectorAdapter;
+
+/**
+ * Kimai is a self-hosted time-tracking application. Each tenant runs its
+ * own instance, so the base URL is sourced from connection metadata
+ * (`instanceUrl`, e.g. `https://demo.kimai.org`). API access uses the
+ * legacy `X-AUTH-USER` / `X-AUTH-TOKEN` header pair documented in the
+ * Kimai REST docs at `/api/doc`; the api-key credential carries the
+ * token, and the username is supplied via metadata.
+ */
+declare const kimaiConnector: ConnectorAdapter;
+
+declare const kissflowConnector: ConnectorAdapter;
+
+declare const klentyConnector: ConnectorAdapter;
+
+declare const knackConnector: ConnectorAdapter;
+
+/**
+ * Ko-fi connector.
+ *
+ * Ko-fi is a creator-monetization platform (donations, monthly subscriptions,
+ * commissions, shop orders). The activepieces `ko-fi` piece is a triggers-only
+ * piece — the documented integration surface is webhook delivery:
+ *
+ *   1. Creator pastes a verification token in Ko-fi → More → API.
+ *   2. Ko-fi POSTs a JSON envelope to the configured webhook URL whenever
+ *      a Donation / Subscription / Commission / ShopOrder event occurs.
+ *   3. The receiver verifies `verification_token` matches and dispatches.
+ *
+ * The catalog's auth shape — `api_key` with a single `instructions` field —
+ * encodes that same token. We model it as `api-key` and document the
+ * webhook-setup steps in the auth hint so the user gets actionable guidance
+ * at connect-time.
+ *
+ * Capabilities expose the four trigger event types (`new.donation`,
+ * `new.subscription`, `new.commission`, `new.shop.order`) as `read` operations
+ * against Ko-fi's webhook-event ledger. The ledger URLs follow the
+ * `https://ko-fi.com/api/v1/...` convention documented on the Ko-fi developer
+ * portal; the per-creator base URL is held in `metadata.creatorBaseUrl` so a
+ * caller targeting a specific creator's storefront does not collide with
+ * another tenant's events.
+ *
+ * The verify-webhook mutation acks an inbound webhook payload back to Ko-fi
+ * for replay protection — Ko-fi's verification_token is sent inside the
+ * payload, not as a header, so the connector forwards it through the body.
+ */
+declare const koFiConnector: ConnectorAdapter;
+
+declare const kudosityConnector: ConnectorAdapter;
+
+/**
+ * Leap AI (Workflows) connector.
+ *
+ * Leap AI exposes a hosted workflow runtime — a tenant defines a workflow
+ * in the Leap dashboard (an arbitrary chain of model + tool steps) and
+ * invokes it externally via a workflow ID. The integration surface is
+ * therefore two endpoints: kick off a workflow run with an input object,
+ * and fetch the status / output of a prior run by run ID.
+ *
+ * Auth is a tenant-issued API key delivered as a bearer token. There is
+ * no OAuth surface.
+ *
+ * Consistency: workflows are non-deterministic (LLM- and tool-backed) and
+ * each run carries external billing-class effects. Runs are async — the
+ * caller polls the get-run endpoint until the run reports terminal state.
+ * CAS posture for `run.workflow` is `none` (the caller owns the
+ * idempotency key by supplying / persisting the resulting run ID).
+ */
+declare const leapAiConnector: ConnectorAdapter;
+
+/**
+ * Kommo CRM (https://developers.kommo.com).
+ *
+ * Auth: long-lived access token sent as Bearer in the Authorization header.
+ * Each Kommo account lives on a per-tenant subdomain
+ * (https://{subdomain}.kommo.com), so the connection stores the resolved
+ * `apiBaseUrl` in metadata (e.g. https://acme.kommo.com/api/v4) and the
+ * connector reads it via metadataKey.
+ *
+ * The activepieces catalog entry lists no explicit actions, so the surface
+ * below maps the documented public v4 REST resources used by the piece's
+ * auth-fields (contacts/leads/companies, plus tasks and notes that the
+ * pipeline ops depend on). The `query` / `tags_to_add` / `tags_to_delete` /
+ * `price` auth-fields the catalog enumerates are surfaced as parameters on
+ * the matching search/update capabilities.
+ */
+declare const kommoConnector: ConnectorAdapter;
+
+declare const lemonSqueezyConnector: ConnectorAdapter;
+
+declare const leexiConnector: ConnectorAdapter;
+
+declare const lettaConnector: ConnectorAdapter;
+
+declare const leadConnectorConnector: ConnectorAdapter;
+
+declare const linkupConnector: ConnectorAdapter;
+
+declare const lightfunnelsConnector: ConnectorAdapter;
+
+declare const lemlistConnector: ConnectorAdapter;
+
+declare const letsCalendarConnector: ConnectorAdapter;
+
+declare const linkaConnector: ConnectorAdapter;
+
+declare const localaiConnector: ConnectorAdapter;
+
+/**
+ * LobsterMail adapter — managed inbox + transactional email API at
+ * https://lobstermail.ai. Auth is a bearer API key minted from
+ * Settings → API Keys; the key is forwarded as `Authorization: Bearer <key>`
+ * on every call, which is `declarativeRestConnector`'s default placement.
+ *
+ * Capabilities mirror the activepieces catalog's `lobstermail` entry:
+ * inbox lifecycle (create / get / list / delete), outbound email send,
+ * and inbound email read paths (list / get / search) plus the account
+ * lookup used by the SDK as a credential health check.
+ */
+declare const lobstermailConnector: ConnectorAdapter;
+
+/**
+ * LLM Rails connector.
+ *
+ * LLM Rails is a managed RAG platform: tenants upload documents into
+ * "datastores", LLM Rails ingests + chunks + embeds them, and the
+ * public API exposes a single hybrid (dense + sparse) semantic search
+ * endpoint over a chosen datastore. The only documented external
+ * action in the activepieces catalog is `datastore.search`.
+ *
+ * Auth: tenant API key sent as a bearer token. No OAuth surface.
+ *
+ * Consistency: a search call is a read against the platform's
+ * vector + keyword index. The index itself is eventually consistent
+ * with respect to recent uploads (ingest pipeline runs asynchronously
+ * on LLM Rails' side), so we mark the connector `advisory` rather
+ * than `authoritative` — a search issued moments after an upload may
+ * not yet see the new chunks.
+ */
+declare const llmrailsConnector: ConnectorAdapter;
+
+/**
+ * Magical API connector.
+ *
+ * Magical API (magicalapi.com) is an HR/recruiting data API that wraps two
+ * concerns into one tenant-scoped key:
+ *   1. Resume intelligence — parse a resume PDF/DOC/DOCX into structured
+ *      fields, run a qualitative review against a job description, or
+ *      compute a numeric fit score.
+ *   2. LinkedIn enrichment — fetch profile-by-username and company-by-name
+ *      / username / website snapshots.
+ *
+ * Catalog action surface (Activepieces piece-magical-api 0.1.4):
+ *   - review.resume       -> reviewResume     (write/billed call)
+ *   - parse.resume        -> parseResume      (write/billed call)
+ *   - score.resume        -> scoreResume      (write/billed call)
+ *   - get.profile.data    -> getProfileData   (read enrichment lookup)
+ *   - get.company.data    -> getCompanyData   (read enrichment lookup)
+ * No triggers are declared upstream; this connector exposes the five
+ * actions and nothing else.
+ *
+ * Auth: tenant-issued API key, sent via the `api-key` header on every
+ * request. The vendor does not accept Bearer placement.
+ *
+ * Async / Request-ID pattern: the resume endpoints return a `request_id`
+ * when the upstream model is still working; callers re-POST the same
+ * endpoint with `{ request_id }` to fetch the completed result. The
+ * catalog surfaces `request_id` as a top-level auth-form field for that
+ * retry flow, but this adapter models it as a per-call parameter so the
+ * runtime can drive both the initial submit and the retry through the
+ * same capability without re-binding credentials.
+ *
+ * Consistency:
+ *   - parse/review/score are LLM-backed, non-deterministic, billed on
+ *     every accepted submit, and the vendor issues the request_id
+ *     server-side. CAS = `none`, externalEffect = true so dry-run policy
+ *     treats them as side-effecting.
+ *   - profile/company reads are advisory enrichment snapshots — the
+ *     underlying LinkedIn data may change between calls.
+ */
+declare const magicalApiConnector: ConnectorAdapter;
+
+declare const lokaliseConnector: ConnectorAdapter;
+
+/**
+ * LogRocket (https://logrocket.com) is a session-replay + product-analytics
+ * platform whose AI Highlights API surfaces summaries of user sessions. The
+ * public REST surface is rooted at `/v1` and authenticated with a personal
+ * API key presented as `Authorization: Bearer <key>` — the same shape the
+ * Activepieces piece-logrocket connector uses.
+ *
+ * The Activepieces piece exposes two actions and one webhook trigger:
+ *   - requestHighlights  → highlights.request   (mutation; async, results
+ *                                                 are delivered to a webhook
+ *                                                 URL the caller controls)
+ *   - identifyUser       → users.identify       (mutation; user-trait upsert)
+ *   - highlightsReady    → highlights.ready     (webhook; modelled as a
+ *                                                 read of the latest request
+ *                                                 so callers without an
+ *                                                 inbound webhook can poll)
+ *
+ * The `users.identify` trait write is an unconditional upsert keyed on
+ * `userId`, so it tolerates idempotent replay natively. The highlights
+ * request returns a server-assigned `requestId` and accepts an
+ * `idempotencyKey` we forward through the declarative-REST adapter — also
+ * native-idempotency.
+ */
+declare const logrocketConnector: ConnectorAdapter;
+
+/**
+ * LogSnag — project event tracking and lightweight product analytics.
+ *
+ * The activepieces catalog only declares the `createEvent` action; LogSnag's
+ * public HTTP API (https://docs.logsnag.com/api-reference) is small and fully
+ * shaped around `project` + `channel` keys, so the surface below is the real
+ * set of endpoints a caller can reach with a single API token: `log` (event),
+ * `identify` (user trait), `group` (group trait), `insight` (numeric metric),
+ * and `insight/mutate` (atomic counter update).
+ *
+ * Auth: a single bearer API token, scoped to a LogSnag project. The catalog
+ * marks `project` / `channel` / `event` as required text fields — those flow
+ * through as capability parameters rather than connector-construction config
+ * so a single connection can target multiple channels in the same project.
+ */
+declare const logsnagConnector: ConnectorAdapter;
+
+declare const loftyConnector: ConnectorAdapter;
+
+/**
+ * Lusha — B2B contact and company data enrichment.
+ *
+ * Auth: API key sent in the `api_key` header.
+ * Base: https://api.lusha.com
+ *
+ * Capabilities mirror the activepieces piece (search.companies,
+ * enrich.companies) plus their natural read counterparts that the
+ * upstream API exposes.
+ */
+declare const lushaConnector: ConnectorAdapter;
+
+declare const mailerLiteConnector: ConnectorAdapter;
+
+/**
+ * Luxury Presence connector.
+ *
+ * Luxury Presence is a CRM + website + marketing platform for real-estate
+ * agents and brokerages. The integration surface that LP exposes to outside
+ * automation tools is its Lead Connect REST API: an api-key-authenticated
+ * endpoint family that lets a third-party system push prospective buyer /
+ * seller leads into the agent's LP CRM and read back the resulting lead
+ * records for state reconciliation.
+ *
+ * The upstream activepieces catalog entry for luxury-presence documents
+ * only a webhook trigger (`new.lead`) and no actions, because that piece
+ * is webhook-receiver-only. We model the side of the integration that the
+ * orchestrator needs in order to actually do CRM work: write a lead into
+ * LP and read leads back out.
+ *
+ * Auth is a per-tenant API key issued in the LP admin console and sent in
+ * the `X-API-Key` header (LP rejects Bearer placement for this surface).
+ */
+declare const luxuryPresenceConnector: ConnectorAdapter;
+
+/**
+ * Lucidya adapter — AI-powered social media analytics and customer experience
+ * management. The activepieces catalog entry for `lucidya` ships with no
+ * actions or triggers (the package only exposes auth wiring), so the
+ * capability surface below maps the documented public Lucidya REST API at
+ * https://api.lucidya.com.
+ *
+ * Auth: API key carried as an HTTP Bearer token on every request. The catalog
+ * names the credential field `md` (the customer-facing "Measurement Domain"
+ * key); the adapter forwards the same token as `Authorization: Bearer <md>`.
+ *
+ * Category: `crm` (matches the catalog entry; customer-experience tooling).
+ */
+declare const lucidyaConnector: ConnectorAdapter;
+
+/**
+ * Mastodon adapter.
+ *
+ * Mastodon is federated: every instance (mastodon.social, fosstodon.org, a
+ * private server, ...) exposes the same REST surface under its own host. The
+ * activepieces piece captures this with a `base_url` field plus a long-lived
+ * `access_token` issued by that instance. We model the per-tenant host as
+ * `baseUrl: { metadataKey: 'baseUrl' }` so each connection resolves to the
+ * instance the user authorized against, and the access token rides as a
+ * bearer credential (the default api-key placement) on every call.
+ *
+ * The piece itself ships exactly one action — `postStatus` — which maps to
+ * the public `POST /api/v1/statuses` endpoint. We also surface the read
+ * paths the same credential unlocks (verify-credentials for connection
+ * health, fetch-status for permalink resolution, home/account timelines for
+ * polling-based triggers) so downstream tooling can compose richer flows
+ * without each consumer hand-rolling Mastodon HTTP.
+ */
+declare const mastodonConnector: ConnectorAdapter;
+
+declare const matomoConnector: ConnectorAdapter;
+
+declare const manychatConnector: ConnectorAdapter;
+
+/**
+ * Mailgun adapter — REST API at https://api.mailgun.net/v3 (US region) or
+ * https://api.eu.mailgun.net/v3 (EU region).
+ *
+ * Auth: HTTP Basic with username `api` and the private API key as the password.
+ * The credential token must be supplied pre-base64-encoded as `api:<KEY>` so the
+ * declarative REST runtime can drop it into `Authorization: Basic <token>`
+ * without per-request transformation. The catalog's `region` field selects the
+ * base URL; default is the US endpoint, override via source metadata.baseUrl.
+ *
+ * Action set mirrors the activepieces `mailgun` piece: transactional send,
+ * email validation, mailing-list membership, event/stat reads, and the bounces
+ * suppression list. Domain templating uses the catalog `from` address's domain
+ * for `/{domain}/messages`-style routes; callers pass the domain explicitly so
+ * the same credential can drive multiple sending domains.
+ */
+declare const mailgunConnector: ConnectorAdapter;
+
+declare const matrixConnector: ConnectorAdapter;
+
+/**
+ * Mattermost — open-source team messaging.
+ *
+ * Auth model from the activepieces catalog: api-key (bot token) plus a
+ * caller-supplied workspace URL. The workspace URL is the customer's
+ * Mattermost instance origin (e.g. `https://activepieces.mattermost.com`);
+ * REST paths hang off `/api/v4` per the Mattermost server API.
+ *
+ * The catalog only ships one action (`send.message`, upstream `sendMessage`),
+ * which maps to `POST /api/v4/posts`. We expose only that capability here so
+ * the manifest reflects the catalog exactly.
+ */
+declare const mattermostConnector: ConnectorAdapter;
+
+declare const mailerooConnector: ConnectorAdapter;
+
+declare const meetgeekAiConnector: ConnectorAdapter;
+
+declare const messagebirdConnector: ConnectorAdapter;
+
+declare const mauticConnector: ConnectorAdapter;
+
+/**
+ * Microsoft 365 People connector backed by Microsoft Graph v1.0.
+ *
+ * Manages personal contacts and contact folders in the signed-in user's
+ * Outlook/Exchange Online mailbox. Authentication uses the Microsoft identity
+ * platform v2.0 OAuth endpoints; the `common` tenant lets one app registration
+ * serve any work, school, or personal account.
+ *
+ * Docs:
+ *   - https://learn.microsoft.com/graph/api/resources/contact?view=graph-rest-1.0
+ *   - https://learn.microsoft.com/graph/api/resources/contactfolder?view=graph-rest-1.0
+ *   - https://learn.microsoft.com/graph/permissions-reference#contacts-permissions
+ */
+declare const microsoft365PeopleConnector: ConnectorAdapter;
+
+declare const memConnector: ConnectorAdapter;
+
+/**
+ * Microsoft Dynamics 365 / Dataverse Web API connector.
+ *
+ * Auth: OAuth2 against the Microsoft identity platform. The token audience is
+ * the organization URL itself (e.g. `https://contoso.crm.dynamics.com/.default`),
+ * so the per-tenant Dataverse origin is supplied through `instanceUrl` connection
+ * metadata rather than baked into baseUrl. The same connector therefore serves
+ * every Dataverse region (crm, crm2..crm9, crm.dynamics.cn, crm.microsoftdynamics.us).
+ *
+ * Capability surface mirrors the activepieces piece (create / get / update /
+ * delete record) but binds them to the Dataverse Web API v9.2 entity-set
+ * conventions: pluralized logical names, GUID record ids, and the
+ * If-Match: * idempotency header for upserts.
+ *
+ * Docs:
+ *   - https://learn.microsoft.com/power-apps/developer/data-platform/webapi/overview
+ *   - https://learn.microsoft.com/power-apps/developer/data-platform/webapi/perform-operations-web-api
+ *   - https://learn.microsoft.com/power-apps/developer/data-platform/authenticate-oauth
+ */
+declare const microsoftDynamicsCrmConnector: ConnectorAdapter;
+
+declare const microsoftDynamics365BusinessCentralConnector: ConnectorAdapter;
+
+/**
+ * Microsoft 365 Planner connector backed by Microsoft Graph v1.0.
+ *
+ * Auth: OAuth2 against the Entra ID v2.0 endpoint. Uses the `common` tenant so the
+ * same app registration works for multi-tenant deployments; single-tenant operators
+ * override authorizationUrl/tokenUrl with their own tenant id at construction time.
+ *
+ * Planner write operations (update + delete) require optimistic concurrency via the
+ * `If-Match` header carrying the resource `@odata.etag`. The declarative-REST runtime
+ * surfaces `cas: 'optimistic-read-verify'` and `cas: 'etag-if-match'` for callers that
+ * need to thread the etag through; the etag itself is read from the prior GET.
+ *
+ * Docs:
+ *   - https://learn.microsoft.com/graph/api/resources/planner-overview
+ *   - https://learn.microsoft.com/graph/api/resources/plannertask
+ *   - https://learn.microsoft.com/graph/api/resources/plannerbucket
+ *   - https://learn.microsoft.com/graph/api/resources/plannerplan
+ */
+declare const microsoft365PlannerConnector: ConnectorAdapter;
+
+/**
+ * Microsoft Power BI connector backed by the Power BI REST API v1.0.
+ *
+ * Auth: OAuth2 against the Entra ID v2.0 endpoint. The `common` tenant lets a
+ * single app registration work for multi-tenant deployments; single-tenant
+ * operators override authorizationUrl/tokenUrl with their tenant id at
+ * construction time.
+ *
+ * Power BI dataset writes are not natively idempotent — pushRows is append-only
+ * and createDataset rejects duplicate names within a workspace — so callers must
+ * gate replay at the orchestration layer (idempotency key + workspace-scoped
+ * name uniqueness check) rather than rely on the API.
+ *
+ * Docs:
+ *   - https://learn.microsoft.com/rest/api/power-bi/datasets/post-dataset
+ *   - https://learn.microsoft.com/rest/api/power-bi/push-datasets/datasets-post-rows
+ */
+declare const microsoftPowerBiConnector: ConnectorAdapter;
+
+/**
+ * Microsoft Outlook Calendar connector backed by Microsoft Graph v1.0.
+ *
+ * Manages events on the signed-in user's primary calendar (and any explicit
+ * calendarId the caller supplies). Authentication uses the Microsoft identity
+ * platform v2.0 OAuth endpoints; the `common` tenant lets a single app
+ * registration serve any work, school, or personal account.
+ *
+ * Docs:
+ *   - https://learn.microsoft.com/graph/api/resources/event?view=graph-rest-1.0
+ *   - https://learn.microsoft.com/graph/api/user-list-events?view=graph-rest-1.0
+ *   - https://learn.microsoft.com/graph/permissions-reference#calendars-permissions
+ */
+declare const microsoftOutlookCalendarConnector: ConnectorAdapter;
+
+/**
+ * Microsoft OneNote connector via the Microsoft Graph v1.0 OneNote API.
+ *
+ * Auth: OAuth2 against the Microsoft identity platform. We request the
+ * delegated Notes scopes that cover read + write of the user's notebooks,
+ * sections, and pages, plus offline_access for refresh.
+ *
+ * Capability surface mirrors the activepieces piece actions:
+ *   - createNotebook        → notebooks.create
+ *   - createSection         → sections.create
+ *   - createPage            → pages.create        (HTML body)
+ *   - createNoteInSection   → pages.createInSection (typed alias of pages.create
+ *                             that pins the parent sectionId)
+ *   - createImageNote       → pages.createImage   (multipart not modeled here;
+ *                             accepts an HTML page body referencing image data;
+ *                             callers supply Graph-compatible HTML)
+ *   - appendNote            → pages.append        (PATCH a page with revisions)
+ *
+ * We also expose read helpers (list notebooks/sections/pages, get page content)
+ * so an agent can navigate the hierarchy before mutating.
+ *
+ * Page mutations use 'native-idempotency' because Graph generates the page id
+ * server-side on POST and accepts a client-request-id header for de-duplication;
+ * page append is 'optimistic-read-verify' since PATCH targets a known page and
+ * Graph has no etag for the OneNote subset.
+ *
+ * Docs:
+ *   - https://learn.microsoft.com/graph/api/resources/onenote-api-overview
+ *   - https://learn.microsoft.com/graph/api/onenote-list-notebooks
+ *   - https://learn.microsoft.com/graph/api/notebook-post-sections
+ *   - https://learn.microsoft.com/graph/api/section-post-pages
+ *   - https://learn.microsoft.com/graph/api/page-update
+ */
+declare const microsoftOnenoteConnector: ConnectorAdapter;
+
+/**
+ * Microsoft Outlook connector backed by Microsoft Graph v1.0 /me/messages.
+ *
+ * Drives the signed-in user's Outlook/Exchange Online mailbox: send mail,
+ * drafts, replies, forwards, attachment download, label (category) tagging,
+ * folder moves, and search. Authentication uses the Microsoft identity
+ * platform v2.0 OAuth endpoints against the `common` tenant so one app
+ * registration can serve work, school, or personal accounts.
+ *
+ * Docs:
+ *   - https://learn.microsoft.com/graph/api/resources/message?view=graph-rest-1.0
+ *   - https://learn.microsoft.com/graph/api/user-sendmail?view=graph-rest-1.0
+ *   - https://learn.microsoft.com/graph/api/message-reply?view=graph-rest-1.0
+ *   - https://learn.microsoft.com/graph/api/message-forward?view=graph-rest-1.0
+ *   - https://learn.microsoft.com/graph/api/message-move?view=graph-rest-1.0
+ *   - https://learn.microsoft.com/graph/api/attachment-get?view=graph-rest-1.0
+ *   - https://learn.microsoft.com/graph/permissions-reference#mail-permissions
+ */
+declare const microsoftOutlookConnector: ConnectorAdapter;
+
+/**
+ * Microsoft Excel 365 connector backed by Microsoft Graph v1.0 Excel APIs.
+ *
+ * Operates on workbooks stored in the signed-in user's OneDrive for Business
+ * / SharePoint mailbox. The Graph Excel surface addresses workbooks via drive
+ * item id, then exposes named worksheet, table, row, column, and range
+ * sub-resources. Authentication uses the Microsoft identity platform v2.0
+ * endpoints; the `common` tenant lets a single app registration serve work,
+ * school, and personal accounts.
+ *
+ * Docs:
+ *   - https://learn.microsoft.com/graph/api/resources/excel
+ *   - https://learn.microsoft.com/graph/api/resources/workbook
+ *   - https://learn.microsoft.com/graph/api/resources/worksheet
+ *   - https://learn.microsoft.com/graph/api/resources/table
+ *   - https://learn.microsoft.com/graph/permissions-reference#files-permissions
+ */
+declare const microsoftExcel365Connector: ConnectorAdapter;
+
+/**
+ * Microsoft To Do connector via the Microsoft Graph v1.0 todo API.
+ *
+ * Auth: OAuth2 against the Microsoft identity platform. We request the
+ * delegated Tasks scopes that cover read + write of the user's task lists
+ * and tasks, plus offline_access for refresh.
+ *
+ * Capability surface mirrors the activepieces piece actions:
+ *   - addAttachmentAction        → tasks.addAttachment
+ *   - completeTaskAction         → tasks.complete       (PATCH status=completed)
+ *   - createTask                 → tasks.create
+ *   - createTaskListAction       → taskLists.create
+ *   - deleteTaskAction           → tasks.delete
+ *   - findTaskByTitleAction      → tasks.findByTitle    ($filter on title eq)
+ *   - findTaskListByNameAction   → taskLists.findByName ($filter on displayName eq)
+ *   - getTaskAction              → tasks.get
+ *   - updateTaskAction           → tasks.update
+ *   - updateTaskListAction       → taskLists.update
+ *   - listTasksAction            → tasks.list
+ *   - listTaskListsAction        → taskLists.list
+ *
+ * Graph models the resource tree as:
+ *   /me/todo/lists                      → todoTaskList
+ *   /me/todo/lists/{listId}/tasks       → todoTask
+ *   /me/todo/lists/{listId}/tasks/{id}/attachments → taskFileAttachment
+ *
+ * Mutations of resources Graph generates server-side (create list, create task,
+ * create attachment) are 'native-idempotency'. Mutations targeting an existing
+ * resource (PATCH list, PATCH task, complete task, DELETE task) are
+ * 'optimistic-read-verify' — Graph does not expose ETags on To Do entities,
+ * so callers must read-then-write if they need to detect concurrent edits.
+ *
+ * Docs:
+ *   - https://learn.microsoft.com/graph/api/resources/todo-overview
+ *   - https://learn.microsoft.com/graph/api/todo-list-lists
+ *   - https://learn.microsoft.com/graph/api/todotasklist-post-tasks
+ *   - https://learn.microsoft.com/graph/api/todotask-update
+ *   - https://learn.microsoft.com/graph/api/todotask-post-attachments
+ */
+declare const microsoftTodoConnector: ConnectorAdapter;
+
+/**
+ * Microsoft SharePoint connector backed by Microsoft Graph v1.0.
+ *
+ * Sites, drives, list items, files, and pages are surfaced through
+ * `https://graph.microsoft.com/v1.0/sites/...`. OAuth2 against the v2.0
+ * Microsoft identity platform endpoint uses the multi-tenant `common`
+ * authority by default; single-tenant deployments override
+ * authorizationUrl/tokenUrl with their own tenant id.
+ *
+ * Docs:
+ *   - https://learn.microsoft.com/graph/api/resources/sharepoint
+ *   - https://learn.microsoft.com/graph/api/resources/driveitem
+ *   - https://learn.microsoft.com/graph/api/resources/listitem
+ *   - https://learn.microsoft.com/entra/identity-platform/v2-oauth2-auth-code-flow
+ *
+ * Mapped activepieces piece: microsoft-sharepoint (storage / oauth2).
+ */
+declare const microsoftSharepointConnector: ConnectorAdapter;
+
+/**
+ * MillionVerifier adapter — email verification REST API.
+ *
+ * Upstream: https://api.millionverifier.com/api/v3
+ * Auth: API key. MillionVerifier forwards the credential as the `api` query
+ * parameter on every verification call; there is no Authorization header.
+ *
+ * Catalog (`millionverifier`) declares a single action `verifyEmail`. The
+ * catalog's `authFields` block is misleading — `email` and `timeout` are
+ * per-call inputs, not credentials; they are modeled as capability parameters
+ * here. The credential itself is the bare API key.
+ */
+declare const millionverifierConnector: ConnectorAdapter;
+
+declare const mindeeConnector: ConnectorAdapter;
+
+declare const mixmaxConnector: ConnectorAdapter;
+
+declare const mixpanelConnector: ConnectorAdapter;
+
+declare const missiveConnector: ConnectorAdapter;
+
+declare const exaConnector: ConnectorAdapter;
+
+declare const googleVertexaiConnector: ConnectorAdapter;
+
+declare const glideConnector: ConnectorAdapter;
+
+declare const gotifyConnector: ConnectorAdapter;
+
+declare const gptzeroDetectAiConnector: ConnectorAdapter;
+
+declare const gristConnector: ConnectorAdapter;
+
+declare const granolaConnector: ConnectorAdapter;
+
+declare const griptapeConnector: ConnectorAdapter;
+
+declare const heartbeatConnector: ConnectorAdapter;
+
+/**
+ * Hedy AI-powered meeting intelligence connector.
+ *
+ * Authentication: API key delivered in the `Authorization: Bearer` header.
+ * Region selection (US vs EU) is configurable at credential time.
+ *
+ * Capability surface covers meeting session management and topic creation:
+ *   - topics: create, read, update, list
+ *   - sessions: get details, list by topic
+ *   - context: create and manage session context for AI analysis
+ */
+declare const hedyConnector: ConnectorAdapter;
+
+declare const humeAiConnector: ConnectorAdapter;
+
+declare const hystructConnector: ConnectorAdapter;
+
+declare const ibmCognoseConnector: ConnectorAdapter;
+
+declare const imapConnector: ConnectorAdapter;
+
+declare const instaChartsConnector: ConnectorAdapter;
+
+declare const insightoAiConnector: ConnectorAdapter;
+
+declare const instasentConnector: ConnectorAdapter;
+
+declare const kallabotAiConnector: ConnectorAdapter;
+
+declare const knockConnector: ConnectorAdapter;
+
+declare const loopsConnector: ConnectorAdapter;
+
+declare const mailchainConnector: ConnectorAdapter;
+
+declare const medullarConnector: ConnectorAdapter;
+
+declare const mollieConnector: ConnectorAdapter;
+
+declare const metabaseConnector: ConnectorAdapter;
+
+declare const mindStudioConnector: ConnectorAdapter;
+
+declare const microsoftOnedriveConnector: ConnectorAdapter;
+
+/**
+ * MongoDB adapter.
+ *
+ * Surfaces MongoDB document operations via the MongoDB Data API
+ * (https://www.mongodb.com/docs/atlas/api/data-api/).
+ *
+ * Requires MongoDB Atlas and Data API enabled. Connection is via
+ * API key authentication with host, database, and optional auth
+ * credentials configured.
+ *
+ * Operations include:
+ * - documents.find: Query documents with optional filters, projections, sort, limit, skip
+ * - documents.findOne: Find a single document matching a filter
+ * - documents.insertOne: Insert a single document into a collection
+ * - documents.insertMany: Insert multiple documents
+ * - documents.updateOne: Update a single document matching a filter
+ * - documents.updateMany: Update multiple documents matching a filter
+ * - documents.replaceOne: Replace a single document entirely
+ * - documents.deleteOne: Delete a single document matching a filter
+ * - documents.deleteMany: Delete multiple documents matching a filter
+ * - documents.aggregate: Run an aggregation pipeline over a collection
+ */
+declare const mongodbConnector: ConnectorAdapter;
+
+declare const niftyConnector: ConnectorAdapter;
+
+declare const ninjapipeConnector: ConnectorAdapter;
+
+declare const nocodbConnector: ConnectorAdapter;
+
+declare const notionConnector: ConnectorAdapter;
+
+declare const ntfyConnector: ConnectorAdapter;
+
+declare const odooConnector: ConnectorAdapter;
+
+declare const omniCoConnector: ConnectorAdapter;
+
+declare const omnihrConnector: ConnectorAdapter;
+
+declare const openRouterConnector: ConnectorAdapter;
+
+declare const openPhoneConnector: ConnectorAdapter;
+
+declare const opportifyConnector: ConnectorAdapter;
+
+declare const openmicAiConnector: ConnectorAdapter;
+
+declare const opnformConnector: ConnectorAdapter;
+
+declare const orimonConnector: ConnectorAdapter;
+
+/**
+ * Oracle Database adapter.
+ *
+ * Surfaces Oracle Database operations via SQL/PL-SQL execution,
+ * supporting row-level CRUD operations and custom SQL queries.
+ *
+ * Connection supports both direct (host, port, service name) and
+ * connection string configurations. Authentication via username/password.
+ * Optional thick mode for legacy Oracle versions (10g, 11g).
+ *
+ * Operations include:
+ * - rows.find: Query rows with optional WHERE conditions
+ * - rows.insert: Insert a single row
+ * - rows.insertBatch: Insert multiple rows
+ * - rows.update: Update rows matching filter conditions
+ * - rows.delete: Delete rows matching filter conditions
+ * - sql.execute: Run custom SQL or PL/SQL with bind parameters
+ */
+declare const oracleDatabaseConnector: ConnectorAdapter;
+
+declare const paddleConnector: ConnectorAdapter;
+
+declare const paperformConnector: ConnectorAdapter;
+
+declare const pastefyConnector: ConnectorAdapter;
+
+declare const pinchPaymentsConnector: ConnectorAdapter;
+
+declare const paywhirlConnector: ConnectorAdapter;
+
+declare const parseurConnector: ConnectorAdapter;
+
+declare const pdfmonkeyConnector: ConnectorAdapter;
+
+declare const peekshotConnector: ConnectorAdapter;
+
+declare const perplexityAiConnector: ConnectorAdapter;
+
+declare const personalAiConnector: ConnectorAdapter;
+
+declare const placidConnector: ConnectorAdapter;
+
+declare const plausibleConnector: ConnectorAdapter;
+
+declare const pocketbaseConnector: ConnectorAdapter;
+
+declare const pollybotAiConnector: ConnectorAdapter;
+
+declare const postgresConnector: ConnectorAdapter;
+
+declare const postizConnector: ConnectorAdapter;
+
+declare const posthogConnector: ConnectorAdapter;
+
+declare const predictLeadsConnector: ConnectorAdapter;
+
+declare const productboardConnector: ConnectorAdapter;
+
+declare const proxycurlConnector: ConnectorAdapter;
+
+declare const pushbulletConnector: ConnectorAdapter;
+
+/**
+ * Pushover connector.
+ *
+ * Pushover is a push-notification service that delivers real-time alerts to
+ * mobile devices and desktops. The external integration surface exposes the
+ * send-notification endpoint, which requires an API token (application key)
+ * and user key to deliver messages to user devices.
+ *
+ * Auth is via two API keys: the application/API token and the user key.
+ * These are delivered as form-encoded parameters on every request.
+ *
+ * Consistency: notifications are fire-and-forget (write-only, non-deterministic
+ * delivery due to network/device state). CAS posture is `none` — the caller owns
+ * idempotency if needed — and `externalEffect: true` so the orchestrator's
+ * dry-run policy treats this as a side-effecting call.
+ */
+declare const pushoverConnector: ConnectorAdapter;
+
+declare const qawafelConnector: ConnectorAdapter;
+
+declare const quadernoConnector: ConnectorAdapter;
+
+declare const raiaAiConnector: ConnectorAdapter;
+
+declare const rapidtextAiConnector: ConnectorAdapter;
+
+declare const recallAiConnector: ConnectorAdapter;
+
+declare const reachinboxConnector: ConnectorAdapter;
+
+/**
+ * Reddit adapter.
+ *
+ * Provides access to Reddit's JSON API (api.reddit.com) for reading posts,
+ * comments, and creating content across subreddits. OAuth2 flows use
+ * access_token (required) and refresh_token (optional) for long-lived sessions.
+ *
+ * The piece surfaces the core actions from activepieces:
+ * - retrieve/get post details
+ * - create post/comment
+ * - edit post/comment
+ * - delete post/comment
+ * - fetch comments on a post
+ *
+ * All requests must include the User-Agent header per Reddit API requirements.
+ */
+declare const redditConnector: ConnectorAdapter;
+
+declare const reoonVerifierConnector: ConnectorAdapter;
+
+declare const replyIoConnector: ConnectorAdapter;
+
+declare const retableConnector: ConnectorAdapter;
+
+declare const retellAiConnector: ConnectorAdapter;
+
+declare const robollyConnector: ConnectorAdapter;
+
+declare const runwareConnector: ConnectorAdapter;
+
+declare const saasticConnector: ConnectorAdapter;
+
+declare const saleorConnector: ConnectorAdapter;
+
+declare const sardisConnector: ConnectorAdapter;
+
+declare const scrapegraphaiConnector: ConnectorAdapter;
+
+declare const scrapelessConnector: ConnectorAdapter;
+
+declare const seekTableConnector: ConnectorAdapter;
+
+declare const skyprepConnector: ConnectorAdapter;
+
+declare const sendinblueConnector: ConnectorAdapter;
+
+declare const senjaConnector: ConnectorAdapter;
+
+declare const serpstatConnector: ConnectorAdapter;
+
+declare const serviceNowConnector: ConnectorAdapter;
+
+declare const signNowConnector: ConnectorAdapter;
+
+declare const signrequestConnector: ConnectorAdapter;
+
+declare const shortIoConnector: ConnectorAdapter;
+
+declare const shippoConnector: ConnectorAdapter;
+
+declare const simplirouteConnector: ConnectorAdapter;
+
+declare const simplybookmeConnector: ConnectorAdapter;
+
+declare const smartleadConnector: ConnectorAdapter;
+
+declare const smartsheetConnector: ConnectorAdapter;
+
+declare const smartsuiteConnector: ConnectorAdapter;
+
+declare const smsmodeConnector: ConnectorAdapter;
+
+declare const snowflakeConnector: ConnectorAdapter;
+
+declare const socialkitConnector: ConnectorAdapter;
+
+declare const squareConnector: ConnectorAdapter;
+
+declare const supadataConnector: ConnectorAdapter;
+
+declare const swarmnodeConnector: ConnectorAdapter;
+
+declare const stripeConnector: ConnectorAdapter;
+
+declare const systemeIoConnector: ConnectorAdapter;
+
+declare const tableauConnector: ConnectorAdapter;
+
+declare const talkableConnector: ConnectorAdapter;
+
+/**
+ * Tally — form builder and submission receiver.
+ *
+ * Tally's primary use case is as a webhook receiver for form submissions
+ * (ActivePieces catalogues it as webhook-only). This adapter exposes the
+ * REST API for querying forms and retrieving submission history, scoped to
+ * read operations. The webhook integration flow remains outside this connector
+ * (agent agents receive submissions via the hub's inbound webhook dispatcher).
+ *
+ * Auth: API key placed in the `Authorization: Bearer <apiKey>` header.
+ *
+ * Tally API refs:
+ *   - GET https://api.tally.so/form/{formId} — fetch form metadata
+ *   - GET https://api.tally.so/form/{formId}/response — list responses
+ *
+ * TODO: expand to pagination and per-response filters if the agent needs them.
+ */
+declare const tallyConnector: ConnectorAdapter;
+
+declare const ticktickConnector: ConnectorAdapter;
+
+declare const teableConnector: ConnectorAdapter;
+
+declare const telnyxConnector: ConnectorAdapter;
+
+declare const tenzoConnector: ConnectorAdapter;
+
+declare const textcortexAiConnector: ConnectorAdapter;
+
+declare const timeOpsConnector: ConnectorAdapter;
+
+declare const timelinesAiConnector: ConnectorAdapter;
+
+declare const tlDvConnector: ConnectorAdapter;
+
+declare const todoistConnector: ConnectorAdapter;
+
+declare const togglTrackConnector: ConnectorAdapter;
+
+declare const totalcmsConnector: ConnectorAdapter;
+
+declare const typefullyConnector: ConnectorAdapter;
+
+declare const twinLabsConnector: ConnectorAdapter;
+
+declare const twitterConnector: ConnectorAdapter;
+
+declare const twilioConnector: ConnectorAdapter;
+
+declare const upgradechatConnector: ConnectorAdapter;
+
+declare const vapiConnector: ConnectorAdapter;
+
+declare const validatedmailsConnector: ConnectorAdapter;
+
+declare const umamiConnector: ConnectorAdapter;
+
+declare const uscreenConnector: ConnectorAdapter;
+
+declare const vboutConnector: ConnectorAdapter;
+
+declare const vidlab7Connector: ConnectorAdapter;
+
+declare const videoaskConnector: ConnectorAdapter;
+
+declare const vlmRunConnector: ConnectorAdapter;
+
+declare const voucheryIoConnector: ConnectorAdapter;
+
+declare const vtexConnector: ConnectorAdapter;
+
+declare const vtigerConnector: ConnectorAdapter;
+
+declare const wafeqConnector: ConnectorAdapter;
+
+declare const whatConvertsConnector: ConnectorAdapter;
+
+declare const webscrapingAiConnector: ConnectorAdapter;
+
+declare const whatsappConnector: ConnectorAdapter;
+
+declare const whatsscaleConnector: ConnectorAdapter;
+
+declare const wonderchatConnector: ConnectorAdapter;
+
+declare const woodpeckerConnector: ConnectorAdapter;
+
+declare const wootricConnector: ConnectorAdapter;
+
+declare const woocommerceConnector: ConnectorAdapter;
+
+declare const workableConnector: ConnectorAdapter;
+
+declare const writesonicBulkConnector: ConnectorAdapter;
+
+declare const wufooConnector: ConnectorAdapter;
+
+declare const wrikeConnector: ConnectorAdapter;
+
+declare const youcanbookmeConnector: ConnectorAdapter;
+
+/**
+ * ZeroBounce adapter — email validation REST API at https://api.zerobounce.net.
+ *
+ * Auth: API token (key) from the ZeroBounce dashboard, sent as a query parameter
+ * `api_key` on requests.
+ *
+ * The activepieces catalog ships a single action — `validate.email` — backed
+ * by `GET /v2/validate`, which validates a single email address and returns
+ * deliverability status, bounce type, and other metadata. We classify it as a
+ * mutation because each call consumes API credits; CAS is `native-idempotency`
+ * since repeat lookups return cached results within the default cache window.
+ */
+declare const zerobounceConnector: ConnectorAdapter;
+
+declare const zeplinConnector: ConnectorAdapter;
+
+/**
+ * Zuora subscription management connector — core financial operations.
+ * Supports finding accounts, products, rate plans, and invoice creation.
+ * Uses OAuth2 with token-based authentication.
+ */
+declare const zuoraConnector: ConnectorAdapter;
+
+declare const zapierConnector: ConnectorAdapter;
+
+declare const n8nConnector: ConnectorAdapter;
+
+declare const makeConnector: ConnectorAdapter;
+
+declare const pipedreamConnector: ConnectorAdapter;
+
+export { type DocuSealOptions, type EtsyOptions, type GmailOptions, type GoogleCalendarOptions, type GoogleDocsOptions, type GoogleDriveOptions, type GoogleFormsOptions, type GoogleSheetsOptions, type HelloSignOptions, type HubSpotOptions, type MicrosoftCalendarOptions, type MicrosoftGraphOptions, type MicrosoftTeamsOptions, type NotionDatabaseOptions, type OneDriveOptions, type OutlookMailOptions, type PandaDocOptions, type RestConnectorSpec, type RestCredentialPlacement, type RestOperationSpec, type RestRequestSpec, type SharePointOptions, type SlackOptions, TELEGRAM_FILE_DOWNLOAD_ROOT, type WhatsappBusinessOptions, activecampaignConnector, acumbamailConnector, adobeCreativeCloudConnector, afforaiConnector, agentxConnector, aidbaseConnector, aipriseConnector, airOpsConnector, aircallConnector, airtableConnector, airtopConnector, alaiConnector, altTextAiConnector, alttextifyConnector, amazonBedrockConnector, amazonSecretsManagerConnector, amazonSesConnector, amazonSnsConnector, amazonSqsConnector, amazonTextractConnector, aminosConnector, ampecoConnector, anthropicConnector, apitableConnector, apitemplateIoConnector, apolloConnector, appfollowConnector, asanaConnector, ashbyConnector, asknewsConnector, assemblyaiConnector, attioConnector, auth0Connector, autocallsConnector, avianConnector, avomaConnector, azureAdConnector, azureCommunicationServicesConnector, azureOpenaiConnector, backblazeConnector, bamboohrConnector, barcodeLookupConnector, baremetricsConnector, basecampConnector, beamerConnector, bettermodeConnector, bexioConnector, bigcommerceConnector, biginByZohoConnector, billplzConnector, bitlyConnector, blandAiConnector, blueskyConnector, bolnaConnector, bonjoroConnector, bookedinConnector, boxConnector, braveSearchConnector, brazeConnector, brilliantDirectoriesConnector, browseAiConnector, calComConnector, calendlyConnector, campaignMonitorConnector, cannyConnector, canvaConnector, capsuleCrmConnector, captainDataConnector, cashfreePaymentsConnector, certopusConnector, chainalysisApiConnector, chargebeeConnector, chargekeepConnector, chartlyConnector, chatDataConnector, chatbaseConnector, chatlingConnector, chatnodeConnector, chatwootConnector, checkoutConnector, circleConnector, clearoutConnector, clicdataConnector, clickupConnector, clioConnector, clockifyConnector, clockodoConnector, closeConnector, cloudconvertConnector, cloudinaryConnector, cloutlyConnector, codaConnector, cognitoFormsConnector, cohereConnector, cometapiConnector, comfyicuConnector, confluenceConnector, constantContactConnector, contentfulConnector, convertkitConnector, copperConnector, copyAiConnector, crispConnector, cryptolensConnector, customerIoConnector, customgptConnector, dashworksConnector, datadogConnector, datafuelConnector, datocmsConnector, declarativeRestConnector, deepseekConnector, denserAiConnector, descriptConnector, devinConnector, discordConnector, dittofeedConnector, doctlyConnector, documentproConnector, documergeConnector, docuseal, docusignConnector, dropboxConnector, dubConnector, dumplingAiConnector, dustConnector, easyPeasyAiConnector, ebayConnector, edenAiConnector, elasticEmailConnector, emailitConnector, emailoctopusConnector, enrichlayerConnector, esignaturesConnector, etsyConnector, exaConnector, facebookLeadsConnector, facebookPagesConnector, fathomAnalyticsConnector, fathomConnector, figjamConnector, figmaConnector, filloutFormsConnector, firebaseConnector, fireberryConnector, firecrawlConnector, firefliesAiConnector, flipandoConnector, flowiseConnector, flowluConnector, folkConnector, foreplayCoConnector, formbricksConnector, formstackConnector, fountainConnector, fragmentConnector, frameConnector, freeAgentConnector, freshsalesConnector, freshserviceConnector, frontConnector, gameballConnector, geminiConnector, ghostcmsConnector, gistlyConnector, giteaConnector, githubConnector, gitlabConnector, glideConnector, gmail, googleBigqueryConnector, googleCalendar, googleCloudStorageConnector, googleContactsConnector, googleDocs, googleDrive, googleForms, googleGeminiConnector, googleMyBusinessConnector, googleSearchConnector, googleSearchConsoleConnector, googleSheets, googleSlidesConnector, googleTasksConnector, googleVertexaiConnector, googlechatConnector, gorgiasConnector, gotifyConnector, gptzeroDetectAiConnector, granolaConnector, greenhouseConnector, greenptConnector, greipConnector, griptapeConnector, gristConnector, guideliteConnector, gustoConnector, harvestConnector, hashiCorpVaultConnector, hastewireConnector, heartbeatConnector, hedyConnector, hellosign, helpscoutConnector, heygenConnector, heymarketSmsConnector, housecallProConnector, hubspot, huggingFaceConnector, huggingfaceConnector, humeAiConnector, hunterConnector, hystructConnector, ibmCognoseConnector, imageRouterConnector, imapConnector, influencersClubConnector, insightlyConnector, insightoAiConnector, instaChartsConnector, instantlyAiConnector, instasentConnector, intercomConnector, invoiceninjaConnector, jinaAiConnector, jiraCloudConnector, jiraDataCenterConnector, joggAiConnector, jotformConnector, justInvoiceConnector, kallabotAiConnector, kapsoConnector, kimaiConnector, kissflowConnector, kizeoFormsConnector, klaviyoConnector, klentyConnector, knackConnector, knockConnector, koFiConnector, kommoConnector, kudosityConnector, kustomerConnector, leadConnectorConnector, leapAiConnector, leexiConnector, lemlistConnector, lemonSqueezyConnector, letsCalendarConnector, lettaConnector, leverConnector, lightfunnelsConnector, linearConnector, linkaConnector, linkupConnector, llmrailsConnector, lobstermailConnector, localaiConnector, loftyConnector, logrocketConnector, logsnagConnector, lokaliseConnector, loopsConnector, lucidyaConnector, lushaConnector, luxuryPresenceConnector, magicalApiConnector, mailchainConnector, mailchimpConnector, mailerLiteConnector, mailercheckConnector, mailerooConnector, mailgunConnector, makeConnector, manychatConnector, marketoConnector, mastodonConnector, matomoConnector, matrixConnector, mattermostConnector, mauticConnector, medullarConnector, meetgeekAiConnector, memConnector, messagebirdConnector, metabaseConnector, microsoft365PeopleConnector, microsoft365PlannerConnector, microsoftCalendar, microsoftDynamics365BusinessCentralConnector, microsoftDynamicsCrmConnector, microsoftExcel365Connector, microsoftGraph, microsoftOnedriveConnector, microsoftOnenoteConnector, microsoftOutlookCalendarConnector, microsoftOutlookConnector, microsoftPowerBiConnector, microsoftSharepointConnector, microsoftTeams, microsoftTodoConnector, millionverifierConnector, mindStudioConnector, mindeeConnector, miroConnector, missiveConnector, mixmaxConnector, mixpanelConnector, mollieConnector, mondayConnector, mongodbConnector, n8nConnector, netlifyConnector, niftyConnector, ninjapipeConnector, nocodbConnector, notionConnector, notionDatabase, ntfyConnector, odooConnector, omniCoConnector, omnihrConnector, oneDrive, openPhoneConnector, openRouterConnector, openaiConnector, openmicAiConnector, opnformConnector, opportifyConnector, opsgenieConnector, oracleDatabaseConnector, orimonConnector, outlookMail, paddleConnector, pagerdutyConnector, pandadoc, paperformConnector, parseurConnector, pastefyConnector, paywhirlConnector, pdfmonkeyConnector, peekshotConnector, perplexityAiConnector, personalAiConnector, pinchPaymentsConnector, pineconeConnector, pipedreamConnector, pipedriveConnector, placidConnector, plausibleConnector, pocketbaseConnector, pollybotAiConnector, postgresConnector, posthogConnector, postizConnector, postmarkConnector, predictLeadsConnector, productboardConnector, proxycurlConnector, pushbulletConnector, pushoverConnector, qawafelConnector, qdrantConnector, quadernoConnector, quickbooksConnector, quickzuConnector, raiaAiConnector, rapidtextAiConnector, reachinboxConnector, recallAiConnector, redditConnector, reoonVerifierConnector, replyIoConnector, retableConnector, retellAiConnector, ripplingConnector, robollyConnector, runwareConnector, saasticConnector, saleorConnector, salesforceConnector, sanityConnector, sardisConnector, savvycalConnector, scrapegraphaiConnector, scrapelessConnector, seekTableConnector, sendgridConnector, sendinblueConnector, sendpulseConnector, senjaConnector, sentryConnector, serpstatConnector, serviceNowConnector, sharepoint, shippoConnector, shopifyConnector, shortIoConnector, signNowConnector, signrequestConnector, simplirouteConnector, simplybookmeConnector, skyprepConnector, slack, slackEventsConnector, smartleadConnector, smartsheetConnector, smartsuiteConnector, smooveConnector, smsmodeConnector, snowflakeConnector, socialkitConnector, squareConnector, stripeConnector, stripePackConnector, stripeWebhookReceiverConnector, supabaseConnector, supadataConnector, swarmnodeConnector, systemeIoConnector, tableauConnector, talkableConnector, tallyConnector, teableConnector, telegramConnector, telnyxConnector, tenzoConnector, textcortexAiConnector, ticktickConnector, timeOpsConnector, timelinesAiConnector, tlDvConnector, todoistConnector, togglTrackConnector, totalcmsConnector, trelloConnector, twentyConnector, twilioConnector, twilioSmsConnector, twinLabsConnector, twitterConnector, typeformConnector, typefullyConnector, umamiConnector, upgradechatConnector, uscreenConnector, validatedmailsConnector, vapiConnector, vboutConnector, vercelConnector, videoaskConnector, vidlab7Connector, vlmRunConnector, voucheryIoConnector, vtexConnector, vtigerConnector, wafeqConnector, weaviateConnector, webflowConnector, webhookConnector, webscrapingAiConnector, whatConvertsConnector, whatsappBusiness, whatsappConnector, whatsscaleConnector, wonderchatConnector, woocommerceConnector, woodpeckerConnector, wootricConnector, wordpressConnector, workableConnector, workdayConnector, wrikeConnector, writesonicBulkConnector, wufooConnector, xeroConnector, youcanbookmeConnector, zagomailConnector, zapierConnector, zendeskConnector, zendeskSellConnector, zeplinConnector, zerobounceConnector, zohoBookingsConnector, zohoCrmConnector, zohoDeskConnector, zuoraConnector };