AI Chatbot HubSpot Integration: Contacts, Deals and Transcripts Written Correctly

Start here: HubSpot’s own chat tools, or an AI bot that writes into HubSpot?

HubSpot ships its own chat and bot tooling, with more AI features on some subscription tiers. Anything built there lands in the CRM and the conversations inbox without an integration to maintain. If it covers what you need, use it, and we will say so in the consultation.

A custom AI chatbot that writes into HubSpot earns its extra moving parts when at least one of these is true:

• Answers depend on data HubSpot’s bot cannot reach, such as your pricing rules, service areas, product specifications or a line-of-business database.
• The same conversation must act on other systems, for example checking availability, drafting a quote or opening a support record elsewhere, and then logging the result in HubSpot.
• The bot runs in more than one place, such as several websites, a customer portal or an internal app.
• You want control of the model, the prompts and the guardrails, including exactly what the bot may and may not say.

EVOTECH is an independent developer working against HubSpot’s public APIs. We are not a HubSpot partner and do not present ourselves as one. Everything below describes how the integration is built from the outside, and platform details are confirmed against HubSpot’s current documentation during scoping.

The first fork: submit a HubSpot form, or write CRM objects directly

HubSpot accepts data from outside in two very different ways, and the choice shapes attribution, workflows and deduplication.

In practice we often use both. The form submission creates or updates the contact with proper attribution and fires your existing form workflows. The CRM API then adds the deal, the transcript note and any follow-up task. Order matters, because form submissions are processed asynchronously and the contact can take a moment to appear. The second step looks the contact up and retries briefly rather than assuming it already exists.

The tracking cookie and consent

The hubspotutk value exists only when HubSpot’s tracking code runs on the page and the visitor has accepted tracking cookies. If they declined, the widget sends none, the contact is created without browsing history, and that is the correct outcome. We never try to work around a declined cookie banner.

Matching returning visitors without exposing their records

HubSpot treats email as the unique key for contacts. Creating a contact whose email already exists fails with a conflict, and the error identifies the existing record. There are two clean ways to handle it: an upsert that uses email as the identifying property, or a search followed by an update. Either way, the conversation attaches to the person you already know rather than spawning a twin.

Search is not instant

HubSpot’s search index trails record creation slightly. A contact created a few seconds ago may not appear in search results yet, which is a classic cause of duplicates when a visitor submits twice in quick succession. Our backend keeps its own short-lived map of email to contact ID for records it just created, so it does not depend on search in that window.

Lookup is for writing, not for answering

Anyone can type someone else’s email address into a chat. So the bot uses a HubSpot lookup only to decide where to write, never to tell the visitor what the CRM holds. “Your last quote was for…” or “I see you spoke to Maria in March” requires proof of identity first, such as a one-time code sent to that email or a logged-in portal session.

Which properties the bot may change

Lifecycle stage deserves care. HubSpot moves it forward readily but will not move it backward through the API unless the value is cleared first, so our code only ever sets a later stage than the current one. Check too how your account classifies contacts created by integrations as marketing or non-marketing, since that status can affect your HubSpot billing.

Creating deals: pipelines, stage IDs and associations

Not every chat is a deal. We write the qualification rule down with you before any code exists, for instance: a deal is created only when the visitor names a specific project, gives a rough timeframe and agrees to be contacted. Everything else becomes a contact and a note.

Labels are for people; IDs are for code

Pipeline and deal stage properties take internal identifiers, not the labels shown on the board. HubSpot’s default pipeline uses readable internal values such as “default” for the pipeline and “appointmentscheduled” for a stage, while custom pipelines and stages receive generated numeric IDs. Anyone can rename a stage in settings without changing its ID. So the backend reads the pipelines API at startup, confirms each configured stage still exists, and raises an alert if one has been deleted rather than guessing.

What the bot writes on a deal

• Deal name built from the service and the contact’s name or company.
• Pipeline and stage by internal ID, usually the first stage of the relevant pipeline.
• Owner when your routing rules can assign one (more on that below).
• Amount left empty. A chatbot should not invent a deal value from a casual conversation; your team fills it after scoping.

Associations

A deal that is not associated with its contact is nearly invisible in daily use. We create the association in the same request that creates the deal, using the association type identifiers from HubSpot’s associations API, and verify it in testing. One more trap: if your account automatically creates and associates companies from email domains, the bot must not also create companies itself, or every chat from a new domain yields two identical company records.

Where the conversation lands: notes, owners and follow-up tasks

The transcript as a note

Each conversation is saved as a note engagement associated with the contact and, where one exists, the deal. The note opens with a structured summary (what they need, when, constraints, anything relevant to pricing) followed by the trimmed transcript. Before anything is sent, a redaction pass removes patterns that should never sit in a CRM, such as card numbers someone pasted into the chat window.

Owner assignment

If HubSpot workflows already rotate or route new leads, we leave assignment to them and simply write the properties those workflows read. That keeps routing logic in one place your team can see and edit. Where no such workflow exists, the backend can set the owner property from HubSpot’s owners list using rules you define, such as service line or territory.

Promises need tasks

If the bot tells a visitor “someone will call you tomorrow,” there must be a HubSpot task, assigned and due, that makes it true. We either create that task along with the note, or phrase the bot’s reply without a time commitment. A promise with no task behind it is how a good lead goes cold.

Authentication: a single-account token or an OAuth app

HubSpot retired its old account-wide API keys, so every integration now authenticates with an access token. Two patterns cover nearly every chatbot project:

• One HubSpot account: a private-app style integration created inside your portal issues a token limited to the scopes selected. HubSpot has been reorganising its developer app types, so the current name and setup screen are confirmed at build time.
• A product installed into many accounts: a public OAuth app with refresh tokens, where each customer authorises the connection separately.

We ask only for what the bot needs: read and write on contacts and deals, and whatever the notes, tasks and owners endpoints require, named exactly from HubSpot’s scope list. No settings, files or user-management scopes. The token lives in the server’s secret store, never in the widget’s JavaScript, with a written rotation procedure and a list of who can view it.

Hearing back from HubSpot

Some projects need the bot to react to CRM changes, such as sending a follow-up once a deal reaches a stage. That comes either from webhook subscriptions on the app or from a workflow webhook action, depending on your tier. Every inbound call is checked against HubSpot’s request signature header before it is trusted.

Rate limits, error codes and what the visitor never sees

HubSpot enforces short burst limits and daily limits that vary with your subscription and app type, and its search endpoint has a tighter limit of its own. Ordinary chat volume rarely approaches them, but a traffic spike or a bulk backfill can. The design principle: the visitor’s conversation never waits on HubSpot.

Every CRM write goes first into an outbox table on our side, then a worker delivers it and marks it complete. Responses are handled by type:

• 429, too many requests: back off and retry later; nothing is lost.
• 409 conflict on a contact: take the existing contact’s ID and carry on.
• 400 on a property: usually a drop-down value that is not one of the property’s options. The value moves into the note, the rest of the write proceeds, and an alert names the property.
• 401 or 403: the token was revoked or lost a scope. Writes stay queued, and someone on your side is alerted immediately.

A small status view lists anything stuck in the outbox so your team can see a failed write rather than discover it through a missed lead.

Testing against a HubSpot account that is not production

HubSpot offers developer test accounts, and some Enterprise subscriptions include sandboxes that mirror your properties and pipelines. We use whichever you have. If neither is available, we test in production with clearly tagged test contacts and delete them afterwards. The scenarios we run:

1. A brand-new visitor who becomes a contact, a note and a deal.
2. A returning email that must attach to the existing contact.
3. The same email submitted twice within seconds.
4. A visitor who declined tracking cookies, so no hubspotutk value arrives.
5. A drop-down answer that does not match any option.
6. A deal stage deleted from the pipeline after launch.
7. A contact whose lifecycle stage is already Customer.
8. A transcript containing a pasted card number, to prove redaction.
9. A revoked token, to prove queuing and alerting.

EVOTECH’s delivery sequence for a HubSpot-connected bot

1. Free consultation by phone or video, including an honest look at whether HubSpot’s own tools already do the job.
2. Portal review: properties, pipelines, lifecycle rules, existing workflows, company auto-creation and your cookie-consent setup.
3. Written mapping of every property the bot writes, with its overwrite policy and qualification rule.
4. Fixed-scope written quote.
5. Build and test against a test account or sandbox using the scenarios above.
6. Launch with the outbox view and alerts on, then a review of the first real contacts and deals with your team.

Twenty-plus years in business and a 5.0 Google rating sit behind EVOTECH IT LLC, which works with businesses anywhere in the country over phone and video, from a US-based team near Houston. If your CRM is not HubSpot, see AI chatbot CRM integration or the Salesforce integration page. Bots that also take actions across other systems are covered under AI agents.

Related services

Frequently asked questions