fix: correct destination auth config and add --include-destination-auth flag

[leggetter]

Summary

• Fix destination auth config structure: The CLI was sending destination authentication credentials under an auth_method key, but the API expects auth_type (string) and auth (credentials map) as separate fields inside destination.config. This affected all auth types (OAuth2, AWS Signature, GCP Service Account).
• Add --include-destination-auth flag to connection get: The connections API does not support include=config.auth, so this flag fetches the destination directly via GET /destinations/{id}?include=config.auth and merges the enriched config back into the connection response.
• Strengthen acceptance tests: Tests now verify credentials are actually stored by doing a connection get --include-destination-auth after creation, asserting specific credential values for all four auth types.

Details

Auth config fix (buildDestinationConfig)

The buildDestinationConfig() function was wrapping all auth fields under config.auth_method, but the API expects:

• config.auth_type — the auth type string (e.g. AWS_SIGNATURE)
• config.auth — a map of the credential values

--include-destination-auth flag

The include=config.auth query parameter is only supported on GET /destinations/{id} and GET /sources/{id} (confirmed via OpenAPI spec). It is not supported on any /connections endpoint. The CLI works around this by making a supplementary GET /destinations/{id}?include=config.auth call when the flag is set.

Note: POST /connections response redaction

When creating a connection with inline destination auth, POST /connections correctly stores the credentials but redacts them in the response (returns auth: {}). A standalone POST /destinations returns them in full. This is a separate API inconsistency — a repro script (test/repro-connection-auth-bug.sh, not committed) was used to verify this.

Test plan

• All unit tests pass (go test ./pkg/...)
• All four acceptance tests pass (TestConnectionOAuth2AWSAuthentication): OAuth2 Client Credentials, OAuth2 Authorization Code, AWS Signature, GCP Service Account
• Each test creates a connection, verifies auth_type in the create response, then does connection get --include-destination-auth to verify credentials were stored
• Manual verification: hookdeck connection get <id> --include-destination-auth --output json returns full auth credentials

Made with Cursor