n8n-nodes-purecallcenter

An n8n community node for PureCallCenter — Belmont's in-house phone
system. Send SMS/MMS through your PCC numbers and update PCC contacts, without hand-rolling HTTP
Request nodes and pasting API keys into workflows.

Status: v0.1.0, not yet published. SMS → Send is verified end-to-end against the live
API (2026-09-25): plain SMS, MMS, E.164 and bare 10-digit all delivered, six sends for six.
Contact → Update mirrors the request shape proven in production but cannot be verified —
that endpoint has no read-back of any kind. See API-NOTES.md for both probe
tables and the open questions.

Installation

Self-hosted n8n → Settings → Community nodes → Install →
@belmontdigitalmarketing/n8n-nodes-purecallcenter

Credential

PCC is not a conventional REST API: each capability is a separate per-account endpoint whose URL
ends in a random token, and the auth differs per endpoint. So the credential stores one full URL
per endpoint rather than a base URL.

Both URLs are stored masked, because the path token is itself authorization — anyone holding the
contact URL can write contacts. Copy them whole, including the token.

Leave an endpoint blank if you don't use it; the node fails with a message naming the exact
credential field when an operation needs a URL that isn't filled in. There is no credential
Test button yet — PCC has no read-only endpoint to test against.

Operations

SMS → Send

Sends an SMS (or MMS, with a media URL) from one of your PCC numbers and threads it onto a
contact's conversation.

Phone numbers are passed through exactly as given — the node refuses anything with fewer than ten
digits but never rewrites what you send. Verified safe: +18015551234 and 8015551234 both
deliver, so PCC normalises 10-digit US numbers itself.

A 200 from PCC is not a delivery receipt. Sends are queued and arrive tens of seconds later, and
every outcome returns 200 with an empty body — no message SID, no status field. The node therefore
outputs accepted: true, not success.

The one failure mode that is completely silent is a from number the account doesn't own: it
returns the same 200 and delivers nothing. No endpoint lists the account's numbers, so the node
can't catch this — getting From Number right is on you.

Contact → Update

Requires an Applicant ID. Common fields (First Name, Last Name, Email, Cell Phone) are
top-level; the rest live in Additional Fields (address, city, state, ZIP, account name,
assigned agent, lead source/status, applicant type, customer since, created, last modified) and
Co-Applicant Fields (first/last name, cell phone, email).

Every PCC field is sent on every call, with an empty string for the ones you leave blank. That
mirrors the request shape proven to work in production rather than second-guessing it. The
consequence is an open risk: it is unconfirmed whether PCC treats a blank as "clear this field".
It behaves identically to the hand-built HTTP Request node already running in production, so it adds
no new risk — but don't point it at records whose other fields matter until that's settled. See
API-NOTES.md.

There is no read-back on this endpoint, so neither the node nor a workflow can verify that a write
landed. Its plain-text Contact Updated response is not evidence.

Include Link to Workflow

Every operation carries the standard opt-in toggle (default off). Because an SMS body is read by
the recipient, the link is never appended to the message or written to the contact — it is
added to the node output as workflowLink, for downstream Slack or email steps.

Not implemented, and why

• Contact → Get — no such endpoint is available. From the existing workflows we know a response
  would look like { "response": { "id", "owner_id", … } }. Its absence is what blocks ID
  validation, contact pickers, and any verification of writes.
• Contact → Create — removed after probing. A body with a blank or absent applicantId returns
  200 with an empty body and creates nothing, so the operation could only ever have silently
  no-opped. How PCC expects a contact to be created is an open question.
• Contact pickers — Contact ID / Owner ID / Applicant ID are plain text fields. Once there's
  a contact search endpoint they should become resourceLocator pickers. That changes the stored
  parameter shape, so it has to land before the first publish.
• Trigger node — pending confirmation that PCC fires outbound webhooks.

Development

npm install
npm run build     # tsc + copy icons
npm run lint      # ESLint with eslint-plugin-n8n-nodes-base
npm run lintfix
npm run format
npm run dev       # tsc --watch

n8n-workflow is pinned to ~1.10.0 on purpose — newer versions pull in an isolated-vm
native dependency that fails to compile against Node 20, which CI uses.

License

MIT