Context
The Python SDK 6.1.0 beta now has the key pieces salesagent needed for AdCP 3.1 catalog webhooks: NotificationConfig, wholesale feed webhook models, destination URL validation, and webhook sender/signing helpers.
One remaining duplicated-implementation risk is proof-of-control for durable webhook subscriptions registered through sync_accounts.accounts[].notification_configs[].
Salesagent PR #561 implemented this locally:
- validate/normalize the destination URL
- issue a
webhook.challenge POST before activating a new/changed active durable subscription
- require the receiver to echo the challenge value
- allow
active: false configs to be stored without a challenge
Ask
Add a Python SDK helper for durable webhook proof-of-control challenges, once the spec-level semantics are settled.
Useful surface could be something like:
result = await challenge_webhook_destination(
url=config.url,
account_id=account_id,
subscriber_id=config.subscriber_id,
authentication=config.authentication,
timeout=...,
)or a lower-level helper that builds/validates the challenge payload and response.
Related spec issue
adcontextprotocol/adcp#4979
Why it matters
Sellers implementing durable webhook registration should not each hand-roll URL validation, challenge payloads, response parsing, timeout behavior, and auth/signing behavior differently.
Context
The Python SDK 6.1.0 beta now has the key pieces salesagent needed for AdCP 3.1 catalog webhooks:
NotificationConfig, wholesale feed webhook models, destination URL validation, and webhook sender/signing helpers.One remaining duplicated-implementation risk is proof-of-control for durable webhook subscriptions registered through
sync_accounts.accounts[].notification_configs[].Salesagent PR #561 implemented this locally:
webhook.challengePOST before activating a new/changed active durable subscriptionactive: falseconfigs to be stored without a challengeAsk
Add a Python SDK helper for durable webhook proof-of-control challenges, once the spec-level semantics are settled.
Useful surface could be something like:
or a lower-level helper that builds/validates the challenge payload and response.
Related spec issue
adcontextprotocol/adcp#4979
Why it matters
Sellers implementing durable webhook registration should not each hand-roll URL validation, challenge payloads, response parsing, timeout behavior, and auth/signing behavior differently.