fix(generated): Changes to multi_factor_auth

[workos-sdk-automation]

Summary

fix(multi_factor_auth): Change errors for endpoint POST /auth/factors/{id}/challenge

• Changed errors for endpoint POST /auth/factors/{id}/challenge.

Triggered by workos/openapi-spec@949c30c

BEGIN_COMMIT_OVERRIDE
fix(multi_factor_auth): Change errors for endpoint POST /auth/factors/{id}/challenge (#732)
END_COMMIT_OVERRIDE

[greptile-apps]

Confidence Score: 4/5

The PR is not safe to merge until the Pipes provider-list endpoint preserves compatibility with its existing public response model.

Findings

1.  Pipes Response Type Changed ▶

Fix with agent prompt

### Issue 1
src/workos/pipes/_resource.py:24-28
`list_user_data_providers` now deserializes responses into the common `DataIntegrationsListResponse`, while `workos.pipes.models.DataIntegrationsListResponse` remains a separate class. Existing consumers importing the Pipes model will receive an object of a different type, so class-identity checks and related annotations can break. Re-export or alias the common implementation from the old Pipes module so both imports resolve to the same class.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

This regeneration updates the MFA challenge documentation and incorporates broader specification changes for organization data providers and Pipes.

• Adds synchronous and asynchronous organization data-provider resources.
• Adds connected-account ownership metadata, plural-connection response models, and new Pipes webhook events.
• Updates common exports, fixtures, and generated round-trip/request tests.
• Introduces a compatibility regression by returning a common response class distinct from the retained public Pipes class.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  C[WorkOSClient] --> O[OrganizationsDataProviders]
  C --> P[Pipes]
  O --> M[Common connected-account models]
  P --> M
  P --> R[Common DataIntegrationsListResponse]
  L[Legacy workos.pipes.models import] --> D[Separate response class]

Loading

_{Reviews (1) · Last reviewed commit: "chore(generated): add release notes frag..."}

[greptile-apps]

Pipes Response Type Changed

list_user_data_providers now deserializes responses into the common DataIntegrationsListResponse, while workos.pipes.models.DataIntegrationsListResponse remains a separate class. Existing consumers importing the Pipes model will receive an object of a different type, so class-identity checks and related annotations can break. Re-export or alias the common implementation from the old Pipes module so both imports resolve to the same class.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/workos/pipes/_resource.py
Line: 24-28

Comment:
**Pipes Response Type Changed**

`list_user_data_providers` now deserializes responses into the common `DataIntegrationsListResponse`, while `workos.pipes.models.DataIntegrationsListResponse` remains a separate class. Existing consumers importing the Pipes model will receive an object of a different type, so class-identity checks and related annotations can break. Re-export or alias the common implementation from the old Pipes module so both imports resolve to the same class.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.