Reconcile CRM and invoicing owner fields with HTTPS APIs and Data Tables

Quick overview Reconcile CRM billing details and invoice summaries using field ownership. This vendor-neutral template reads both current records, applies only source-owned differences through conditional REST adapters, verifies the target independently, and keeps a metadata journal for replay and uncertain-write review. How it works 1. An authenticated webhook accepts only an entity reference. Distinct source tokens choose CRM or invoicing ownership; the caller cannot supply field values or a destination URL. 2. The workflow validates the request and checks the entity journal. Unresolved intent or uncertain outcomes block new requests in either direction before provider writes. 3. Both normalized adapters return current records with strong ETags. The workflow compares only the authenticated source’s owned fields; matching values return unchanged without a PATCH. 4. For a valid difference, it persists and verifies a minimal intent row, then reads the source again. A changed or unavailable source becomes a no-write conflict. 5. It sends a per-field target PATCH with If-Match and an Idempotency-Key. Proven revision conflicts and uncertain outcomes are retained for review; an acknowledgement alone does not establish an applied result. 6. After a valid acknowledgement, an independent target GET must match the expected fields, revision and write marker. The final journal update is verified before returning applied. Missing, deleted or invalid records are held; records are never created or revived. Setup 1. Import inactive into n8n with Variables and Data Tables. In Workflow settings, explicitly confirm UTC, execution order v1 and Do not save for successful, failed and manual executions; editor imports may preserve destination settings. 2. Create ReconciliationJournal using the full schema in Additional info and select it in all three Data Table nodes. Configure distinct RECONCRMTOKEN and RECONINVOICETOKEN tokens plus RECONCRMBASEURL and RECONINVOICEBASEURL. The exact token and HTTPS URL constraints are documented below. 3. Create separate Header Auth credentials for the two adapters. Assign each to its four HTTP Request nodes. Implement both normalized REST adapters using the complete GET/PATCH contract below; ordinary vendor endpoints cannot be substituted by changing only the base URL. 4. Serialize the entire lane, including both directions, manual runs and retries. Use an upstream queue with one request in flight and wait for completion. Data Tables are not a transactional lock. Configure error monitoring and review of old intent or reconcilerequired rows. 5. Test synthetic records in isolated adapters: both directions, unchanged replay, malformed requests, missing/deleted records, source changes, target revision conflicts, uncertain writes, independent readback and journal failures. Only then connect trusted source events or a separate scheduler to the webhook. Requirements - Requires n8n Variables, Data Tables, the crypto built-in for Code nodes, two separately authenticated normalized REST adapters, strong revisions, provider-enforced conditional writes and durable idempotency, and serialized execution. Use CRM/customer records and mutable invoice summaries; do not rewrite issued fiscal documents. Uncertain writes require manual reconciliation. This is not a plug-and-play connector for a named CRM or accounting product. Customization - Map provider fields to the documented ownership policy and unique entity mapping. Trigger requests from source-system changes, an operator action or a separate scheduler. Use separate adapters, credentials and journals for different authorization scopes. The template does not include a scheduled scan or durable intake queue. Additional info It uses native n8n Webhook, Code, IF, HTTP Request, Data Table and Respond to Webhook nodes. There are no simulator tables, embedded provider credentials, community nodes, customer emails or invoice-creation actions. It imports inactive. Before choosing this