HubSpot webhooks automation for client onboarding

HubSpot webhooks automation lets you connect HubSpot to other systems without retyping data. When a deal changes in the CRM, HubSpot can send a webhook (an HTTP request carrying information about the event) to your application, which then carries out the next steps. We use this ourselves for onboarding: a new deal in HubSpot starts a process that creates the accounts needed in Microsoft 365.

Because it is an internal tool, we share the principles behind the flow rather than its configuration: how to make it secure and resilient to errors.

The problem with manual onboarding

Manual onboarding is usually a list of steps in someone’s head: create the accounts, assign licences, add users to groups, send the sign-in details, record everything in the CRM. Each step is simple, but together they make it easy to skip one or mistype an email address. The problem grows when several people close deals and each does it slightly differently.

Automation does not replace the salesperson’s decision. The technical steps are defined once, in the system, instead of being remembered by a person for every deal. The salesperson changes the deal stage in HubSpot, and the system does the rest, the same way every time.

How does the flow from deal to Microsoft 365 accounts work?

Split such a flow into four stages:

Stage	What happens	What to watch
Event in HubSpot	The deal reaches a set stage, and HubSpot sends a webhook	Send only the events the process needs
Receiving the webhook	The receiving service checks the request signature and stores the event for processing	Respond quickly, process later
Processing	Fetching the full deal data from the HubSpot API (application programming interface), creating the accounts in Microsoft 365	Every step must be safe to repeat
Recording the result	The result goes back to HubSpot, and an error reaches the team as a notification	An error must be visible to a person, not only in the logs

We run our internal tools on AWS. Our article on AWS vs on-premises hosting for web applications explains why we choose serverless services for short, event-triggered tasks.

Receiving the webhook separately from processing

The simplest webhook implementation looks like this: receive the request, create the accounts, respond. It works in a demo, but causes trouble in practice:

• Operations take time. Creating accounts and assigning licences involves several API calls, each of which may take a while or fail temporarily. The webhook sender should not wait for them to finish.
• Events repeat. Any webhook system can deliver the same event more than once, for example when a response does not arrive in time. If every call creates the accounts from scratch, you get duplicates.
• Errors can be partial. When three steps succeed and the fourth fails, you need to know where to resume.

That is why receiving should be separate from processing. The service that receives the webhook only checks the signature, stores the event and responds at once. Processing happens separately, step by step. Each step first checks whether it has already been done (for example, whether an account with that address already exists). This property is called idempotency: running a step again gives the same result and does not create a second account.

How do you secure the address that receives webhooks?

The address HubSpot sends webhooks to is public. Without safeguards, anyone who learns it can trigger onboarding. The minimum we consider mandatory:

1. Check the signature. HubSpot signs its requests. In the newer version (v3), the signature is an HMAC SHA-256 computed from the app secret, the method, the address, the request body and a timestamp. HubSpot recommends rejecting requests older than 5 minutes (validating requests in the HubSpot documentation, as of 6 November 2026). Note that requests from the webhook action in workflows are signed with the older version (v2), so check which one you handle.
2. Fetch the deal details from the HubSpot API. Treat the webhook body only as a signal that something has changed. Then even a forged request body cannot decide which accounts are created.
3. Grant the least privilege needed. The HubSpot token should have access only to the objects the process needs. Permissions on the Microsoft 365 side should cover only the operations the process performs.
4. Keep secrets out of the code. Keys and secrets belong in a secrets management service, not in the repository or hard-coded.

Other HubSpot integrations in our tools

Onboarding is not the only integration in our internal tools. We also send data from Fakturownia (a Polish invoicing service) to HubSpot, pull time reports from Jira and fetch company data from the Polish National Court Register (KRS). All of them connect programs that would otherwise need data moved between them by hand.

These projects taught us a few lessons that we apply to the system integration work we do for clients:

• Start with the one process that causes the most trouble, not with “integrating everything with everything”.
• Decide which system is the source of truth for each field. If a company address can be changed in two places, a month later you will have two different addresses.
• Plan error handling from the start. An integration without error notifications that “usually works” is worse than a manual process, because nobody knows when it stopped working.
• Record what the integration did. An event history answers the question “why was this account created?” without searching the logs.

What automated onboarding changed

The main goal was quality. Onboarding should not depend on who closed the deal and whether they remembered every step. Accounts are created to the same pattern every time, and an error at any step reaches a person instead of getting lost in the logs.

When does such automation make sense for your company?

Integration through webhooks pays off when the same sequence of steps repeats regularly, the steps are clearly defined and both systems have an API. If the process is rare, or every case looks different, start with a checklist in the CRM instead. Signing in to your own application with a Microsoft 365 work account is a different case, which needs a different integration: single sign-on with Microsoft Entra ID.

If someone in your company retypes data between the CRM and other programs every day, describe the process to us. We will assess whether it can be automated and how much work it would take.