Webhooks
Webhook support is the right pattern when customers want BidBlender to push change events outward instead of polling for them.
Likely webhook events
Opportunity created, decision state changed, connector status changed, document analysed, and assessment updated are the most obvious high-value event types.
Why webhooks matter
They let customers trigger internal workflows when new intelligence appears instead of forcing users to manually check the product.
How this fits the product story
Webhooks reinforce the idea that BidBlender is a platform and a system of intelligence, not just a static dashboard.
How this should be positioned today
Signal webhook readiness as part of the platform direction, with care around what is internal versus what is exposed for customers.
Reading the site
How BidBlender labels capability status
The public site distinguishes between what is already available, what becomes useful once data is connected, and what is still part of the product direction. That keeps the story clear without flattening everything into one vague promise.
Core product surfaces and workflows that already exist in the current BidBlender experience.
Capabilities that depend on configured data sources, integrations, or customer-specific setup.
Directionally important workflows and platform extensions that are signposted carefully, not overstated as available.