<!-- Canonical URL: https://www.usebluehill.com/features/integrations -->
<!-- Source: https://www.usebluehill.com/features/integrations.md -->

# Integrations — API, webhooks, and email automation

> BlueHill's integration layer is an API-first foundation: REST API, outbound webhooks for every meaningful event, and native email automation via Resend. Third-party connectors are on the roadmap.

## What's native today

Being explicit about what's first-class versus what's via-the-API: the integrations that are **native, shipped, and fully wired in BlueHill today**:

1. **Email (inbound + outbound) via Resend** — every email touchpoint with your customers flows through this. Inbound mail creates or appends to tickets. Outbound replies maintain thread integrity. This is the email-to-ticket pipeline.
2. **REST API** — every model (Customers, Tickets, CustomerTasks, Forms, Boards, Templates, Metrics) has CRUD endpoints.
3. **Outbound webhooks** — every meaningful event in the system fires a webhook. Ticket lifecycle, task status changes, form submissions, customer updates, board changes.
4. **API key management** — generate, scope, and rotate API keys in Settings, backed by the `api_keys` model.
5. **SAML SSO** (Enterprise) — Okta, Azure AD, Google Workspace as IdPs.

These five together cover the integration surface that matters most: messaging in/out, programmatic data access, event-driven downstream automation, and identity.

## What's via webhook / API today

Brand-name integrations that customers ask about — Slack notifications, Google Drive document storage, QuickBooks invoice export, HubSpot sync, Notion mirroring — are **not native connectors yet**. They're absolutely supported in production today, but through webhook + a small amount of glue code (or through Zapier/n8n if you don't have engineers handy).

We're being upfront about this distinction because the difference matters. A "native" integration means: install once, never touch again. A "via webhook" integration means: install once, monitor your endpoint, update when one of the systems changes its API. The webhook path is plenty robust if you have any engineering capacity, and it covers essentially every SaaS tool. It's just not zero-friction.

The integrations we hear teams build most often via webhook today:

- **Slack** — fires on customer-health changes, SLA breaches, milestone hits
- **QuickBooks** — fires on time-entry approval to draft invoices
- **HubSpot** — sync customer record updates back to the CRM
- **Snowflake / BigQuery / Postgres** — fire all events to the data warehouse for BI
- **Notion / Confluence** — push status updates into team wikis

## Native connectors on the roadmap

We don't pre-announce dates, but the integration team's current focus order (based on customer requests):

1. **Slack** — direct notifications without webhook code
2. **QuickBooks** — native invoice export from time entries
3. **Google Drive / OneDrive** — file storage with two-way sync
4. **HubSpot / Salesforce** — bidirectional customer sync
5. **Calendar** (Google / Outlook) — meeting capture into the interaction timeline

When these ship, the documentation will move from this page into Settings → Integrations as a one-click setup. Until then, the webhook path is the way.

## The REST API in detail

Every BlueHill entity is reachable via REST:

```
GET /api/customers
POST /api/customers
PATCH /api/customers/:id

GET /api/tickets?customer_id=...&status=Open
POST /api/tickets
PATCH /api/tickets/:id

GET /api/customer_tasks?board_id=...
PATCH /api/customer_tasks/:id

GET /api/activity?customer_id=...&since=2026-05-01
```

Authentication: `Authorization: Bearer <api_key>` header. API keys are managed in Settings → API Keys, with optional scoping by permission level.

Rate limits are generous (10,000 requests / hour per key by default; higher on Enterprise). The API responds in JSON with consistent envelope: `{ data, meta }` for collection endpoints, plain object for singletons.

For the current endpoint reference and additional API examples, contact sales@usebluehill.com.

## Webhook setup

In Settings → Integrations → Webhooks:

1. Add target URL (HTTPS, valid TLS cert)
2. Pick events you want
3. BlueHill posts a sample payload so you can confirm your endpoint receives it
4. Production traffic starts immediately

Every webhook payload is signed: header `X-BlueHill-Signature: sha256=<hmac>`. Verify with the shared secret from the webhook settings page.

Retry policy: failed deliveries (non-2xx response) retry with exponential backoff for 24 hours.

## What this replaces

Teams arriving at BlueHill for integration work are usually replacing:
- Manual data export → CSV import pipelines
- Brittle Zap chains that break when one tool changes
- Custom-built sync scripts that nobody maintains

The pattern: build once against the BlueHill API or webhook surface, and the data flows reliably. We don't try to be a workflow automation platform — we try to be the operational system of record that integrates well with whatever automation platform you already use.

## Try it

[Start a 14-day free trial](https://app.usebluehill.com/sign-up) — no credit card required. The API + webhook surface is available on every paid plan; native connectors (when they ship) will be available on Professional and Enterprise.
