feat(pipes)!: Support organization-owned and multiple connections

[dandorman]

Description

Bring Pipes up to date with organization-owned connections, multiple connections per provider, and API-key/client-credentials integrations without letting regeneration undo existing SDK behavior.

• Thread ownership, account selectors, provider config, and plural-connection opt-in through the public options and wire serializers.
• Add organization integration/account operations and client-credentials rotation; deserialize all credential variants, including client-credentials metadata.
• Adopt the credential component from workos/workos#73671 while retaining published DTO/type/serializer names and common property-access patterns through compatibility shims.
• Preserve and protect the manual DELETE query correction until the Node emitter fix is available; remove an unused conflicting interface and make generation ownership explicit.

Compatibility and release impact

This is intentionally marked as a breaking SDK type change, not an HTTP wire-contract change:

• DataIntegration.credentials can be null for non-OAuth integrations; consumers must check it before reading OAuth application credentials.
• Credential responses now describe active/inactive outcomes and authentication-method variants accurately. Typed mocks must include the matching discriminator and fields; API-key credentials do not expose OAuth scope/expiry fields.
• Expanded authentication-method/state unions may require updates to exhaustive switches. Custom types extending the old credential interfaces need intersections with the new unions.

Existing method names, published DTOs, and credential type/serializer imports remain available. Reads such as result.error and result.credential?.value still compile. The new organization integration methods were not previously released.

Plural connections remain opt-in: omitted/false supportsMultipleConnections keeps compatibility-slot behavior. Legacy provider ownership: 'userland_user' remains available; new code can use connectionOwner: 'user'. See Pipes compatibility and migration notes.

Keep the breaking-change marker when squash-merging. With the repository's default release-please configuration, this requests a major release. No changelog or package-version files are manually changed here.

Validation

Rebased onto current main (4c12d5a1, release 10.14.0) and ran locally:

• npm run typecheck
• npm run lint
• npm run prettier, plus formatting checks for changed JSON/Markdown files
• npm run build (including the package type/export checks)
• npm test -- --runInBand: 1,112 passed, 12 skipped, 17 snapshots passed

Coverage includes request bodies/query parameters, true/false/omitted plural opt-ins, pagination filters, credential variants, metadata, date conversion, and compatibility aliases. A temporary regeneration also preserved the protected DELETE methods and credential compatibility shims. The old package tarball and build-generated metadata changes are excluded.

Documentation

• Yes — the related API schema/reference change is merged in https://github.com/workos/workos/pull/73671.
• SDK-specific migration and generation-boundary guidance is included in docs/PIPES_COMPATIBILITY.md.
• The known generated-docs optionality/nullability presentation issue is deferred to a separate docs-parser PR.

BREAKING CHANGE: Integration credentials may be null, and credential responses now reflect active/inactive and authentication-method variants. Consumers relying on non-null OAuth credentials, unconditional token fields, or the former flat credential interfaces must update their types and guards as described in the compatibility guide.

[greptile-apps]

Confidence Score: 5/5

[High risk] Expands data integration API types and adds organization-owned connections.

The PR appears safe to merge; no new actionable issue or outstanding previous finding remains.

Summary

The PR adds organization-owned and multiple Pipes connections, API-key and client-credentials flows, and credential response variants while retaining compatibility exports and protecting hand-maintained code from regeneration. The change since the previous review clarifies the API dependency for idempotent POST retries.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A[Integration and ownership] --> B[Create or select connection]
  B --> C[OAuth, API key, or client credentials]
  C --> D[Vend credential]
  B --> E[Compatibility connection]
  B --> F[Plural connections when opted in]

Loading

_{Reviews (4) · Last reviewed commit: "docs(pipes): Clarify idempotency-key not..."}