Skip to main content

The Problem

When a third-party app (like a form builder, CRM, or bug reporting tool) sends a notification email on behalf of a user, the email comes from the app’s noreply@ address — not the actual customer. This means Halo creates the contact as [email protected] instead of the real user, and:
  • The ticket is linked to the wrong contact
  • The AI agent can’t pull up the customer’s history or context
  • Replies go to the notification address instead of the customer
  • You lose all the structured data from the original form submission
This guide covers two approaches to solve this, depending on your integration capabilities.
If you can make HTTP requests from your app or webhook handler, use the Tickets API to create tickets with proper user association. This is the cleanest solution and what tools like Intercom recommend for programmatic integrations.

How it works

Basic example

The ticket is created in your Halo inbox, linked to [email protected], and the AI agent has full context to respond.

Integration examples

Most form builders (Typeform, Tally, JotForm, OrbitForms) support sending webhooks when a form is submitted. Point the webhook at a handler on your backend that calls the Halo Tickets API:

Enabling AI responses

Set "ai_enabled": true to have Halo’s AI agent automatically respond to tickets created via the API. The AI uses your configured email agent and replies to the user’s email address:
AI responses require AI email auto-reply to be enabled in Settings > AI Agents. The AI agent uses your trained knowledge base to respond, just like it would for email tickets.

Enriching user data

For richer AI context, call the identify endpoint before creating the ticket. This gives the AI access to the user’s plan, role, company, and custom attributes:

Approach 2: Email Best Practices

If your integration must send emails (e.g., you can’t modify the third-party app’s webhook behavior), follow these guidelines to help Halo identify the real sender.

Use the customer’s email as the From address

The most effective approach is configuring your notification system to send emails from the customer’s actual email address, not from a noreply@ address:
vs.
Sending emails from a customer’s address you don’t control may cause deliverability issues (SPF/DKIM failures). Only do this if you’re sending from a domain you have DNS control over, or if the email provider supports “send as” with proper authentication.

Use the Reply-To header

If you can’t change the From address, set the Reply-To header to the customer’s email. This ensures that when your team replies from Halo, the response goes to the right person:

Enable forwarded customer detection

If your notification emails include a From: line in the body (common with email forwarding), Halo can automatically extract the original sender.
  1. Go to Settings > Emails > Email Settings
  2. Enable Detect forwarded customers
This works when the email body contains a line like:
Halo parses this and creates the contact as [email protected] instead of the envelope sender.

Include structured data in the subject

When sending notification emails, put key information in the subject line so it’s visible in the Halo inbox at a glance:

Limitations of email-based integrations

For these reasons, the Tickets API is strongly recommended over email for third-party integrations.

Comparison


Next Steps

Tickets API Reference

Full API reference for creating tickets programmatically.

Identify Users

Enrich user records with traits and context before creating tickets.

Receiving Emails

Set up email forwarding from your existing support address.

Automatic Ticket Creation

Create tickets through the AI chat pipeline for triage and auto-response.