Package Information
Documentation
n8n-nodes-wr-leadperfection
n8n community node for the LeadPerfection CRM.
Built against LeadPerfection's official OpenAPI 2.0 specification
(SwaggerHub) and
verified live against LeadPerfection's public sandbox.
Coverage
Every endpoint in the official spec is implemented — 48 endpoints across 6 controllers,
exposed as 54 operations over 11 resources.
| Resource | Ops | Notes |
|---|---|---|
| Account | 2 | Entitlement introspection, menu |
| Appointment | 5 | Detail, date range, result update, schedule, images |
| Custom Field | 1 | Slot discovery |
| Customer | 15 | Search, prospect/lead/job data, milestones, updates, call history |
| Employee | 1 | Directory |
| Installer | 4 | Job detail, notes, images |
| Job | 9 | Detail, costs, payments, commissions |
| Lead | 7 | Create, inbound history/queue, forward look, appointments |
| Note | 1 | Notes against customers, leads and jobs |
| Reference Data | 5 | Source subs, promoters, branches, products + 29 static lookup tables |
| Telecom | 4 | Dialer queues, call history / notes XML |
Architecture
Every LeadPerfection endpoint is a POST with an x-www-form-urlencoded flat body, so the
node is declarative:
resources.ts— the operation catalogue, generated from the official spec. Single source
of truth for methods, fields, types, required-ness, date formats and custom-field slots.Builder.ts— turns the catalogue into n8n UI properties.Engine.ts— one generic executor for all spec'd endpoints.LeadPerfection.node.ts— hand-written handlers for the value-add operations.
To pick up an API change, regenerate resources.ts rather than hand-editing field lists.
Things that will bite you
StartIndex is a 1-based PAGE NUMBER, not a row offset. This is undocumented and is the
opposite of the usual convention. Advancing by row count asks for page 201 after page 1,
gets an empty array back, and silently truncates the result to a single page. Verified
against the sandbox: a 12-row range at PageSize=5 returns 5/5/2 rows over pages 1/2/3,
while StartIndex=6 returns nothing.
Date formats are not consistent between controllers. Leads/* documents MM/DD/YYYY;Customers/*, SalesApi/* and Installer/* document YYYY-MM-DD; AddCallHistory wantsYYYY-MM-DD HH:mm:ss. The backend currently parses both, but the node sends each endpoint
its documented format so day/month can never be transposed. The format is carried per-field
in the catalogue — do not "normalise" it.
Custom fields have no definitions endpoint. Slot labels appear only in the userfields
array riding along on live records ({fldnumber, fieldtitle, fieldvalue}). The Resource
Mapper therefore discovers its schema by sampling recent records, widening the window until
slots turn up. Two candidate label tables (GetSalesApptDispProd types j/l) were
checked and are screen-label overrides for standard fields, not slot definitions.
Writable slots differ by endpoint. LeadAdd accepts user1–user15.UpdateSalesApptDetail3 accepts a 5x5 grid: user11–15, 21–25, 31–35, 41–45,51–55. Reads can surface slots beyond either range.
Run Account > Get Entitlements first. The /token response carries user_data.Settings
— the exact list of methods that credential may call. It turns an opaque 403 three weeks in
into a named list to hand LeadPerfection support on day one.
No outbound webhooks. Change detection is polling via Customer > Get Job Status Changes.
No search by email. Phone is the only find-or-create key.
Lead > Get Many (GetLeadData) is deprecated by LeadPerfection and ignores pagination
entirely — chunk it by date.
Credential
Password-grant against https://{serverid}.leadperfection.com/token. Tokens last 24h and are
cached per server + client + user. serverid is the environment: api (production),apitest (LeadPerfection's shared sandbox), or a dedicated host.