n8n-nodes-karbon

An n8n community node for Karbon, the practice management platform for accounting firms.

This package provides two nodes that share a single credential:

• Karbon — an action node covering the entire published Karbon API v3 surface: 20 resources, every documented endpoint.
• Karbon Trigger — a webhook trigger node that subscribes to Karbon's webhooks, verifies delivery signatures, and can hydrate events into full records.

n8n is a fair-code licensed workflow automation platform.

• Installation
• Credentials
• Karbon node — resources and operations
• Karbon Trigger node
• Usage notes
• Compatibility
• Resources
• License
• Support
• Author

Installation

Follow the community nodes installation guide in the n8n documentation. When prompted for the npm package name, enter:

n8n-nodes-karbon

This node is for self-hosted n8n instances.

Credentials

Both nodes use one Karbon API credential with three fields:

| Field | Description | | --- | --- | | API Access Key | Your Karbon API access key. Sent as the AccessKey header on every request. | | Application ID | Your application's Bearer token. Sent as Authorization: Bearer {Application ID}. | | Base URL | Defaults to https://api.karbonhq.com. Only change this if Karbon directs you to a different API host. |

To get keys, see Karbon's API documentation — you'll need to register an application with Karbon to receive an Application ID, and generate an access key for your tenant.

The credential test calls GET /v3/Organizations, so a working credential is verified before you build anything.

Karbon node — resources and operations

| Resource | Operations | | --- | --- | | Billing | Create Manual Payment, Delete Manual Payment, Get Invoice, Get Manual Payment, Get Many Invoices, Get Many Manual Payments, Reverse Manual Payment | | Business Card | Get, Update | | Client Group | Create, Get, Get by User Defined Identifier, Get Many, Patch (Partial), Update (Full) | | Comment | Get | | Contact | Create, Get, Get Many, Patch (Partial), Update (Full) | | Custom Field | Create Definition, Delete Definition, Get Definitions, Get Values, Update Values | | Estimate Summary | Get by Work Item | | File | List Files, Upload File, Download File | | Individual Time Entry | Get, Get Many | | Integration Task | Get, Get Many, Get Many Definitions, Update | | Note | Create, Get | | Organization | Create, Get, Get by User Defined Identifier, Get Many, Patch (Partial), Update (Full) | | Team | Add Members, Get, Get Many, Remove Member | | Tenant Settings | Get | | Timesheet | Get, Get Many (endpoints deprecated by Karbon — see notes) | | User | Create, Get, Get Many | | Webhook Subscription | Create, Delete, Delete All, Get | | Work Item | Create, Get, Get Many, Patch (Partial), Update (Full) | | Work Schedule | Create, Get, Update (Full), Update End Date | | Work Template | Get, Get Many |

Highlights:

• Dropdown pickers for organizations, contacts, users, teams, work templates and more, loaded live from your tenant — with expression support when you need to pass keys dynamically.
• File uploads and downloads against work items, contacts and other entities, including binary data handling.
• Business card handling — contact and organization creates accept addresses and phone numbers and attach them to the primary business card automatically.
• Integration Tasks cover Karbon's Integrated Workflows feature, letting a workflow read and complete integration tasks embedded in work item checklists.

Karbon Trigger node

The trigger node registers a webhook subscription with Karbon when the workflow is activated and removes it again on deactivation.

How it works

• Webhook types — Karbon delivers events per entity type (Contact, Work, Note, User, IntegrationTask, Invoice, EstimateSummary). Pick the type the workflow should listen to. Note that Contact also covers client groups and organizations.
• One subscription per type, tenant-wide — a Karbon tenant can hold only one subscription per webhook type, and Karbon has no UI to manage them; the API is the only way to see or change what is registered. If another integration already owns the type, activation fails with a clear error showing the currently registered URL. Enable Replace Existing Subscription only when you intend to take that subscription over.
• Current Subscription Status — a read-only lookup right in the node (shown in the screenshot) that tells you what is currently registered with Karbon for the selected type, so you can check for conflicts before activating. It never changes anything.
• Safe deactivation — the node only deletes a subscription that points at its own webhook URL, so it can never tear down another integration's subscription.
• Signature verification — Karbon signs deliveries with an HMAC-SHA256 Signature header. The node generates and stores a signing key automatically (or accepts one you provide) and rejects any request whose signature is missing or invalid. Activation always makes sure Karbon is signing with a key the node knows — if the registered subscription's key is unknown (for example it was created by another tool), the node re-registers it with its own key.
• Fetch Full Record — optionally hydrates each event by fetching the changed record from the API, emitting the full entity alongside the event payload.
• Silent cancellation after failures — Karbon cancels a subscription after 10 consecutive failed deliveries, without telling you. If events stop arriving, deactivate and re-activate the workflow to re-register.

You can run multiple Karbon Triggers at the same time — one per webhook type. The one-subscription limit applies per type, not per tenant, so separate triggers for Contact events, Invoice events, Note events and so on can all be active simultaneously (in the same workflow or spread across different workflows). What you cannot have is two active triggers listening to the same webhook type:

Companion management operations (inspect, create, delete subscriptions manually) live on the action node's Webhook Subscription resource.

Testing trigger workflows — read this first

n8n gives every webhook trigger two different URLs: a test URL (/webhook-test/...) used while the editor is listening for a test event, and a production URL (/webhook/...) used once the workflow is active. Because Karbon only holds one subscription per webhook type, there is no clean way to point Karbon at the test URL without tearing down the production registration — so the editor's "Listen for test event" flow is effectively unusable with this trigger.

The workflow that works well instead:

1. Activate the workflow — activation registers the production URL with Karbon. (A bare trigger node with nothing after it is fine to start with.)
2. Cause a real event in Karbon — update a contact, change a work item, whatever matches the webhook type.
3. Open the workflow's Executions list, open the run that came in, and use Copy to editor on it (or copy the trigger's output payload).
4. Pin that data on the trigger node in the editor and build the rest of the flow against the pinned, real payload.
5. Unpin when you're done — live events keep flowing through the production URL the whole time.

This gives you a real Karbon payload to develop against without ever re-registering the webhook or interrupting live delivery.

Usage notes

• List operations follow a consistent pattern: a Return All toggle, a Limit (default 50), and an Options collection with sort, skip and filter fields. Pagination via OData @odata.nextLink is handled automatically.
• Filtering — most Get Many operations expose the useful filters as individual fields, plus a Custom Filter option that accepts a raw OData $filter expression and overrides the structured fields when set. User-supplied text is escaped for OData automatically.
• Dates — date inputs are sent as calendar dates exactly as entered (no timezone conversion), matching how Karbon stores date-only values.
• Timesheets vs Individual Time Entries — Karbon has deprecated the Timesheets endpoints in favor of IndividualTimeEntries. The Timesheet resource remains implemented because it is the only place the timesheet approval status (Draft/Submitted/Approved/Declined) is exposed; prefer Individual Time Entries for per-day, per-entry time data (including hourly rate, total cost and billed status).
• Mutations that return no content (payment reversal, team membership changes, schedule end-date updates, integration task updates) emit a { "success": true, ... } object with the affected keys so downstream nodes always receive an item.
• Integration Tasks only work for an Application ID that Karbon has registered as an integration partner and that your tenant has connected. A standard API Application ID receives 401 Unauthorized on these endpoints even when it works for every other resource — contact Karbon to enroll your application in Integrated Workflows.

Compatibility

Requires an n8n version that supports community nodes (Node.js 20.15+). Developed and tested against recent n8n 2.x releases on self-hosted instances.

Resources

• Karbon API reference
• Karbon
• n8n community nodes documentation

License

MIT

Support

For bugs and feature requests, please open an issue on the GitHub repository.

Author

Daniel Fonseca — [email protected]

Built for the n8n community and shout out to AutomationTown.