ERP API Integration Explained: REST, Webhooks, Auth and Idempotency
A plain-English explanation of ERP API integration: REST APIs, webhooks, authentication methods, idempotency, pagination, rate limits and error handling.
Service · Data & Integration
Overview
Integrations remove that manual work, but only if they are built to run unattended. The common failure is not that an integration never worked — it is that it failed silently for three days and nobody noticed until a customer complained.
01The problem
Customer addresses or product prices edited in both places, overwriting each other unpredictably.
An API token expires or a field changes, orders stop syncing, and nobody finds out until month-end reconciliation.
A timeout triggers a retry, and the order is created twice — once from each attempt.
Each system connected directly to every other system with scripts nobody fully understands.
02Our approach
Every integration starts with a data ownership map. For each entity — customers, products, prices, stock, orders, invoices, payments — we decide which system is the source of truth, which fields flow where, and in which direction. That single document prevents most of the problems we are later asked to fix.
We then choose a pattern suited to the volume and latency: event-driven webhooks for orders and payments, scheduled batches for catalogues and price lists, a middleware layer when several systems share data. Every write uses an idempotency key so retries are safe. Failures retry with backoff, then land in a dead-letter queue that someone can see, fix and replay.
03Capabilities
Orders, stock, products, prices, fulfilment and returns with Shopify, WooCommerce, Amazon and others.
Accounts, contacts, opportunities and quotes synchronised with Salesforce or HubSpot.
Payment matching, payouts, fees and refunds from Stripe, PayPal and bank feeds.
Journals and invoices to QuickBooks or Xero during transitions or for subsidiaries.
Shipment creation, labels, tracking numbers and proof of delivery.
APIs, databases, file drops, EDI and machines — whatever the other side offers.
04Technical considerations
Each message carries a unique key; the receiver ignores duplicates, so retries never create double orders or payments.
Exponential backoff with jitter for transient errors; permanent failures move to a visible queue with the error and payload.
Respect provider limits by batching changes and spreading load, rather than firing one call per stock movement.
Structured logs searchable by order number or SKU, metrics on throughput and failures, and alerts to a named owner.
05Process
Systems, entities, volumes, data ownership and direction of sync.
Integration pattern, field mapping, error handling and monitoring approach.
Connector development with tests against sandbox APIs and realistic data.
Volume tests, failure simulation (timeouts, bad data, expired tokens) and reconciliation.
Go-live with monitoring and alerting, and a runbook for common failures.
06Outcomes
Orders, payments and stock move between systems automatically.
When something breaks, the right person knows within minutes and can replay the message.
Clear ownership rules stop systems overwriting each other.
Where it applies
Related services
Insights
A plain-English explanation of ERP API integration: REST APIs, webhooks, authentication methods, idempotency, pagination, rate limits and error handling.
How to integrate an ERP with eCommerce, CRM, payments and other systems: data ownership, integration patterns, middleware, error handling, monitoring and common failure modes.
How to integrate RFID readers with Odoo inventory: middleware design, mapping EPCs to products and serials, receiving and counting flows, performance and what to build vs buy.
FAQ
Evaluate the existing connector first against your rules for customers, taxes, variants and fulfilment. If it fits with little modification, use it. If it needs heavy changes, a purpose-built integration is usually cheaper to own.
Orders and payments generally benefit from near-real-time sync. Catalogues, price lists and reconciliations are usually fine in batches. Real-time everything adds cost and fragility without much benefit.
Alerts go to a named owner on your side and, under a support plan, to us. Each integration has a short runbook explaining common failures and how to resolve them.
Often, yes — through database access, scheduled file exports, email parsing or, as a last resort, controlled screen automation. We will explain the tradeoffs of each.
Consultation
List the systems and the data. We will outline the architecture, the risks and the effort.