Hi @LRüdinger
What you’re describing is a classic two-way operational flow, and HubSpot can handle its side cleanly as long as Azure DevOps is the system that receives the webhook and pushes updates back in.
For the HubSpot > Azure DevOps direction, the usual pattern is a deal-based workflow that triggers when the stage moves to Closed Won. That workflow sends a webhook carrying the fields you need: company name, AE fields, contacts, custom implementation data, and so on. HubSpot walks through how to structure those workflow webhooks here (How to Trigger Webhooks in HubSpot Contact-Based Workflows )
Azure DevOps receives the payload, creates the work item, and stores the HubSpot record ID so it can write back later.
For the Azure DevOps > HubSpot direction, treat HubSpot as the destination API. When your implementation item hits Go-Live, Azure DevOps calls the CRM API and updates the corresponding deal’s stage or the custom field you use for implementation progress. This avoids polling and keeps both systems current. HubSpot’s CRM v3 object update structure is documented here (Accounts Dashboard | HubSpot ).
Most teams also add minimal validation on the Azure side so only meaningful state changes trigger updates back into HubSpot. If your pipeline grows more complex later or you need both systems to stay in lockstep without maintaining a mapping layer manually, Stacksync keeps HubSpot and tools like Azure DevOps aligned in real time so these cross-system stage changes land instantly. Hope this helps.