Building the Howie Integration: CC-on-Thread Instead of an API

Howie is an AI calendar secretary. He books meetings over email. That is his whole public surface: CC him and he handles the back-and-forth. No REST API, no OAuth, no webhooks, no SDK. So when we built the Introzy integration, the question was not "which endpoint do we call?" It was "what is the thinnest possible integration that still delivers value?"

The answer: store one email address per org, CC it on outbound mail through Nylas, and let the existing calendar sync close the loop.

The Constraint

Howie uses a hybrid AI + human reviewer model. The system simulates scheduling decisions internally, flags potential errors, and escalates anything ambiguous to a human before hitting send. That is why there is no API: the product is conversational and asynchronous by design. Every interaction is an email thread, not a function call.

Our team was already using it. Zac writes about the personal experience. From an engineering perspective, the question was: how do you integrate with a product that has no integration surface?

The Integration Model

Every other Introzy CRM integration follows the same playbook: OAuth or API key, field and stage mapping, inbound and outbound sync flows, data normalization. HubSpot, Salesforce, Zero — all use that pattern.

Howie does not fit the playbook. He is not a CRM. He does not have contacts, companies, deals, or pipeline stages. He does not expose an API. He is a scheduling secretary who reads email threads and writes Google Calendar events.

We spent a full audit documenting what Howie’s public surface actually is before writing production code. The decision table:

The locked v1 decision: email-only auth, CC-on-thread action, Nylas calendar inbound.

Schema: One Row Per Org

The closest existing pattern is the Zoom org install: one row per organization, admin connects, Settings card. Except Zoom needs OAuth tokens, encrypted secrets, and a callback route. Howie needs an email address.

OrgHowieInstallation stores:

• organizationId (unique)
• howieEmail (normalized lowercase, Zod-validated)
• status: active | revoked
• installedByUserId, timestamps
• lastInviteAt, lastErrorMessage, lastErrorAt (health tracking)

No ciphertext columns. No connection id. No token refresh job. Connect is a POST with an email field. Disconnect is a soft-revoke that preserves the email for reconnect.

Default address is howie@howie.com. Custom-domain assistants (howie@yourdomain.com) work by entering any valid email.

The Send Path

When a user sends a referral intro or schedules from the person slideout with Howie checked:

User action (wizard or slideout)
  → resolveHowieIntroCc()
     → findOrgHowieInstallationForOrg (active only)
     → append howieEmail to cc[] (dedupe)
  → addNylasEmailSendJob({ to, cc, howieInvite, no loopsFallback })
  → nylas-email-send-worker
     → Nylas API sends the email
     → stamp lastInviteAt
     → (if deal) persist HowieSchedulingInvite

Three details worth calling out:

Loops fallback cannot CC Howie. The email send path has a Loops fallback for when Nylas is unavailable. Loops templates cannot take extra CCs. So Howie rides the Nylas path only. If Nylas cannot send, Howie is not on the thread. This is a known gap, not a bug — the alternative was building CC support into a transactional email provider, which is out of scope.

The body must include a schedule ask. During our pilot soak, we discovered that CC alone was not enough. If the email body did not contain an explicit scheduling request, Howie classified the thread as informational and did not engage. So the server owns the schedule-ask sentence:

export const HOWIE_SCHEDULE_ASK =
  "I'd like to find a time to meet. Howie, can you propose some times that work?"

The user can add optional context above this, but the ask is always appended. We intentionally do not expose a full email composer for this flow — the ask is not user-editable.

Human-initiated sends are not rate-limited. The Nylas send path is shared with Kai intake, which has a per-org daily mutation cap (default 20, env-configurable). Schedule with Howie sends bypass that cap because they are explicit user actions, not agent-initiated mutations.

The Inbound Path: There Is No Inbound Path

Howie has no webhooks. After Howie books, the flow is:

Howie reads the thread
  → proposes times on the email thread
  → attendee picks a time
  → Howie writes a Google Calendar event
  → Google Calendar updates
  → Nylas webhook fires
  → existing nylas-calendar-webhook-worker syncs the event
  → event appears on the contact timeline

Introzy never calls Nylas events.create. Howie never writes Introzy CRM objects. The calendar sync that already exists for Gmail is the return path. We did not build a scheduling engine — Howie is the scheduling engine. We get him on the email thread and let existing infrastructure do the rest.

Attribution is best-effort. We match on org + attendee email overlap + a 48-hour time window from lastInviteAt. No Howie event id exists in the calendar event metadata, so a unique match is not guaranteed. If the same two people have overlapping Howie threads, or the calendar event was created outside the window, the match is ambiguous. Ambiguous matches stay unlinked — same fail-closed philosophy as our Zoom calendar matcher.

What We Deliberately Did Not Build

• Data sync connection. Howie has no objects to sync. No field mapping, no data normalization, no pipeline stage pairs.
• Per-user Howie install. Howie the product is per-person (each user connects their own Google Calendar). But the assistant email is shareable. One org-wide email is enough for v1.
• Booking page. Howie is not Calendly. He negotiates on email threads, not booking links. The distinction matters: booking links are one-way forms. CC-on-thread is a conversation where Howie can ask clarifying questions, handle multi-party coordination, and follow up if someone goes quiet.
• Outlook support. Howie reads and writes Google Calendar only. We show a static note on the Settings card. This is Howie’s limitation, not ours.
• Howie provisioning. Introzy does not create Howie accounts. Howie is a customer prerequisite — sign up at howie.com and connect your Google Calendar before enabling the integration in Introzy.
• iMessage / SMS from Introzy. Howie supports text scheduling, but our send path is email via Nylas.

What Surprised Us

Plus-address threads are ignored. During local QA, Howie ignored threads sent from user+tag@gmail.com plus-addressed aliases. The same send from a non-aliased address worked immediately. Do not use +tag aliases on threads where Howie is CC’d.

Booking is not instant. Howie uses a hybrid AI + human reviewer model. Responses can take minutes, not seconds. The first time a pilot user reported "Howie did not book," the meeting showed up 15 minutes later. Build your monitoring expectations around this — do not alert on a 10-minute gap between send and calendar event.

The Howie dashboard is the debugging tool. howie.ai/dashboard → Currently Scheduling shows what Howie ingested. If the thread does not appear there, Howie did not pick it up. Check the email body for the schedule ask, check for plus-address aliases, and verify the Howie account’s Google Calendar is connected.

Where This Goes

• Attribution link between HowieSchedulingInvite and the calendar event when the matcher finds a unique match
• Company slideout Schedule with Howie (currently person-only)
• Detection of whether the sender’s Google Calendar is actually connected to Howie (requires a future Howie API or a lightweight probe)

The integration is deliberately minimal. The thinnest thing that works is often the right thing to ship.

Try Introzy: Connect Howie in Settings, CC him on your next referral intro, and the meeting lands on the contact timeline. Get started free →

We ship in public. Come build with us.

Introzy is free to start. No card required.