n8n

n8n is an automation engine you run yourself. On one side is AppBO, reached over its REST API and its webhooks. On the other is whatever lives in your environment. An internal database, a file share, a line-of-business application on a private network, a reporting warehouse, plus the same public SaaS catalog any automation platform reaches. The defining difference is where the engine runs: on your infrastructure, inside your network boundary, with credentials stored in your instance rather than a vendor's.

That is the reason to choose it. If your constraint is regulatory, contractual or simply a security review that will not approve customer data transiting a third-party automation vendor, a self-hosted runner removes the question entirely. The AppBO payload arrives at a host you control, is transformed on that host, and is written to a destination you control. It is also the right answer when the integration needs to reach something with no public endpoint (a practice management system on a private subnet, a database behind a firewall) because the runner is already inside with it.

The cost is that you own the platform. Uptime, upgrades, TLS certificates, backups, queue workers, secret storage and capacity are now your responsibility, and a runner that falls over at two in the morning does not page a vendor. n8n also gives you a Code node, which is simultaneously its best feature and the place where undocumented business logic accumulates. Treat a production n8n instance as a service you operate, with the monitoring and change control that implies.

1. Stand up the instance properly before building anything: a persistent database rather than the default file store, a durable volume, TLS on a hostname your team can reach, and authentication on the editor UI. An n8n editor exposed without authentication is a credential store open to the internet.
2. Decide how the instance will receive webhooks. Set the public webhook URL configuration so that generated webhook URLs are the externally reachable ones, and open only that path through your ingress. Getting this wrong produces webhook URLs that look right and are unreachable.
3. Configure queue mode with separate workers if you expect any real volume. The single-process default will serialise your executions and become the bottleneck.
4. Create the AppBO credential in n8n. Use an OAuth app credential where the node supports it; otherwise configure a header-auth credential carrying the bearer token, together with the API version header the reference specifies. Store it as an n8n credential, never inline in a node.
5. Confirm the credential resolves by running a single read node (fetch one contact or list the calendars) and checking the returned account identifier is the account you intended.
6. Choose how the workflow starts. For platform-initiated flows, add a Webhook node and register its URL as an outbound webhook or a workflow webhook step in AppBO. For scheduled work, use a Schedule trigger and read from the API.
7. Secure the Webhook node. Attach header authentication to it, and have AppBO send the matching secret header. An unauthenticated n8n webhook is a public endpoint that will execute your workflow for anyone who finds it.
8. Capture a real payload: activate the workflow, send one live event, and pin the resulting data on the Webhook node so you can keep building without re-sending events.
9. Build the transformation with Set and IF nodes in preference to a Code node. Reserve the Code node for genuine logic, and comment it, because it will outlive whoever wrote it.
10. Add a lookup node before any create node, keyed on a stable identifier, and branch the found and not-found cases with an IF node.
11. Configure error handling explicitly: set retry-on-fail with a sensible interval on nodes that call flaky services, decide node by node whether to continue on failure, and set an error workflow on the workflow's settings so failures are reported rather than merely logged.
12. Return the right response from the Webhook node and return it fast. Use the respond-immediately option and do the work after responding, so the platform is not waiting on your whole workflow.
13. Verify the connection end to end: trigger a real event in AppBO, watch the execution appear in n8n, confirm the branch taken, and confirm the destination record is correct.
14. Test the failure modes you will actually hit: stop the destination system and confirm the retry and error workflow behave; restart n8n mid-execution and confirm you know what happens to in-flight work.
15. Put the instance under monitoring: process liveness, queue depth, execution failure rate, disk usage for execution history, and set an execution data retention policy before the database fills up.

Platform to n8n

• Webhook payloads from AppBO outbound webhooks or workflow webhook steps, arriving at a Webhook node on your host.
• Records read through the API: contacts and custom fields, opportunities, conversations, appointments, form submissions, users.
• Paginated result sets, which n8n can iterate natively over items.

n8n to the platform

• Contact creates and updates, including custom field values.
• Opportunity creates and stage changes.
• Notes, tasks and appointments.
• Workflow entry for a contact.
• Any other API operation via the HTTP Request node using the stored credential, which is how you reach endpoints no dedicated node covers.

Inside your environment

• Reads and writes against internal databases, file shares and private-network applications. The data stays on your side of the boundary throughout.
• Credentials for all of the above, held in your instance's encrypted credential store.

What does not move

• Nothing goes to a third-party automation vendor. There is no external execution log holding your payloads.
• Builder assets in the platform: funnels, sites, email template design.
• Execution history out of your instance; if you need it elsewhere, ship it deliberately.
• Transactional guarantees across nodes. A failure at node nine does not roll back node four.

Scenario: a healthcare operator cannot send patient data to a hosted automation vendor, and must write every AppBO appointment into an on-premises practice management database.

1. n8n runs on a virtual machine inside the operator's network, behind their load balancer, with TLS on an internal hostname and the editor UI restricted to the corporate network. Only the webhook path is exposed externally.
2. A workflow begins with a Webhook node at a long random path, with header authentication requiring a secret the operator generated.
3. In AppBO, a workflow triggered by appointment booking ends in a webhook step pointed at that URL, sending the secret header and a flat JSON body: event identifier, contact identifier, name, date of birth custom field, appointment start, calendar name and assigned practitioner.
4. A real booking is made. The Webhook node receives the request, validates the header, and responds immediately with a success status so the platform is not held open.
5. An IF node checks the event identifier against a de-duplication table in the local database. It is unseen, so execution continues down the true branch.
6. A Set node normalizes the payload: the date of birth is reformatted to the database's expected format, the practitioner name is mapped to the internal staff identifier, and the appointment start is converted to the database's timezone.
7. A Postgres node looks the patient up by the operator's own medical record number, which AppBO holds in a custom field. The patient exists.
8. A second Postgres node inserts the appointment row and writes the event identifier into the de-duplication table in the same statement batch, so a replay cannot double-book.
9. An HTTP Request node calls back to AppBO using the stored credential and writes a note on the contact recording that the appointment was synced, giving the front desk visible confirmation.
10. The database is briefly unavailable during a maintenance window. The Postgres node's retry-on-fail attempts fail, the workflow's error workflow fires, and the operations team receives an alert naming the failed execution.
11. After the window closes the team retries the failed execution from n8n's execution list. The de-duplication check still passes because nothing was written, the appointment inserts cleanly, and no patient data ever left the network.

Rate limiting

Your runner has no vendor-imposed task quota, which removes one limit and exposes another: it is now trivially easy to hammer the AppBO API. A loop over ten thousand contacts with no pacing will hit 429 responses quickly. Add deliberate batching and a wait between batches, honor the rate-limit headers, and remember your own internal systems have capacity limits too. Capacity on the n8n side is whatever you provisioned; in single-process mode concurrent executions queue behind each other.

Retries and idempotency

n8n's retry-on-fail is per node and re-executes just that node, which is useful but means a create node that timed out after succeeding will create a second record on retry. Keep a de-duplication table or an upsert key, and make the writing node idempotent rather than relying on the retry being safe. Be clear-eyed about process restarts: executions in flight when the process dies may not resume, so for anything that must not be lost, let the platform's webhook retry be your safety net by responding only once you have durably queued the work.

Field mapping traps

n8n passes data as items, and a node that expects one item but receives twenty will run twenty times. A frequent surprise after a node that returns a list. Expressions silently evaluate to empty when a path does not exist, so a renamed upstream field produces blank values rather than an error. Pin sample data while building, then remember to unpin it before activating; a workflow left running on pinned data looks like it works and processes nothing real.

Duplicate creation

Two sources of duplicates compound here: the platform's at-least-once webhook delivery and your own retries. Check an event identifier at the top of the workflow and store it as part of the same write that creates the record.

Sandbox versus live

Run separate instances, or at minimum separate workflows with separate credentials, for test and production, and never point a test workflow at a production AppBO account. n8n's own distinction between a test URL and a production webhook URL catches people out: a workflow that works while the editor is open but does nothing once you close it is almost always a test URL registered where the production one belongs.

Auth expiry and operational hygiene

OAuth credentials expire and need refresh; n8n handles this for credentials it owns, but a token you pasted into a header-auth credential will simply stop working one day with no warning. Put an expiry reminder on any static credential. Beyond auth, the operational failures are yours: an expired TLS certificate, a full disk from unpruned execution history, an upgrade that changes node behavior, and a credential store whose encryption key was never backed up.

What commonly breaks

• The configured public webhook URL not matching reality, so generated URLs are unreachable.
• Test webhook URLs left in production configuration.
• Pinned data left on a node, masking the fact that nothing real is flowing.
• Execution history filling the database and degrading the instance.
• An unauthenticated editor UI or webhook node exposed to the internet.
• Business logic buried in an uncommented Code node that nobody left in the team understands.
• Upgrades applied without reading the release notes, changing node semantics underneath working workflows.