When an integration works, nobody notices it. Leads appear in the CRM, payments mark orders as paid, couriers get shipments and invoices reach the accounts team. When it breaks, the damage is often silent - until a customer calls asking why they were charged twice, or a salesperson realises they have not received a website lead in ten days.
After years of building and fixing integrations, we see the same mistakes again and again. Here are twelve of them, with the habit that prevents each.
Design mistakes
1. Automating before mapping the process
The most expensive mistake happens before any code is written. Teams connect tools based on what the APIs can do, not on how the business actually works. The result: an integration that technically runs but does not match real workflows, so staff work around it.
Prevent it: write down the process step by step - who does what, in which system, with which data - and agree on it with the people who do the work. Then design the integration.
2. No single source of truth
If both the CRM and the accounting software can edit a customer's GSTIN, which one is correct when they disagree? Without a rule, two-way sync becomes a loop of overwrites.
Prevent it: for each type of data, decide which system owns it. Customer contact details might belong to the CRM, invoice data to accounts, stock levels to the inventory system. Other systems read from the owner.
3. Careless field mapping
"Name" in one system may be a single field; in another it is "First name" and "Last name". Phone numbers may be stored with or without +91. States may be names in one tool and codes in another. Map every field explicitly and decide how to transform it.
Prevent it: create a mapping table before building:
| Source field | Target field | Transformation | Required? |
|---|---|---|---|
| full_name | first_name, last_name | Split on first space | Yes |
| mobile | phone | Add +91 if missing, remove spaces | Yes |
| state | state_code | Convert name to GST state code | For invoices |
| city | city | Trim, title case | No |
Reliability mistakes
4. No handling of duplicates
Webhooks can be delivered more than once - providers retry when they do not get a quick success response. Requests can be retried after a timeout. Without protection, you create duplicate orders, send duplicate WhatsApp messages or double-count payments.
Prevent it: make processing idempotent. Store the unique event or payment ID, and if you have already processed it, acknowledge and skip. Where an API supports idempotency keys, use them for create requests.
5. Doing slow work inside the webhook
Some integrations receive a webhook and then, before responding, call three other APIs, generate a PDF and send an email. If any step is slow, the provider times out, marks the delivery failed and retries - creating more load and more duplicates.
Prevent it: acknowledge the webhook quickly, then put the work into a queue and process it in the background.
6. No retries, or retries without limits
APIs fail temporarily - network issues, maintenance, rate limits. An integration that gives up on the first failure loses data. One that retries instantly and endlessly can hammer an API and get blocked.
Prevent it: retry with increasing delays (exponential backoff), stop after a sensible number of attempts, and move failed items to a "dead letter" list that a person reviews.
7. Ignoring rate limits
Most APIs limit how many requests you can make in a period. Bulk syncs - importing a full product catalogue, backfilling old leads - often hit these limits and fail halfway.
Prevent it: read the limits in the documentation, batch requests where the API allows it, respect rate-limit response headers and spread large jobs over time.
Security mistakes
8. API keys in the wrong place
We still find secret keys inside website JavaScript, mobile app bundles, public code repositories and WhatsApp messages between staff. Anyone who finds a secret key can act as your business on that service.
Prevent it: keep secrets on the server, in environment variables or a secrets manager. Use separate keys for test and live environments. Rotate keys when exposed and when people with access leave. Use publishable keys only where the provider designs them for front-end use.
9. Trusting webhooks without verification
A webhook URL is just a web address. If you mark orders paid whenever a request arrives at it, someone could fake a payment notification.
Prevent it: verify the webhook signature using the secret the provider gives you - payment gateways such as Razorpay document how to do this. For payments, also confirm the payment status with the gateway's API before fulfilling.
10. Sharing more data than needed
Sending complete customer records - addresses, purchase history, notes - to every connected tool multiplies privacy risk. Under India's DPDP Act 2023, businesses should collect and process personal data for a clear purpose, which makes minimisation a sensible default.
Prevent it: send each system only the fields it needs, give API credentials the minimum permissions required, and keep a simple record of which systems receive which personal data. Our cyber security team can review integrations that handle sensitive data.
Operations mistakes
11. No logging or alerts
The most common reason integration problems last for weeks is that nobody knows they exist. An expired token or a changed field quietly stops data flowing.
Prevent it:
- Log every sync attempt with a timestamp, record ID and result
- Alert a named person by email or WhatsApp on repeated failures
- Run a daily reconciliation: compare counts between systems - orders in the store vs orders in accounts, leads in forms vs leads in the CRM
- Keep a simple dashboard showing the last successful sync for each flow
Hosting integrations on properly monitored infrastructure helps here; our cloud and DevOps team sets up logging, alerts and uptime checks.
12. No documentation or ownership
Six months after launch, the developer has moved on, the API key is in someone's personal email and nobody remembers which tool sends the "order shipped" message.
Prevent it: document every integration - systems involved, triggers, field mapping, where credentials live, who owns it, and what to do when it fails. Keep accounts and keys under business ownership, not personal logins.
A quick health check for existing integrations
Answer yes or no for each integration you run today:
- Do we know which system owns each type of data?
- Is every webhook verified and processed idempotently?
- Are secrets stored only on the server?
- Do failures trigger an alert to a named person?
- Do we reconcile record counts regularly?
- Is there written documentation someone new could follow?
- Do we know which personal data each tool receives?
Every "no" is a risk worth fixing - most can be addressed in a short, focused piece of work.
Mistakes, symptoms and fixes at a glance
| Mistake | Symptom you notice | Fix |
|---|---|---|
| No process map | Staff work around the integration | Map and agree the process first |
| No source of truth | Records keep overwriting each other | Assign an owner system per data type |
| Poor field mapping | Wrong states, broken phone numbers | Write a mapping table and transform data |
| No duplicate handling | Double orders or messages | Idempotent processing using event IDs |
| Slow webhook handling | Repeated retries from the provider | Acknowledge fast, queue the work |
| No retry policy | Missing records after outages | Backoff retries and a review list |
| Ignored rate limits | Bulk syncs fail halfway | Batch, throttle and spread jobs |
| Exposed keys | Unexpected activity on accounts | Server-side secrets, rotation |
| Unverified webhooks | Fake events accepted | Verify signatures, confirm status |
| Over-shared data | Privacy exposure | Send only the fields needed |
| No logs or alerts | Problems found weeks later | Logging, alerts, reconciliation |
| No documentation | Nobody can fix or change it | Written runbook and business-owned access |
Key takeaways
- Map the process and decide the source of truth before connecting anything.
- Handle duplicates, queue slow work and retry with limits.
- Respect rate limits, especially during bulk syncs.
- Keep keys on the server, verify webhooks and share only the data each system needs.
- Log, alert, reconcile and document - silent failures are the real enemy.
Get your integrations reviewed
MetaFox Technologies is a Jaipur-based company with 6+ years of experience, 25+ in-house specialists and 1,500+ projects delivered. We build new integrations and audit existing ones for reliability and security. Book a free consultation and tell us which integrations worry you, or explore our API integration and automation services. A written scope and quote follow the call.
