In this guide 6 sections
Ask how a failed sync is detected, who is alerted, what retries happen and how a rejected record is replayed. Then ask who fixes the link when a connected system changes its API, whether you receive the source code, and what documentation you keep if the relationship ends.
Ask what happens when a sync fails
Every integration fails sometimes. A vendor who says it will not is not being honest. Request a walk through of the last real failure on another project, with what broke and how long the fix took.
Ask where a failed record goes. A good answer names a queue, a log with the reason and a way to replay the message after the data is fixed. A weak answer is that someone will look into it.
Ask about the order of events. If message four fails, do messages five and six wait or pass through?
- Where does a rejected record wait?
- Can our staff read the reason without a developer?
- How is a message replayed once fixed?
- Do later messages queue behind a failure?
Ask about alerts and retries
A failure nobody sees is worse than one that is loud, and ask who receives the alert, by which channel, and at what point. An email to a shared inbox at midnight may not be read until Monday.
Ask about retry rules. A timeout may retry three times with growing gaps. A validation error should not retry at all. Ask how the vendor stops a retry creating a duplicate order.
Request a sample alert. Does it name the record, the system and the reason, or just say sync failed?
Ask who fixes it when a connected system changes
Vendors retire API versions, rename fields and change login methods. Ask how the partner learns of these changes. Do they subscribe to the changelog of each connected product?
Ask whether fixing such a change is inside the support agreement or billed as new work. Get the response time in working hours, and who answers when the person who built it is on leave.
Ask what happens when a connected product has no public API. A scraper or file drop may be the only route, and it breaks more often.
- Do you track API changelogs for each connected product?
- Is a vendor driven fix covered by support?
- What is the stated response time for a broken link?
- Who covers when the lead developer is away?
Ask about code, documents and ownership
Ask who owns the source code once the work is paid for. Ask where it is stored, whether you have access to the repository, and whether credentials sit in your accounts or the vendor’s.
Ask to see a sample of documentation: field mapping sheet, flow diagram, deployment steps and a runbook for common faults. Documentation that exists only in the developer’s head is a dependency.
Ask what a handover would look like if you changed partners. A confident vendor can describe it in a paragraph.
Compare answers, then test one
Put the same questions to every shortlisted vendor, in writing. Score each answer as specific, vague or evasive. Specific answers mention real tools, real file types and real past faults.
Then ask for one small proof. A single field mapped, a failure forced on purpose, and the alert shown on a screen, and watching a deliberate failure is more telling than any brochure.
Take the scored sheet to your reference calls and ask the previous clients about the same points.
Integration vendor question sheet
A one page scoring sheet. Rows hold the questions grouped as failures, alerts, API changes, code ownership and documentation. Columns record each vendor’s answer, a mark of specific, vague or evasive, and a note on the proof requested. A footer block lists reference calls made and the date.
Open a blank worksheet to printQuestions owners ask
Should I insist on getting the source code?
Request it, or a written escrow arrangement. Without access, you cannot move to another partner or keep the link running if the vendor closes.
How do I test a vendor’s error handling?
Ask them to force a failure in a demo, such as a rejected field or an offline target, and show the alert, the queue and the replay.
Is a monthly support retainer worth it?
Usually for links that touch money or stock. Check that API changes, monitoring and a named response time are written into it.
What documents should I receive at handover?
Field mapping sheet, flow diagram, credential list, deployment steps, a runbook of common faults and the repository access details.