@tangle-network/agent-integrations 0.9.0 → 0.14.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +73 -0
- package/data/activepieces-catalog.json +40907 -0
- package/dist/index.d.ts +344 -2
- package/dist/index.js +5181 -4243
- package/dist/index.js.map +1 -1
- package/docs/catalog-registry.md +59 -0
- package/docs/integration-coverage-checklist.md +3 -1
- package/docs/third-party/activepieces.md +57 -0
- package/package.json +2 -1
package/README.md
CHANGED
|
@@ -15,6 +15,7 @@ agent-facing tool contract.
|
|
|
15
15
|
- [Architecture](#architecture)
|
|
16
16
|
- [Install](#install)
|
|
17
17
|
- [Core Primitives](#core-primitives)
|
|
18
|
+
- [Catalog Registry](#catalog-registry)
|
|
18
19
|
- [Provider Strategy](#provider-strategy)
|
|
19
20
|
- [Executable Coverage](#executable-coverage)
|
|
20
21
|
- [Examples](#examples)
|
|
@@ -31,10 +32,19 @@ agent-facing tool contract.
|
|
|
31
32
|
- Policy checks for read/write/destructive actions.
|
|
32
33
|
- Invocation-envelope validation before sandbox tool calls reach the hub.
|
|
33
34
|
- A generic HTTP provider boundary for hosted integration gateways.
|
|
35
|
+
- A gateway catalog provider for Nango, Pipedream, Activepieces, Zapier,
|
|
36
|
+
executor-style gateways, and internal connector registries.
|
|
34
37
|
- A first-party `ConnectorAdapter` boundary for direct provider execution.
|
|
35
38
|
- A declarative REST adapter factory for promoting REST APIs from reviewed specs.
|
|
36
39
|
- A broad coverage catalog for planning hundreds of integrations without
|
|
37
40
|
pretending every catalog item is executable.
|
|
41
|
+
- A canonical registry that deduplicates overlapping catalogs, keeps support
|
|
42
|
+
tiers explicit, and reports auth/category conflicts.
|
|
43
|
+
- App/agent manifests, grants, and sandbox bundles so Builder, generated apps,
|
|
44
|
+
vertical agents, Blueprint Agent, and executor-backed runtimes can reuse the
|
|
45
|
+
same user-owned connections safely.
|
|
46
|
+
- Workflow trigger installation and normalized event dispatch for non-agent UI
|
|
47
|
+
automation, sync jobs, webhooks, and product workflows.
|
|
38
48
|
- A generated `IntegrationSpec` registry used for setup docs, admin UI steps,
|
|
39
49
|
normalized permissions, healthcheck plans, and tool descriptions.
|
|
40
50
|
|
|
@@ -72,9 +82,16 @@ pnpm add @tangle-network/agent-integrations
|
|
|
72
82
|
| `IntegrationConnection` | User/team/agent-owned grant with scopes and secret references. |
|
|
73
83
|
| `IntegrationHub` | Facade for provider catalogs, connection storage, capabilities, and invocation. |
|
|
74
84
|
| `IntegrationCapability` | Short-lived authorization for a specific subject, connection, scope set, and action set. |
|
|
85
|
+
| `IntegrationManifest` | Generated app or agent requirements: connectors, actions, scopes, and reasons. |
|
|
86
|
+
| `IntegrationGrant` | Persistent grant from a user-owned connection to an app, agent, or sandbox consumer. |
|
|
87
|
+
| `createIntegrationRuntime` | Facade for manifest resolution, grant creation, and sandbox capability bundles. |
|
|
88
|
+
| `createIntegrationWorkflowRuntime` | Installs trigger workflows and dispatches normalized provider events. |
|
|
75
89
|
| `buildIntegrationToolCatalog` | Converts connector actions into agent/tool definitions. |
|
|
76
90
|
| `searchIntegrationTools` | Intent search over normalized integration tools. |
|
|
91
|
+
| `buildDefaultIntegrationRegistry` | Composes setup specs and vendored catalog metadata into one deduplicated connector registry. |
|
|
92
|
+
| `composeIntegrationRegistry` | Merges arbitrary catalog sources with explicit aliases, precedence, support tiers, and conflict diagnostics. |
|
|
77
93
|
| `buildIntegrationCoverageConnectors` | Planning catalog for 100+ high-value integrations. |
|
|
94
|
+
| `createGatewayCatalogProvider` | Normalizes 500+ gateway-backed connectors into the same provider contract. |
|
|
78
95
|
| `buildIntegrationInvocationEnvelope` | Sandbox-safe action envelope. |
|
|
79
96
|
| `validateIntegrationInvocationEnvelope` | Runtime validation for tool/action consistency and input limits. |
|
|
80
97
|
| `createHttpIntegrationProvider` | Adapter for hosted integration gateways. |
|
|
@@ -84,6 +101,62 @@ pnpm add @tangle-network/agent-integrations
|
|
|
84
101
|
| `renderRunbookMarkdown` / `renderConsoleSteps` | Render operator docs or admin UI steps from the same spec source. |
|
|
85
102
|
| `validateCredentialSet` / `buildHealthcheckPlan` | Validate setup input and describe the correct healthcheck path. |
|
|
86
103
|
|
|
104
|
+
## Catalog Registry
|
|
105
|
+
|
|
106
|
+
Catalog breadth and runtime execution are separate. Activepieces metadata gives
|
|
107
|
+
the package broad connector inventory; first-party adapters and gateways decide
|
|
108
|
+
which connectors can actually run.
|
|
109
|
+
|
|
110
|
+
Use `buildDefaultIntegrationRegistry()` before creating tool catalogs or
|
|
111
|
+
connection pickers. It produces one canonical connector per integration,
|
|
112
|
+
dedupes aliases such as `notion -> notion-database`, keeps source provenance in
|
|
113
|
+
metadata, and marks each connector with a support tier:
|
|
114
|
+
|
|
115
|
+
```txt
|
|
116
|
+
catalogOnly < setupReady < gatewayExecutable < firstPartyExecutable < sandboxExecutable
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
See [Catalog Registry](./docs/catalog-registry.md).
|
|
120
|
+
|
|
121
|
+
## App And Agent Grants
|
|
122
|
+
|
|
123
|
+
Use `IntegrationManifest` for any app or agent that needs integrations:
|
|
124
|
+
Agent Builder-generated apps, tax/legal/GTM/creative agents, Blueprint Agent
|
|
125
|
+
sandboxes, and executor-backed workflows all use the same shape.
|
|
126
|
+
|
|
127
|
+
```ts
|
|
128
|
+
const runtime = createIntegrationRuntime({ hub, grants })
|
|
129
|
+
|
|
130
|
+
const resolution = await runtime.resolveManifest(manifest, user)
|
|
131
|
+
const grants = await runtime.createGrants({
|
|
132
|
+
manifest,
|
|
133
|
+
owner: user,
|
|
134
|
+
grantee: { type: 'app', id: manifest.id },
|
|
135
|
+
})
|
|
136
|
+
const bundle = await runtime.buildSandboxBundle({
|
|
137
|
+
manifestId: manifest.id,
|
|
138
|
+
subject: { type: 'sandbox', id: sandboxId },
|
|
139
|
+
ttlMs: 15 * 60_000,
|
|
140
|
+
})
|
|
141
|
+
```
|
|
142
|
+
|
|
143
|
+
Generated apps and sandboxes receive scoped capability tokens and tool
|
|
144
|
+
definitions. They never receive OAuth refresh tokens, API keys, or raw secrets.
|
|
145
|
+
|
|
146
|
+
The same manifest/grant model works for non-agent workflows:
|
|
147
|
+
|
|
148
|
+
```ts
|
|
149
|
+
await workflows.install({
|
|
150
|
+
workflow,
|
|
151
|
+
owner: user,
|
|
152
|
+
grantee: { type: 'app', id: 'github-pr-sync' },
|
|
153
|
+
})
|
|
154
|
+
```
|
|
155
|
+
|
|
156
|
+
That installs provider trigger subscriptions against the user's connection and
|
|
157
|
+
lets the product dispatch normalized events to UI workflows, sync jobs, or
|
|
158
|
+
agent runs.
|
|
159
|
+
|
|
87
160
|
## Provider Strategy
|
|
88
161
|
|
|
89
162
|
The package deliberately avoids vendor lock-in.
|