API integrations: risks and how to limit them

01 — Risks

What can go wrong

• The system answers incorrectly. Containable by having it work exclusively from verified content and escalate when uncertain rather than guess. This is a configuration decision, not a property of the technology.
• The effort is underestimated. Most common reason: unclear starting situation. An honest assessment of the current state before the proposal prevents this more reliably than any buffer.
• No one maintains it. The biggest risk of all — and the most easily avoidable.
• Data protection gaps. Almost always arise from missing deletion deadlines and unclear responsibility, rarely from the technology itself.
• Vendor lock-in. Avoidable if access credentials, data, and documentation contractually remain with the client.

02 — Warning signs

When to be skeptical

• Guaranteed results. Anyone promising top Google ranking or a specific revenue increase is selling something they can't deliver.
• No pushback. A provider who thinks every project is a good idea has either not listened or is only selling.
• Time pressure. Limited-time discounts on project prices are a sales tool, not an offer.
• Unclear ownership. Anyone who won't clearly say who owns data and access doesn't have your interests at heart.
• No contact with technical expertise. If only sales sits in the first meeting, that's where misunderstandings arise.

03 — Contract

What needs to be clarified in writing

• Ownership of data and access. They belong to the client. If a provider won't clearly confirm this, that's the most important information from the conversation.
• Handover upon termination. In what format, within what timeframe, at what cost.
• No minimum term without consideration. Lock-in is justifiable if something is delivered in return — otherwise not.
• What a later change costs. The total cost isn't determined by the project price, but by the hourly rate in year three.
• Documentation as a deliverable. Not as a promise, but as a line item in the proposal.