CXP-2212: document C1 redirect URI and integration key classification - #70
Conversation
Setup docs told every reader to enter an arbitrary redirect URI, which only works for the self-hosted flow. Cloud-hosted (demo environment) setups need C1's actual OAuth callback registered on the DocuSign app or the authorization request is rejected. The integration key classification choice, which affects billing and can't be changed later, also had no guidance.
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
luisina-santos
changed the title
Connector PR Review: CXP-2212: document C1 redirect URI and integration key classificationBlocking Issues: 0 | Suggestions: 1 | Threads Resolved: 0 Review SummaryThe new commit rewrites only the integration-key classification paragraph in Security IssuesNone found. Correctness IssuesNone found. Suggestions
Prompt for AI agents |
The self-hosted redirect URI is not unused — DocuSign does redirect the browser there and sends it as redirect_uri in the token exchange, so the registered value must match --redirect-uri/BATON_REDIRECT_URI.
| You'll be asked to classify the integration key. This choice affects production billing and [can't be changed later](https://developers.docusign.com/platform/go-live/#ik-classifications): | ||
| - Choose **Private custom integration** if this app will only be used internally by your organization — the typical case for a self-hosted connector. | ||
| - Choose **Third-party integration key** if you're using this app with C1's **Custom App (Demo Environment)** field group and connecting third-party (C1) infrastructure to your DocuSign account. |
There was a problem hiding this comment.
🟡 Suggestion: This ties DocuSign's integration key classification to the C1 hosting mode, but the two aren't the same axis. DocuSign's classification is about who owns/distributes the integration; in the Custom App (Demo Environment) flow the key is still created in and used against the customer's own DocuSign account, which reads as a private/internal integration even though C1 drives the OAuth flow. Also note that field group targets account-d.docusign.com only (see line 138 and pkg/client/oauth.go:15), so recommending a permanent classification that "affects production billing" for a demo-only key is worth double-checking against DocuSign's actual prompt wording. (Medium confidence — I can't verify DocuSign's UI labels from this repo.)
| In the **Redirect URI** field, enter any URI of your choice (such as http://example.com/callback) and click **Add**. | ||
| In the **Redirect URI** field: | ||
| - If you're configuring a **self-hosted** connector, enter any URI of your choice (such as http://example.com/callback) and click **Add**. Nothing needs to be listening at that address — the `--configure` flow prints an authorization URL, and after you authorize, DocuSign redirects your browser there; copy the `code` parameter from the resulting (unreachable) URL and paste it when prompted. Whatever value you register here must also be passed as `--redirect-uri` / `BATON_REDIRECT_URI`, or the authorization and token exchange will fail. | ||
| - If you're configuring a **Cloud-hosted (demo environment)** connector, enter `https://accounts.conductor.one/oauth/callback` and click **Add**. C1 completes the OAuth flow through this URL; DocuSign rejects the authorization request if it isn't registered here. |
There was a problem hiding this comment.
🟡 Suggestion: https://accounts.conductor.one/oauth/callback appears nowhere else in this repo (redirect-uri is ExportTargetCLIOnly in pkg/config/config.go:32-37, so the cloud-hosted path never passes it through the connector), which means this exact string can't be verified here. If it doesn't match the redirect URI C1's platform actually sends, DocuSign rejects the authorization and setup fails at the last step. Worth confirming the literal value with the platform team (and whether it varies by environment/region) before merging. (Medium confidence.)
The prior wording split the classification choice cleanly by hosting mode, but DocuSign's classification is about who owns/distributes the app, not who runs the connector -- the key is created and used against the customer's own account in both cases. State it as DocuSign's own criteria plus a case worth double-checking, not a rule.
2 participants
Summary
Related: CXH-2212. Note the CLM opt-in gap that ticket also flagged is already fixed on
main— only these two gaps remained.Test plan