@tangle-network/agent-integrations 0.1.2 → 0.2.0

package/dist/index.d.ts

@@ -535,6 +535,374 @@ interface GenericHmacVerifyOptions {
 declare function verifyHmacSignature(rawBody: string, signatureHeader: string, secret: string, options?: GenericHmacVerifyOptions): boolean;
 declare function firstHeader(headers: Record<string, string | string[] | undefined>, name: string): string | undefined;
 
+/**
+ * Google Calendar connector — CAS reference implementation.
+ *
+ * Scopes: `https://www.googleapis.com/auth/calendar` covers list/insert/
+ * patch on the user's calendars. We could split read/write but for v1 the
+ * single scope keeps the consent screen simple; an operator who wants
+ * read-only-Calendar can pick a different `kind` later (`google-calendar-readonly`).
+ *
+ * The two capabilities the agent actually needs:
+ *
+ *   list_availability(calendarId, timeMin, timeMax)
+ *     → {busy: [{start, end}], events: [{id, etag, start, end, summary}]}
+ *     Read; no CAS. Cheap (events.list).
+ *
+ *   book_slot(calendarId, start, end, summary, attendees?)
+ *     → {eventId, etag}
+ *     Mutation. CAS by Calendar's own conflict-detection: we re-list
+ *     events for the requested window inside the same call, and if any
+ *     OVERLAP exists we return `conflict` with the next-3 free slots
+ *     mined from the user's freebusy, instead of inserting.
+ *
+ * Why pre-flight read-then-insert rather than relying on If-Match:
+ * `events.insert` doesn't take If-Match (you can't precondition an
+ * insert against a non-existent resource). Calendar's own
+ * `freebusy.query` is the canonical conflict signal. The whole flow is:
+ *
+ *   1. freebusy.query for [start, end] on this calendarId
+ *   2. if busy → emit ResourceContention with next-3 free slots
+ *      (computed by walking forward in 30-min steps until 3 free
+ *      windows of (end-start) duration found)
+ *   3. else events.insert with idempotency-key as `requestId` (a Calendar
+ *      API feature that gives us per-key dedup at upstream)
+ *
+ * Step 3's `requestId` parameter means a retry of the same idempotency
+ * key on the same calendar will return the original event rather than
+ * creating a duplicate, which composes correctly with our MutationGuard's
+ * idempotency record (which short-circuits before ever hitting upstream
+ * on the second call). Defense-in-depth.
+ */
+
+/** OAuth client config the factory closes over. Caller resolves these
+ *  at construction time (env, DB, secret manager — package doesn't care). */
+interface GoogleCalendarOptions {
+    clientId: string;
+    clientSecret: string;
+}
+declare function googleCalendar(opts: GoogleCalendarOptions): ConnectorAdapter;
+
+/**
+ * Google Sheets connector — live KB source + writable rows.
+ *
+ * The flagship for the "agent reads from a live spreadsheet" UX. The
+ * customer points the connection at a Sheet (spreadsheetId + sheetName +
+ * headerRow). We expose:
+ *
+ *   list_rows(filter?, limit?)
+ *     → {rows: [{...header→cell}], nextCursor?}
+ *     Cheap; just spreadsheets.values.get with the configured range.
+ *
+ *   query_rows(predicate)
+ *     → same shape as list_rows but with a structured filter (k=v pairs
+ *     ANDed together). Simple and explainable; no SQL.
+ *
+ *   update_row(rowKey, patch)
+ *     → {row: {...header→cell}, updatedRange}
+ *     Mutation. CAS via Sheets' spreadsheets.values.update + a
+ *     pre-flight read of the row's revisionId-equivalent hash. Sheets
+ *     doesn't expose a per-row etag, so we synthesize one — see
+ *     `rowFingerprint`. If the fingerprint doesn't match what the agent
+ *     last read, we surface ResourceContention with the current row in
+ *     `currentState`.
+ *
+ * KB binding: when a Sheet is `consistencyModel: 'cache'` (the default
+ * for spreadsheets — they're slow-moving), the system also indexes the
+ * rows as KB chunks. The KB build pipeline calls `list_rows` and emits
+ * one markdown page per row; on a connector-level "refresh" event the
+ * agent's KB rebuilds.
+ */
+
+/** OAuth client config the factory closes over. Caller resolves these
+ *  at construction time (env, DB, secret manager — package doesn't care). */
+interface GoogleSheetsOptions {
+    clientId: string;
+    clientSecret: string;
+}
+declare function googleSheets(opts: GoogleSheetsOptions): ConnectorAdapter;
+
+/**
+ * Microsoft Graph Calendar connector — the Outlook half of the
+ * voice-agent's "book me a slot" surface.
+ *
+ * Mirrors the Google Calendar pattern almost line-for-line, with two
+ * upstream-specific quirks worth calling out:
+ *
+ *   1. Graph exposes `@odata.etag` on every event resource AND honors
+ *      `If-Match` on `events.patch` / `events.delete`. So unlike Calendar
+ *      (insert can't be preconditioned against a non-existent resource),
+ *      we DO get real etag CAS for updates after the booking. We still
+ *      use the freebusy pre-flight for the create path, because the
+ *      "two callers grab the same slot" race happens before any event
+ *      exists.
+ *
+ *   2. `getSchedule` is the Graph equivalent of `freeBusy.query`. Same
+ *      shape: send `[start, end]` plus the calendar's email/UPN, get
+ *      back a `scheduleItems` list of busy windows.
+ *
+ * Why the same flow ports cleanly: the conflict mode is identical
+ * ("did someone else grab this slot between read and write?"). The
+ * mechanism — pre-flight read + idempotent insert — composes regardless
+ * of whether upstream gives us a request-id dedup feature. Graph does
+ * not have a `requestId` analogue on `events.create`, so we rely
+ * exclusively on MutationGuard's idempotency-key short-circuit ABOVE
+ * the connector. That layer prevents duplicate inserts on retry.
+ */
+
+/** OAuth client config the factory closes over. Caller resolves these
+ *  at construction time (env, DB, secret manager — package doesn't care). */
+interface MicrosoftCalendarOptions {
+    clientId: string;
+    clientSecret: string;
+}
+declare function microsoftCalendar(opts: MicrosoftCalendarOptions): ConnectorAdapter;
+
+/**
+ * HubSpot CRM connector — three load-bearing capabilities, picked to
+ * cover the voice-agent's CRM hot path without trying to swallow all of
+ * HubSpot's surface in v1.
+ *
+ *   find_contact(email)
+ *     → {contact: {id, properties}} | {found: false}
+ *     POST /crm/v3/objects/contacts/search with an email-equality filter.
+ *     Cheap, idempotent, no CAS needed (read).
+ *
+ *   upsert_contact(email, properties)
+ *     → {contactId, created}
+ *     Mutation. CAS strategy = native-idempotency, BUT: HubSpot's
+ *     `idempotencyKey` query param is ONLY available on the v3 *batch*
+ *     endpoints (`/crm/v3/objects/contacts/batch/upsert`). The
+ *     single-record endpoints don't honor it. We use the batch endpoint
+ *     with a single-element array to get native idempotency on retry.
+ *
+ *   create_note(contactId, body)
+ *     → {noteId}
+ *     Mutation that logs a note engagement on a contact and associates
+ *     it. Notes are append-only — there's no conflict to detect — so we
+ *     use native-idempotency via the same batch trick on
+ *     `/crm/v3/objects/notes/batch/create`.
+ *
+ * Why three and not thirty: the agent's leverage on HubSpot is
+ * "remember who I just spoke to". `find_contact` lets the agent address
+ * a returning caller by name; `upsert_contact` captures a new one
+ * without duplicates; `create_note` writes the call's outcome as a CRM
+ * activity. Anything beyond these (deals, tickets, lists) lives in
+ * Tier-2 specific kinds — keeping the manifest tight keeps the agent's
+ * tool registry comprehensible.
+ */
+
+/** OAuth client config the factory closes over. Caller resolves these
+ *  at construction time (env, DB, secret manager — package doesn't care). */
+interface HubSpotOptions {
+    clientId: string;
+    clientSecret: string;
+}
+declare function hubspot(opts: HubSpotOptions): ConnectorAdapter;
+
+/**
+ * Slack connector — bot-token OAuth, three messaging-oriented capabilities.
+ *
+ *   post_message(channel, text|blocks)  → mutation; cas: 'none'
+ *   lookup_user(email)                  → read
+ *   list_channels(types?, limit?)       → read
+ *
+ * Why `cas: 'none'` is acceptable here (and only here in this batch):
+ * Slack messages are advisory — we set
+ * `defaultConsistencyModel: 'advisory'`. The registry validator allows
+ * `cas: 'none'` only on non-authoritative connectors precisely so that
+ * append-only messaging surfaces don't have to invent fake CAS theatre.
+ * The agent's planner already treats `advisory` data as informational
+ * and does not promise outcomes based on its post results without
+ * a separate authoritative confirm. MutationGuard's idempotency-key
+ * dedup remains in force above the connector — a retry of the same
+ * post_message call will short-circuit before reaching Slack.
+ *
+ * Auth: standard OAuth2. Slack's `/oauth.v2.access` returns a bot
+ * `access_token` (`xoxb-…`) but does NOT return a refresh_token unless
+ * the app has rotated tokens enabled. Bot tokens are long-lived by
+ * default; we surface refreshToken handling but treat its absence as
+ * normal rather than an error.
+ */
+
+/** OAuth client config the factory closes over. Caller resolves these
+ *  at construction time (env, DB, secret manager — package doesn't care). */
+interface SlackOptions {
+    clientId: string;
+    clientSecret: string;
+}
+declare function slack(opts: SlackOptions): ConnectorAdapter;
+
+/**
+ * Notion database connector — query + page-level CRUD against a single
+ * connected database.
+ *
+ *   query_database(filter?, pageSize?)  → read
+ *   create_page(properties)             → mutation; cas: 'native-idempotency'
+ *   update_page(pageId, properties)     → mutation; cas: 'etag-if-match'
+ *
+ * CAS quirks worth flagging:
+ *
+ *   1. Notion added support for the `Idempotency-Key` HTTP header on
+ *      mutating requests. We forward our SDK's idempotency key on
+ *      create_page, which gives at-most-once semantics under the same
+ *      key for ~24h. MutationGuard's record short-circuits above us;
+ *      Notion's dedup is the second line of defense.
+ *
+ *   2. Notion does NOT expose a per-page etag the way Graph does. The
+ *      canonical drift signal is `last_edited_time` (RFC3339). Our
+ *      `update_page` capability accepts an `expectedLastEditedTime` arg;
+ *      if supplied, we GET the page first and compare. Mismatch →
+ *      ResourceContention with the current page state. Conflict-free
+ *      callers can omit the field (last-write-wins, the Notion default).
+ *
+ * Auth: standard OAuth2. Notion's token endpoint follows RFC 6749 with
+ * one twist — the workspace_id and bot_id come back in the response and
+ * we stash them in `metadata` so the agent can address resources by
+ * workspace where useful.
+ */
+
+/** OAuth client config the factory closes over. Caller resolves these
+ *  at construction time (env, DB, secret manager — package doesn't care). */
+interface NotionDatabaseOptions {
+    clientId: string;
+    clientSecret: string;
+}
+declare function notionDatabase(opts: NotionDatabaseOptions): ConnectorAdapter;
+
+/**
+ * Twilio SMS connector — outbound texts + recent-message lookup. The
+ * agent's "send the caller a confirmation link" surface.
+ *
+ * Auth: HTTP Basic (Account SID + Auth Token). Twilio's API key auth
+ * also supports SID/Secret pairs; we accept either by treating the
+ * stored apiKey envelope as `accountSid:authToken` (or
+ * `accountSid:keySid:secret`) — the connector parses it at call time.
+ *
+ *   send_sms(to, body)
+ *     Mutation. CAS = native-idempotency. Twilio added the
+ *     `Idempotency-Key` HTTP header to POST /Messages in 2024 — same
+ *     key + same args within 24h returns the original Message resource
+ *     instead of sending a second SMS. MutationGuard's record short-
+ *     circuits before us; Twilio's own dedup is defense-in-depth.
+ *
+ *   lookup_number(phoneNumber)
+ *     Read. Hits /v1/PhoneNumbers/{e164} on Lookup API. Confirms the
+ *     number is real, returns carrier info if the caller has Lookup
+ *     enabled on their account.
+ *
+ *   find_recent_messages(toOrFrom?, limit?)
+ *     Read. Returns the most recent Messages on the account, optionally
+ *     filtered by To/From. Useful for "did the confirmation actually
+ *     send?" introspection inside an agent run.
+ */
+
+declare const twilioSmsConnector: ConnectorAdapter;
+
+/**
+ * Stripe pack connector — single connector kind packing 3 capabilities,
+ * validating the "connector pack" concept (one auth handshake, multiple
+ * related capabilities) without exploding the registry into
+ * `stripe-customers`, `stripe-checkout`, `stripe-invoices` triplets.
+ *
+ *   find_customer(email)               → read; CAS n/a
+ *   create_invoice(customerId, items)  → mutation; cas: 'native-idempotency'
+ *   create_checkout_session(...)       → mutation; cas: 'native-idempotency'
+ *
+ * Auth: API key (Stripe restricted key). Operator pastes the key into
+ * the Connections UI. We never see their account password / OAuth flow;
+ * Stripe restricted keys are the customer's responsibility (they pick
+ * which permissions the key carries). The kind exposes a webhook URL
+ * post-connect for the operator to paste into the Stripe dashboard —
+ * we'll wire the receiver to P-3's inbound webhook surface in a later
+ * commit. That URL is returned in `metadata.webhookUrl` so the UI can
+ * render it.
+ *
+ * Why this is the textbook example of `cas: 'native-idempotency'`:
+ * Stripe's `Idempotency-Key` HTTP header is THE reference implementation
+ * of native idempotency. Same key + same args within 24h returns the
+ * stored response (Stripe's words, not ours). Same key + different args
+ * → 400 with `idempotency_error`. We forward the SDK's idempotency key
+ * directly. MutationGuard short-circuits before us on retry; Stripe's
+ * own dedup is the second line of defense.
+ */
+
+declare const stripePackConnector: ConnectorAdapter;
+
+/**
+ * Universal webhook connector — the long-tail escape hatch.
+ *
+ * The user declares a target URL + a JSON-schema for the request body
+ * the agent should send, plus an optional shared secret. We sign every
+ * outbound POST with HMAC-SHA256 over `timestamp.body` and forward the
+ * agent's idempotency key as a header. The receiving system enforces
+ * its own idempotency.
+ *
+ * One adapter, two capabilities. Both arity-1 — `body` is whatever JSON
+ * the agent's planner constructs from the operator-defined schema (which
+ * lives in DataSource.metadata.requestSchema). The agent's planner reads
+ * that schema at request time and constructs valid args.
+ *
+ * Why one connector covers 50 systems badly and 1 system well: the agent
+ * gets a generic "send_event" tool that doesn't *know* what the upstream
+ * does with the payload. That's fine for fire-and-forget event posting
+ * (Zapier-style); it's wrong for booking against a calendar where you
+ * need conflict-resolution. So webhook's `post_event` capability is
+ * marked `cas: 'native-idempotency'` (we forward the key — the receiver
+ * MUST honor it) and `defaultConsistencyModel: 'advisory'`. Anyone
+ * needing real CAS uses a kind-specific connector (Calendar, Sheets, ...).
+ */
+
+declare const webhookConnector: ConnectorAdapter;
+
+/**
+ * Stripe inbound-webhook receiver — push-only side of a Stripe connector.
+ *
+ * The full Stripe connector (charges/customers/invoices read+mutation) is
+ * tracked in INTEGRATIONS.md as separate `stripe-customers` / `stripe-invoices`
+ * rows. This adapter only ships the inbound surface today: receive a push,
+ * verify the signature, persist one `InboundEvent` per Stripe event so the
+ * agent's runtime can react (e.g. payment_failed → outbound dunning call).
+ *
+ * Why a dedicated `kind: 'stripe'` rather than reusing the billing webhook
+ * at /api/billing/stripe-webhook: that route is hard-coded for OUR Stripe
+ * account (Builder subscription state). This connector is for the customer's
+ * OWN Stripe account — they paste their `whsec_*` and we listen on a
+ * per-DataSource URL, /api/webhooks/inbound/stripe/:dataSourceId.
+ *
+ * Signature scheme: Stripe's `t=<unix>,v1=<hmac>` header. HMAC is
+ * sha256(`${t}.${rawBody}`) keyed by the customer's webhook secret. We use
+ * `timingSafeEqual` to defeat timing oracles and bound timestamp skew at
+ * 5 minutes (Stripe's recommendation) to thwart replay against captured
+ * signatures.
+ */
+
+declare const stripeWebhookReceiverConnector: ConnectorAdapter;
+
+/**
+ * Slack Events API inbound receiver.
+ *
+ * Slack sends two distinct request shapes to the same webhook URL:
+ *
+ *   1. `url_verification` — a one-off handshake during app-config. The body
+ *      contains a `challenge` string we MUST echo back as the response body
+ *      (Slack's app-config UI fails the URL otherwise). No InboundEvent is
+ *      persisted for this — it's an infrastructure ping, not a user event.
+ *
+ *   2. `event_callback` — every actual workspace event (message posted,
+ *      reaction added, channel created, …). We persist one InboundEvent
+ *      keyed by `event_id` so a Slack retry (Slack retries 3 times on any
+ *      non-2xx) is deduped at the unique constraint, not after we've
+ *      double-processed.
+ *
+ * Signature scheme: `v0=<hmac(sha256, "v0:<timestamp>:<rawBody>")>` keyed by
+ * the app's signing secret. Header `X-Slack-Request-Timestamp` carries the
+ * timestamp; we reject anything older than 5 minutes (Slack's recommendation)
+ * to bound replay risk.
+ */
+
+declare const slackEventsConnector: ConnectorAdapter;
+
 type IntegrationProviderKind = 'first_party' | 'nango' | 'pipedream' | 'zapier' | 'activepieces' | 'executor' | 'custom';
 type IntegrationConnectorCategory = 'email' | 'calendar' | 'chat' | 'crm' | 'storage' | 'docs' | 'database' | 'webhook' | 'workflow' | 'internal' | 'other';
 type IntegrationActionRisk = 'read' | 'write' | 'destructive';
@@ -793,4 +1161,4 @@ declare function createHttpIntegrationProvider(options: HttpIntegrationProviderO
 declare function signCapability(capability: IntegrationCapability, secret: string): string;
 declare function verifyCapabilityToken(token: string, secret: string): IntegrationCapability;
 
-export { type AuthSpec, type CASStrategy, type Capability, type CapabilityClass, type CapabilityMutation, type CapabilityMutationResult, type CapabilityParameterSchema, type CapabilityRead, type CapabilityReadResult, type CompleteAuthRequest, type ConnectorAdapter, type ConnectorCredentials, type ConnectorInvocation, type ConnectorManifest, type ConnectorManifestValidationIssue, type ConnectorManifestValidationResult, type ConsistencyModel, CredentialsExpired, DEFAULT_SIGNATURE_TOLERANCE_SECONDS, type DataSourceMetadata, type EventHandlerResult, type ExchangeCodeInput, type GenericHmacVerifyOptions, type HttpIntegrationProviderOptions, InMemoryConnectionStore, InMemoryOAuthFlowStore, type InboundEvent, type IntegrationActionGuard, type IntegrationActionRequest, type IntegrationActionResult, type IntegrationActionRisk, type IntegrationActor, type IntegrationCapability, type IntegrationConnection, type IntegrationConnectionStore, type IntegrationConnector, type IntegrationConnectorAction, type IntegrationConnectorCategory, type IntegrationConnectorTrigger, type IntegrationDataClass, IntegrationError, type IntegrationGuardContext, IntegrationHub, type IntegrationHubOptions, type IntegrationProvider, type IntegrationProviderKind, type IntegrationTriggerEvent, type IntegrationTriggerSubscription, type InvokeWithCapabilityRequest, type IssueCapabilityRequest, type IssuedIntegrationCapability, type OAuthFlowStore, type OAuthTokens, type ParsedStripeSignatureHeader, type PendingOAuthFlow, type RateLimitSpec, type RefreshInput, type ResolvedDataSource, ResourceContention, type SecretRef, type SlackVerifyOptions, type StartAuthRequest, type StartAuthResult, type StartOAuthInput, type StartOAuthOutput, type StripeVerifyOptions, _resetPendingFlowsForTests, assertValidConnectorManifest, consumePendingFlow, createHttpIntegrationProvider, createMockIntegrationProvider, exchangeAuthorizationCode, firstHeader, parseStripeSignatureHeader, refreshAccessToken, sanitizeConnection, signCapability, startOAuthFlow, validateConnectorManifest, verifyCapabilityToken, verifyHmacSignature, verifySlackSignature, verifyStripeSignature };
+export { type AuthSpec, type CASStrategy, type Capability, type CapabilityClass, type CapabilityMutation, type CapabilityMutationResult, type CapabilityParameterSchema, type CapabilityRead, type CapabilityReadResult, type CompleteAuthRequest, type ConnectorAdapter, type ConnectorCredentials, type ConnectorInvocation, type ConnectorManifest, type ConnectorManifestValidationIssue, type ConnectorManifestValidationResult, type ConsistencyModel, CredentialsExpired, DEFAULT_SIGNATURE_TOLERANCE_SECONDS, type DataSourceMetadata, type EventHandlerResult, type ExchangeCodeInput, type GenericHmacVerifyOptions, type GoogleCalendarOptions, type GoogleSheetsOptions, type HttpIntegrationProviderOptions, type HubSpotOptions, InMemoryConnectionStore, InMemoryOAuthFlowStore, type InboundEvent, type IntegrationActionGuard, type IntegrationActionRequest, type IntegrationActionResult, type IntegrationActionRisk, type IntegrationActor, type IntegrationCapability, type IntegrationConnection, type IntegrationConnectionStore, type IntegrationConnector, type IntegrationConnectorAction, type IntegrationConnectorCategory, type IntegrationConnectorTrigger, type IntegrationDataClass, IntegrationError, type IntegrationGuardContext, IntegrationHub, type IntegrationHubOptions, type IntegrationProvider, type IntegrationProviderKind, type IntegrationTriggerEvent, type IntegrationTriggerSubscription, type InvokeWithCapabilityRequest, type IssueCapabilityRequest, type IssuedIntegrationCapability, type MicrosoftCalendarOptions, type NotionDatabaseOptions, type OAuthFlowStore, type OAuthTokens, type ParsedStripeSignatureHeader, type PendingOAuthFlow, type RateLimitSpec, type RefreshInput, type ResolvedDataSource, ResourceContention, type SecretRef, type SlackOptions, type SlackVerifyOptions, type StartAuthRequest, type StartAuthResult, type StartOAuthInput, type StartOAuthOutput, type StripeVerifyOptions, _resetPendingFlowsForTests, assertValidConnectorManifest, consumePendingFlow, createHttpIntegrationProvider, createMockIntegrationProvider, exchangeAuthorizationCode, firstHeader, googleCalendar, googleSheets, hubspot, microsoftCalendar, notionDatabase, parseStripeSignatureHeader, refreshAccessToken, sanitizeConnection, signCapability, slack, slackEventsConnector, startOAuthFlow, stripePackConnector, stripeWebhookReceiverConnector, twilioSmsConnector, validateConnectorManifest, verifyCapabilityToken, verifyHmacSignature, verifySlackSignature, verifyStripeSignature, webhookConnector };