Skip to content

Commit c5ddbea

Browse files
feat(connector-docusign): DocuSign eSignature connector app over the installer's OAuth client, sandbox first (#29813)
<!-- claude-projects-attribution: {"github_login":"os-warren"} --> _Requested by **Warren** · [project thread](https://claude.ai/code/project/chan_01U5RdnAAmkSQmZbqh6FtqZ8?thread=cmsg_01U5RdnAAmkSQmZbqh6FtqZ8QyKMa6E3hDZdbZ3S2VtCGM)_ Fixes #28277 Clause-②: no Metadata-protocol: none ## 维护者速读 - 改了什么:新增私有元数据包 `packages/apps/connector-docusign`(仿 `connector-stripe`):DocuSign 电子签的 `openapi` 连接器(只含建信封、读信封、列状态变更三个操作)、`docusign_envelope` 对象及其列表视图、三个流程(发送、刷新单个信封、轮询状态变更)、上架清单、README 与测试。 - 为什么改:#28702 裁决 B 落地后(#28864/#28866/#28869),OAuth 客户端由每个部署的管理员自己注册并在连接时填入;本包用 `clientSource: 'installer'`,仓库里没有任何人的 clientId 或密钥,先走沙箱。 - 风险与回滚:不发布(`private: true`),不改平台代码、不改任何已发布键;回滚即 revert。实时沙箱往返未测(本容器网络策略拒绝 DocuSign 沙箱主机),欠验收运行。 - 先看:① `src/connectors/docusign.connector.ts` 的 `auth`(无 clientId、无 credentialRef);② `test/boot.test.ts` 的连接用例(管理员客户端 → 授权 URL → 回调换码);③ README 的 Credentials 与 Callbacks 两节。 - 两分钟验证:`pnpm --filter @objectstack/connector-app-docusign test`,预期 `objectstack validate` 通过且 2 个测试文件 27 个用例全绿。 - 需要你做的:无,席位落地。 ## What changes A new npm-private metadata package, `@objectstack/connector-app-docusign` in `packages/apps/connector-docusign`, laid out like `packages/apps/connector-stripe`: - `openapi/docusign-esignature.openapi.json`: DocuSign's eSignature document (`docusign/OpenAPI-Specifications` `esignature.rest.swagger-v2.1.json` at `858a3ae59b0edbc8beea4fa3a6d7fe803833dd68`, MIT, licence notice in `openapi/LICENSE`), converted from Swagger 2.0 and trimmed offline by `normalize-openapi` to `Envelopes_PostEnvelopes`, `Envelopes_GetEnvelope` and `Envelopes_GetEnvelopes`, with the 187 empty `consumes` lists filled (`--empty-consumes application/json`). The README's Provenance section records the command, the printed figures and the sha256 the listing test recomputes. - `src/connectors/docusign.connector.ts`: a declarative `provider: 'openapi'` instance named `docusign`. `providerConfig.baseUrl` points it at the sandbox API host (`https://demo.docusign.net/restapi`), and `include` names the three operations. `auth` is `oauth2` `authorization_code` against `account-d.docusign.com` with `scopes: ['signature']` and `clientSource: 'installer'`. No `clientId` and no `credentialRef`: per ruling 6566728470 (letter B), the administrator of each deployment registers their own DocuSign integration key against that deployment's redirect URI and enters it on the connection. No key value is in the repository. - `src/objects/docusign-envelope.object.ts` and `src/views/docusign-envelope.view.ts`: `docusign_envelope` with the two fields the skill eval names, `envelope_id` and `signature_status`, plus `email_subject` and `status_changed_at`, and one grid list view. - `src/flows/docusign.flows.ts`: `docusign_send_envelope` (create and send one envelope, record it only when DocuSign accepted it), `docusign_get_envelope` (read one envelope, refresh its record), and `docusign_poll_status_changes` (list changes since `from_date`, copy each status onto its record; each update contained in a `try_catch`). - `objectstack.manifest.json` with an `iconUrl` at the package's own `assets/icon.svg`, `README.md` (what it adds, credentials, running it, callbacks, limits, provenance), and `test/listing.test.ts` plus `test/boot.test.ts`. - `pnpm-lock.yaml`, regenerated by `pnpm install` only. Besides the new importer, pnpm re-recorded `knex@3.3.0`'s optional peers (`mysql2`, `pg`, `tedious`, already in the lock) on its two importers. A `pnpm install --lockfile-only` on clean `origin/main` `f87239ae` changes nothing, while the same command with this importer added writes exactly this diff, so the peer re-resolution is pnpm's own response to the importer set changing. No changeset: the package is `private: true` and publishes nothing, so this PR carries `skip-changeset`. ## Why #28277 is E4 batch 2 of #27293: DocuSign as the first declarative verification of the outbound OAuth path. Its blocker was the OAuth client. A packaged `clientId` works only on deployments whose callback the client's owner registered (report 6559204204). Ruling 6566728470 chose letter B, executed as #28864 (spec, `clientSource: 'installer'` on `ConnectorInstanceOAuth2AuthorizationCodeAuthSchema`, `packages/spec/src/shared/connector-auth.zod.ts`), #28866 (server: `installerClientOfBegin` and `keptInstallerClient` in `packages/services/service-automation/src/plugin.ts`, `takesInstallerClient` in `oauth2-grant/installer-client.ts`) and #28869 (the Console's Connect dialog). This package is the first listing on that shape. ## Tests `pnpm --filter @objectstack/connector-app-docusign test` at head `d9a09f83`: `objectstack validate` exit 0 (1 object, 4 fields, 1 view, 3 flows, no warning), then vitest `Test Files 2 passed (2)`, `Tests 27 passed (27)` (lock `VERDICT command-exit 0`). `pnpm --filter @objectstack/connector-app-docusign typecheck` exit 0. - `test/listing.test.ts` (17): the manifest parses against `TemplateManifestSchema`, names the stack id and an owned http(s) icon; the connector's `auth` is exactly the installer-client shape and parses against `DeclarativeConnectorEntrySchema`; no file the package owns (outside DocuSign's document) carries a GUID-shaped value; the README's Credentials and Callbacks sections name the redirect URI path, the connection door and the poll flow; the packaged document's sha256 equals the README's record, it is OpenAPI 3.x with no security scheme, carries exactly the three included operations, and gives `Envelopes_PostEnvelopes` a JSON body. - `test/boot.test.ts` (10): booted with `bootStack` against a fake DocuSign (the API through `ConnectorOpenApiPlugin`'s `fetchImpl`, the sandbox token endpoint through a `fetch` stub). Before a connect the instance is degraded "not connected" and the connection read answers `redirectUri`; a flow run fails `FLOW_FAILED` naming the connector and sends nothing; a connect naming no client is refused `400 VALIDATION_ERROR` naming the vendor registration step and the redirect URI; a connect with the administrator's integration key sends the browser to `account-d.docusign.com/oauth/auth` as that client (`scope=signature`, `code_challenge_method=S256`), the callback exchanges the code in HTTP Basic as that client, and the read shows the client without its secret; the instance then materializes with exactly the three actions; the three flows send the expected requests to `demo.docusign.net` as the bearer of the connection's token and write or refresh the record; a refused envelope writes no record. No ablation: the diff adds a package and changes no tested behaviour of existing code. ## Acceptance notes - **Live sandbox round trip: NOT MEASURED, owed to the acceptance run.** `curl https://account-d.docusign.com/.well-known/openid-configuration` from this container: the egress proxy answered the CONNECT with `403 Forbidden` (demo.docusign.net and developers.docusign.com: no answer either). No integration key exists for this repository either, by design. The DocuSign console steps in the README follow DocuSign's documentation and say so. - **Document depth.** The package ships the document at `--max-depth 0` (304,080 bytes, sha256 `b741ded5cfc4d0291d7f0e26559f8583f8c9a783f8711d8f9a98405cb27f7cb4`, 1,438 lines), as `connector-stripe` does. At the default depth of 2 the same run writes 553,922 bytes, sha256 `e1051eb4bbc381d879e979beac8cb64ead24531c93a19fc26e950a12d9fc961d` (the epic probe's hash, re-derived here independently), 4,737 lines, which takes this PR to 6,130 changed lines, over the 3,000-line human-merge threshold. At depth 0 the PR is 2,841 changed lines. The cost: `Envelopes_PostEnvelopes`'s body is described as DocuSign's envelope definition (type and description) rather than with its fields expanded. Switching is one normalizer run plus the README figures and one listing-test assertion. - **Sandbox only.** Production DocuSign signs in at `account.docusign.com` and has a per-account API host (`base_uri` from `/oauth/userinfo`) that a packaged instance cannot name; the README's Limits section says production is not supported yet. No follow-up card is filed here. - **Callbacks.** DocuSign Connect signs its own HMAC header, which the `api` flow door does not verify, so the app takes no Connect posts and polls instead (`docusign_poll_status_changes`); the README says so. - **CEL map typing.** A CEL map literal's values share one type, so every string literal beside a variable read is wrapped in `dyn(…)` at every nesting level; `os validate` refused the first draft that wrapped only the top level (`expression-invalid`, "Map value uses wrong type"). The Stripe README already states the rule for the top level. ## Verification - `node scripts/check-package-naming.mjs`: exit 0 (`129 workspace package(s)`, the `@objectstack/plugin-*` set exactly the 10 frozen names; this package is `@objectstack/connector-app-docusign`, beside `connector-app-stripe` and `connector-app-github`). - `node scripts/pm/dispatch-gates.mjs --commands` on this diff derived 62 families; all 62 ran, every one exit 0; `--ran` reconciliation: "62 derived famil(ies) accounted for — 62 run, 0 NOT-MEASURED". Two first ran exit 3 on missing prerequisites, not on this diff, and were re-run green: `check-plugin-teardown-shape.mjs --self-test` (its pinned fixture commit `621a4876` absent from the shallow clone; fetched) and `check:dual-build-cjs-loads` (unbuilt `dist/` of ten packages this diff does not touch; built). - `pnpm lint` (`eslint . --no-inline-config`) at head `d9a09f83`: exit 0. - Every other CI family: this PR's check-runs. ## Human Minimum - [x] 1. Schemas start as Zod; `packages/spec` holds no runtime logic. (No spec change.) - [x] 2. Every name I added uses the casing for its kind. - [x] 3. No formatter ran; `pnpm lint` passes. - [x] 4. One issue, one branch off an up-to-date `main`, one pull request. - [x] 5. A change that publishes carries a changeset, and both declaration lines are filled in here and in the changeset. (Publishes nothing: `skip-changeset`.) - [x] 6. `packages/spec` touched: its generated artifacts are regenerated and committed. (Not touched.) - [x] 7. No hand edits to `content/docs/references/`, `packages/*/CHANGELOG.md` or `content/docs/releases/`. - [x] 8. Title, body and comments are in English (the 维护者速读 block excepted, by the dispatch contract). 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01JQwxbX1cvwSxDEYCkfDcLg --- _Generated by [Claude Code](https://claude.ai/code/session_01JQwxbX1cvwSxDEYCkfDcLg)_ --------- Co-authored-by: Claude <noreply@anthropic.com>
1 parent 42ff86f commit c5ddbea

17 files changed

Lines changed: 2911 additions & 12 deletions
Lines changed: 197 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,197 @@
1+
# DocuSign eSignature
2+
3+
Send documents out for signature, read envelopes and follow their signature
4+
status from your flows. The app calls DocuSign's eSignature REST API in the
5+
DocuSign **developer sandbox** (`https://demo.docusign.net/restapi`) through a
6+
connector built from DocuSign's own OpenAPI document, and exposes three
7+
envelope operations as connector actions. It signs in to DocuSign with OAuth,
8+
using an integration key your administrator registers for your deployment:
9+
the app carries no key of anyone's.
10+
11+
## What it adds
12+
13+
- **A connector, `docusign`.** Its actions are DocuSign's own operation ids:
14+
15+
| Action | Request | What it does |
16+
|:---|:---|:---|
17+
| `Envelopes_PostEnvelopes` | `POST /v2.1/accounts/{accountId}/envelopes` | Creates an envelope; with `status: "sent"` DocuSign emails it to the signers at once |
18+
| `Envelopes_GetEnvelope` | `GET /v2.1/accounts/{accountId}/envelopes/{envelopeId}` | Reads one envelope, its `status` included |
19+
| `Envelopes_GetEnvelopes` | `GET /v2.1/accounts/{accountId}/envelopes` | Lists envelopes, for example those whose status changed since `from_date` |
20+
21+
No other DocuSign operation is in the package, so none can reach your flows
22+
or agents.
23+
- **An object, `docusign_envelope`**, one record per envelope the app sent:
24+
`envelope_id` (DocuSign's envelope id), `signature_status` (DocuSign's own
25+
status word: `sent`, `delivered`, `completed`, `declined`, `voided`, …),
26+
`email_subject` and `status_changed_at`. The status is DocuSign's, mirrored
27+
each time a flow below reads it. Its list view, **DocuSign Envelopes**,
28+
shows the newest status change first.
29+
- **Three flows that use them**, ready to run or to copy:
30+
- `docusign_send_envelope` takes `account_id`, `email_subject`,
31+
`document_name` (for example `contract.pdf`), `document_base64`,
32+
`signer_name` and `signer_email`, sends the document to that signer and
33+
records the envelope. DocuSign's answer is the run's `send.body` output.
34+
- `docusign_get_envelope` takes `account_id` and `envelope_id`, reads the
35+
envelope and refreshes its record's `signature_status`. DocuSign's
36+
envelope is the run's `envelope.body` output.
37+
- `docusign_poll_status_changes` takes `account_id` and `from_date` (an ISO
38+
8601 instant), lists the envelopes whose status changed since then (at
39+
most 100) and copies each status onto its record. DocuSign's list is the
40+
run's `changes.body` output. See [Callbacks](#callbacks) for why this
41+
poll exists.
42+
43+
`account_id` is your DocuSign account's API account id (a GUID): in the
44+
DocuSign developer console it is **API Account ID** on **Apps and Keys**.
45+
46+
An install adds the connector, the object, its list view and the three
47+
flows, and nothing else: no sample data and no demo users.
48+
49+
## Credentials
50+
51+
The app needs one OAuth client, which **you register with DocuSign for your
52+
own deployment**. ObjectStack ships none: a DocuSign OAuth client is an
53+
integration key that accepts only the redirect URIs registered on it, and the
54+
redirect URI belongs to your deployment. Until an administrator connects the
55+
`docusign` connector, it is listed as degraded "not connected" and its flows
56+
fail, naming the connector.
57+
58+
| What | What it is | Where to get it |
59+
|:---|:---|:---|
60+
| Integration key | DocuSign's client id for your app (a GUID) | DocuSign developer console (<https://admindemo.docusign.com/apps-and-keys>) → **Apps and Keys** → **Add App and Integration Key** |
61+
| Secret key | The client secret DocuSign issues for that integration key, shown once | The same app → **Authentication** → **Add Secret Key** |
62+
| Redirect URI | Your deployment's OAuth callback, which DocuSign must accept | The connector's connection read (below); register it on the same app under **Additional settings** → **Redirect URIs** |
63+
64+
1. Read your deployment's redirect URI. It is your deployment's origin plus
65+
`/api/v1/automation/connectors/oauth/callback`, and the server answers the
66+
exact value, before any client exists, as `redirectUri` of
67+
`GET /api/v1/automation/connectors/docusign/connection`; the Console's
68+
**Connect** dialog (step 3) shows the same value. Use that answer, never
69+
your browser's address bar: behind a proxy, or when `OS_AUTH_URL` /
70+
`OS_BASE_URL` name another origin, the two differ.
71+
2. In the DocuSign developer console, add an app and integration key, choose
72+
**Authorization Code Grant**, add a secret key, and add the redirect URI
73+
from step 1. The app needs the `signature` scope, which is DocuSign's
74+
default for the authorization code grant.
75+
3. Connect the connector: on **Setup → Integrations → Connector Connections**,
76+
choose **Connect** on `docusign` and enter the integration key and the
77+
secret key; or begin the connect yourself with
78+
`POST /api/v1/automation/connectors/docusign/connection` and a body of
79+
`{ "clientId": "<integration key>", "clientSecret": "<secret key>" }`, then
80+
open the `authorizationUrl` it answers. Sign in to DocuSign and allow
81+
access; DocuSign returns to your redirect URI and the connection is
82+
stored.
83+
84+
Connecting takes the organization-scoped `manage_connector_connections`
85+
capability (organization owners and admins hold it), from a signed-in
86+
session; an agent or an API key is refused. Each organization connects once.
87+
The platform keeps the integration key and its secret encrypted on the
88+
organization's connection, shows the key but never the secret, and uses them
89+
for the authorization, the code exchange and every token refresh. A reconnect
90+
that names no client reuses the stored one; disconnecting removes it.
91+
92+
The token is only ever sent to DocuSign. Neither it nor your secret key is
93+
stored in the app's metadata.
94+
95+
## Running it
96+
97+
```bash
98+
curl -X POST "$OS_URL/api/v1/automation/docusign_send_envelope/trigger" \
99+
-H "Authorization: Bearer $SESSION_TOKEN" -H 'Content-Type: application/json' \
100+
-d '{"params": {"account_id": "<API account id>", "email_subject": "Please sign the contract",
101+
"document_name": "contract.pdf", "document_base64": "<the PDF, base64>",
102+
"signer_name": "Ada Lovelace", "signer_email": "ada@example.com"}}'
103+
```
104+
105+
To use an answer elsewhere, add a `connector_action` node with
106+
`connectorId: 'docusign'` to your own flow and read `<nodeId>.body` in a later
107+
node. An action takes its path parameters as one `path` object, its query
108+
parameters as one `query` object and its request body as one `body` value,
109+
for example
110+
`path: { dialect: 'cel', source: '{"accountId": record.docusign_account_id, "envelopeId": record.envelope_id}' }`.
111+
112+
A contract app that follows its own records' signatures keeps the same two
113+
fields on its record (`envelope_id`, `signature_status`) and copies them from
114+
the `docusign_envelope` record, or from the action's answer, in its own flow.
115+
116+
A DocuSign error answer does not fail the step: it lands as
117+
`<nodeId>.status`, `<nodeId>.ok` false and DocuSign's error in
118+
`<nodeId>.body`. The three flows check `ok` and write no record when DocuSign
119+
refused the call.
120+
121+
## Callbacks
122+
123+
DocuSign can post envelope events to a URL you name (DocuSign Connect). This
124+
app does **not** take those posts, and you should not point Connect at a
125+
deployment's `api` flow door: Connect signs each post with its own HMAC
126+
header, and the `api` door verifies only the platform's own signature
127+
scheme, so a Connect post cannot be told from a forged one there. Until the
128+
platform verifies vendor callback schemes, follow status changes by polling:
129+
run `docusign_poll_status_changes` on a schedule, passing the time of the
130+
previous run as `from_date`, or `docusign_get_envelope` for one envelope.
131+
132+
## Limits
133+
134+
- **Sandbox only.** The connector points at DocuSign's developer environment:
135+
sign-in at `account-d.docusign.com`, API calls at `demo.docusign.net`. A
136+
production DocuSign account signs in at `account.docusign.com` and has an
137+
API host of its own (DocuSign answers it as `base_uri` from
138+
`/oauth/userinfo`), which this package cannot name for you; production is
139+
not supported yet.
140+
- One document and one signer per `docusign_send_envelope` run. The action
141+
itself takes DocuSign's whole envelope definition; copy the flow to send
142+
more.
143+
- `docusign_poll_status_changes` reads one page of at most 100 changed
144+
envelopes. Poll often enough that one page covers the interval.
145+
- Not measured live: the tests run against a fake DocuSign. A round trip
146+
against the DocuSign sandbox (connect, send, read, poll) is owed to the
147+
acceptance run, and the DocuSign console steps under Credentials follow
148+
DocuSign's documentation.
149+
- The request body and response schemas in the packaged document are not
150+
expanded (see Provenance): `Envelopes_PostEnvelopes` takes DocuSign's
151+
envelope definition as one JSON object, described by its type and
152+
description only, so its fields are DocuSign's documented ones (the
153+
`docusign_send_envelope` flow shows the minimal set). The answer itself is
154+
DocuSign's full JSON.
155+
156+
## Provenance
157+
158+
`openapi/docusign-esignature.openapi.json` is generated, not written by hand.
159+
It is DocuSign's eSignature REST API document,
160+
`docusign/OpenAPI-Specifications` `esignature.rest.swagger-v2.1.json` at
161+
commit `858a3ae59b0edbc8beea4fa3a6d7fe803833dd68` (Swagger 2.0, 414
162+
operations), converted to OpenAPI 3.0 and trimmed to the three operations
163+
above by this repository's offline normalizer:
164+
165+
```bash
166+
pnpm --filter @objectstack/connector-openapi normalize-openapi \
167+
--in https://raw.githubusercontent.com/docusign/OpenAPI-Specifications/858a3ae59b0edbc8beea4fa3a6d7fe803833dd68/esignature.rest.swagger-v2.1.json \
168+
--include-pattern '^Envelopes_(PostEnvelopes|GetEnvelope|GetEnvelopes)$' \
169+
--trim --empty-consumes application/json --max-depth 0 \
170+
--out packages/apps/connector-docusign/openapi/docusign-esignature.openapi.json
171+
```
172+
173+
It printed OpenAPI 3.0.4, 304,080 bytes, 3 operations trimmed from 414, 187
174+
empty `consumes` lists filled with `application/json`, 7 schema references cut
175+
at `--max-depth 0` and none left, and sha256
176+
`b741ded5cfc4d0291d7f0e26559f8583f8c9a783f8711d8f9a98405cb27f7cb4`, the hash
177+
of the committed file. The package's tests recompute that hash and fail when
178+
the file and this record disagree.
179+
180+
`--max-depth 0` keeps every parameter schema as DocuSign wrote it, and
181+
replaces each named schema (the envelope definition the create operation
182+
takes, and each response) with its type, title and description. At the
183+
default depth of 2 the same three operations write 553,922 bytes (sha256
184+
`e1051eb4bbc381d879e979beac8cb64ead24531c93a19fc26e950a12d9fc961d`), with the
185+
envelope definition's fields expanded two levels.
186+
187+
`--empty-consumes application/json` is required: DocuSign's document clears
188+
the request media type on its operations (`consumes: []`), which would leave
189+
`Envelopes_PostEnvelopes` with no request body at all. The document's
190+
`servers[0].url` is DocuSign's production host,
191+
`https://www.docusign.net/restapi`; the connector's `providerConfig.baseUrl`
192+
points it at the sandbox instead. The document declares no security scheme,
193+
so the OAuth token is sent on every operation.
194+
195+
Re-normalize from a newer commit by running the command with that commit,
196+
then update the commit and the sha256 here in the same change. DocuSign's
197+
document is MIT-licensed; its licence notice is `openapi/LICENSE`.
Lines changed: 7 additions & 0 deletions
Loading
Lines changed: 46 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,46 @@
1+
// Copyright (c) 2026 ObjectStack. Licensed under the Apache-2.0 license.
2+
3+
import { defineStack } from '@objectstack/spec';
4+
import { ConnectorOpenApiPlugin } from '@objectstack/connector-openapi';
5+
import { DocuSignConnector } from './src/connectors/docusign.connector.js';
6+
import { DocuSignEnvelope } from './src/objects/docusign-envelope.object.js';
7+
import { DocuSignEnvelopeViews } from './src/views/docusign-envelope.view.js';
8+
import { allFlows } from './src/flows/docusign.flows.js';
9+
10+
/**
11+
* DocuSign eSignature connector app — open edition (every key it uses runs on
12+
* the open tier), so it lives in this repository and is validated by its CI
13+
* against the runtime at HEAD. One declarative connector over DocuSign's own
14+
* OpenAPI document, authorized by OAuth with the OAuth client each
15+
* deployment's administrator registers (ADR-0143 D2.1, `clientSource:
16+
* 'installer'`), one object that keeps each envelope's signature status (and the
17+
* list view that shows it), and three flows that use them; no secret and no client of anyone's. The
18+
* listing is `objectstack.manifest.json`, and the README is what the
19+
* administrator reads before installing.
20+
*/
21+
export default defineStack({
22+
manifest: {
23+
id: 'app.objectstack.connector-docusign',
24+
namespace: 'docusign',
25+
version: '0.1.0',
26+
type: 'app',
27+
name: 'DocuSign eSignature',
28+
description: 'Send documents for signature, read envelopes and follow their signature status from flows, over DocuSign\'s eSignature OpenAPI document (developer sandbox).',
29+
engines: { protocol: '^18' },
30+
},
31+
32+
// `automation` materializes the `connectors:` entry at boot, serves the
33+
// connection door an administrator connects it through, and runs the
34+
// flows; the executor below registers the `openapi` provider with it.
35+
requires: ['automation'],
36+
37+
// The generic `openapi` executor, zero-arg: it contributes the provider
38+
// factory only, which reads the packaged document through the host's
39+
// package-file capability (confined to this package's root).
40+
plugins: [new ConnectorOpenApiPlugin()],
41+
42+
objects: [DocuSignEnvelope],
43+
views: [DocuSignEnvelopeViews],
44+
connectors: [DocuSignConnector],
45+
flows: allFlows,
46+
});
Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,14 @@
1+
{
2+
"$schema": "https://schemas.objectstack.dev/template-manifest.json",
3+
"manifestId": "app.objectstack.connector-docusign",
4+
"name": "connector-docusign",
5+
"specVersion": "^18.0.0",
6+
"displayName": "DocuSign eSignature",
7+
"description": "Send documents for signature, read envelopes and follow their signature status from flows, over DocuSign's eSignature OpenAPI document. Developer sandbox; your administrator registers their own DocuSign integration key.",
8+
"category": "productivity",
9+
"tags": ["docusign", "esignature", "openapi", "connector", "oauth"],
10+
"license": "Apache-2.0",
11+
"iconUrl": "https://raw.githubusercontent.com/objectstack-ai/objectstack/main/packages/apps/connector-docusign/assets/icon.svg",
12+
"homepageUrl": "https://github.com/objectstack-ai/objectstack/tree/main/packages/apps/connector-docusign",
13+
"readmePath": "README.md"
14+
}
Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,22 @@
1+
The MIT License
2+
3+
Copyright (c) 2017- DocuSign, Inc. (https://www.docusign.com)
4+
5+
Permission is hereby granted, free of charge, to any person obtaining a copy
6+
of this software and associated documentation files (the "Software"), to deal
7+
in the Software without restriction, including without limitation the rights
8+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9+
copies of the Software, and to permit persons to whom the Software is
10+
furnished to do so, subject to the following conditions:
11+
12+
The above copyright notice and this permission notice shall be included in all
13+
copies or substantial portions of the Software.
14+
15+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21+
SOFTWARE.
22+

0 commit comments

Comments
 (0)