Connecting SendGrid to HubSpot: events, and what they mean

Two systems end up holding email: one sends it and one records who somebody is. Connecting them is usually framed as getting email activity into the CRM, which is worth doing — provided the events that arrive are understood, because several of them do not mean what their names suggest.

The other half is suppression. Two systems each holding their own idea of who must not be contacted is how a customer who unsubscribed receives another email, and that is the failure that has consequences beyond tidiness.

What we'll cover

• Which system is doing what
• What each event actually means
• Bounces are two different problems
• Building it with CodeWords
• Suppression must agree across both
• What belongs in the CRM
• Domains, and why they should be separate
• Reporting deliverability where somebody sees it
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Which system is doing what

Transactional email usually goes through the sending platform — receipts, resets, notifications — triggered by your application.

Marketing email usually goes through the CRM, where the lists and the consent live.

Both produce events, and only one of them is visible in the CRM by default.

Decide which sends what, explicitly, since the ambiguous middle — a lifecycle email that is arguably both — is where duplicates come from.

One consent record, wherever it lives, consulted by both.

Do not send the same thing from both. It happens more than people expect and the recipient sees it immediately.

What each event actually means

Delivered means the receiving server accepted it. Not that it reached an inbox, and not that it avoided a spam folder.

Open is unreliable. Privacy features prefetch images, which registers opens nobody performed, and blocked images suppress genuine ones.

Click is the strongest engagement signal available and is still affected by security scanners following links automatically.

Spam report is the serious one and should reach a person, not a dashboard.

Deferred is temporary and normal; treating it as a failure produces false alarms.

Dropped means your own platform did not send it, usually because the address was already suppressed — which is informative and is frequently misread as a delivery failure.

Bounces are two different problems

A hard bounce is permanent: the address does not exist. Suppress it immediately and mark the contact.

A soft bounce is temporary: a full mailbox, a server problem, a rate limit. Retrying is appropriate.

Repeated soft bounces become hard in effect, and need a threshold rather than infinite patience.

A bounced address in a CRM is a data quality problem, not only a sending one — the contact record is wrong and somebody should know.

Tell the owner for a bounced address on an account that matters, since a bouncing address on an active customer is usually somebody who left the company.

Track the bounce rate by source, because a list segment or a form that produces bad addresses is worth finding.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, so the sending platform, HubSpot and your alerting can meet in one automation.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which events cross, how bounces and unsubscribes are handled, and who is told.
3. Authorize the connections — the sending platform and HubSpot.
4. Describe the exceptions: a hard bounce, a spam report, an unsubscribe originating in either system, an unknown recipient.
5. Run it over a week of events and check what reached the CRM and in what form.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Suppression must agree across both

The part with real consequences, and the part most integrations leave half-built.

An unsubscribe in either system must apply in both, promptly, in both directions.

A spam report is an unsubscribe, treated with more urgency, not a metric to observe.

Hard bounces suppress everywhere, since resending to a dead address damages reputation across both streams.

Transactional is not exempt from everything, but it is not the same as marketing — a receipt should still send to somebody who unsubscribed from marketing, and a promotional message dressed as transactional should not.

Reconcile the lists on a schedule and alert on any divergence rather than assuming the sync held.

Record where the suppression came from, since an unsubscribe and a bounce are different and a person asking to be removed deserves a different record from an address that failed.

What belongs in the CRM

Sends, at a summary level, so the contact's history shows they were contacted.

Clicks, which are the engagement signal worth acting on.

Bounces and their type, which is data quality information.

Unsubscribes and complaints, with their source and timestamp.

Not every open, which is both unreliable and high volume, and which buries a timeline within a month.

Not the message content, which belongs in the sending platform with a link.

Domains, and why they should be separate

Reputation is per sending domain, so problems in one stream should not reach another.

Use a subdomain for marketing and a different one for transactional, so a bad campaign does not delay password resets.

Authenticate both properly with SPF, DKIM and DMARC, which is now effectively required rather than advisable.

Warm new domains gradually, since volume from a cold domain is filtered.

Do not send transactional from the marketing stream to improve its engagement numbers, which mixes the reputations you were separating.

Monitor each separately, since a single blended deliverability figure hides the stream that is degrading.

Reporting deliverability where somebody sees it

Deliverability data lives in the sending platform, which marketing rarely opens, so a degrading domain is usually noticed by a salesperson wondering why replies stopped.

Report delivered rate by stream, weekly, somewhere the people sending email actually read.

Watch the trend rather than the day, since reputation problems appear as a slow decline before anything obvious happens.

Break it down by major recipient provider, because a sequence performing normally overall can be filtered entirely at one of them.

Report complaint rate against its threshold, not as a raw number, since the number alone means nothing to most readers.

Alert on a sudden drop in delivered rate, which is one of the few email metrics worth interrupting somebody for.

Connect it to what changed. A decline that began the week a new list was imported is a different conversation from one with no obvious cause.

Making it survive

Make event ingestion idempotent — event webhooks are delivered at least once and often out of order.

Handle the unknown recipient without creating a contact for every address you ever sent to.

Respect HubSpot rate limits, particularly during a backfill of historical events.

Batch rather than writing per event, since high-volume sending will otherwise consume your API allowance.

Report the outcome: events received by type, written, batched, suppressed, and any list divergence.

Limits worth knowing about

Open tracking is unreliable to the point where it should not drive automation decisions.

Event volume is large and writing every event to a CRM is both expensive and unhelpful.

Events can arrive out of order, so a click before a delivered event is normal rather than an error.

Historical event retention is limited on most sending platforms, so a backfill only reaches so far.

HubSpot's own email sending produces its own events, which are separate and should not be conflated with the platform's.

What to build first

Bounce and unsubscribe handling in both directions, reconciled on a schedule. It is the part with consequences — a person who asked not to be contacted receiving another email is a compliance matter, not an inconvenience — and it is the part most likely to be half-built in an integration that otherwise looks complete.

Two habits make the difference. Do not write open events to the CRM, since they are unreliable, high volume, and they bury the timeline with information nobody should act on. And alert on divergence between the two suppression lists rather than trusting the sync, because the failure is silent and the first evidence of it is usually a complaint.

Frequently asked questions

What does a "delivered" event actually mean?

That the receiving server accepted the message. Not that it reached an inbox, and not that it avoided the spam folder. It is a weaker statement than it sounds.

Are open events worth recording?

No. Privacy features prefetch images, registering opens nobody performed, while blocked images suppress genuine ones. They are unreliable, high volume, and they bury a CRM timeline.

What is the difference between a hard and soft bounce?

A hard bounce is permanent — the address does not exist — and should be suppressed immediately. A soft bounce is temporary, such as a full mailbox, and retrying is appropriate with a threshold rather than infinite patience.

Why does suppression need to agree across both systems?

Because a person who unsubscribed in one and receives email from the other is a compliance matter rather than an inconvenience. Reconcile the lists on a schedule and alert on divergence rather than trusting the sync.

Is a spam report just a metric?

No. It is an unsubscribe with more urgency, it weighs heavily on sender reputation, and it should reach a person rather than a dashboard.

Should transactional and marketing email share a domain?

No. Use separate subdomains so a bad campaign cannot delay password resets, authenticate both, and monitor each separately — a blended deliverability figure hides the stream that is degrading.

What does a "dropped" event mean?

That your own sending platform did not send it, usually because the address was already suppressed. It is informative and it is frequently misread as a delivery failure.

What should a bouncing address on an active customer tell me?

Usually that somebody has left the company. It is a data quality signal worth routing to the account owner rather than only suppressing the address.

Who should see deliverability data?

The people sending the email, weekly, wherever they already read things. It lives in the sending platform, which marketing rarely opens — so a degrading domain is typically noticed by a salesperson wondering why replies stopped.

Should deliverability be reported per provider?

Yes. A sequence that looks normal overall can be filtered almost entirely at one major mailbox provider, and a blended figure hides it completely.

Should every email event be written to the CRM?

No. Event volume is large, most of it is not actionable, and writing per event will consume your API allowance. Batch a summary, write clicks and bounces individually, and leave the rest in the sending platform.

Does an unsubscribe from marketing stop transactional email?

It should not. A receipt still sends to somebody who unsubscribed from marketing. The distinction only works if promotional messages are not dressed as transactional ones, which is where this goes wrong.

Related reading

• Automating follow-up emails
• HubSpot and CodeWords
• Automating a welcome email sequence