Integrate a third-party API with AI: contracts, limits and observable failures

A worked example: where the task becomes difficult

A fictional app wants to show delivery estimates from an external service. The generated integration includes a button linking to the provider homepage and a fake successful response. The real task needs account configuration, an authenticated operation and verified result mapping. Begin with a provider-supported test or read-only request and record which capabilities the account actually allows.

Decisions to make before implementation

Separate provider discovery, credential configuration, account permission and operational connectivity. Use official documentation rather than guessed endpoint paths. Validate returned fields and handle changed or missing values. Set timeouts, retry policy and request budgets appropriate to the operation. Do not automatically repeat writes after uncertain responses without an idempotency or reconciliation strategy.

A practical sequence for the work

Use the sequence below as a task boundary, not as a claim that the example has been executed. Work with approved inputs and the project’s actual architecture. If a required integration or permission is unavailable, keep that stage visibly incomplete rather than generating a plausible substitute result.

• Read the actual provider contract and verify the intended account capability.
• Configure the narrow required credential through protected storage.
• Implement one operation with response validation and bounded errors.
• Run a controlled request and show connected, unavailable or incomplete state honestly.

A detailed brief you can adapt for your agent

Replace the illustrative context with your approved facts and controlled inputs. Keep the stated boundaries when adapting the brief. The expected deliverable matters more than a particular tool name: ask for an explanation grounded in the inspected material and evidence for the requested outcome.

Implement one delivery-estimate operation from this provider’s current official API contract. Separate configuration, permission and connection states. Protect credentials, validate responses and bound timeouts and retries. Use a controlled request and do not invent a successful fixture as live data. Trace active routes before reporting any old integration removed.

Failure modes that an attractive preview can hide

An integration can be present in source but disabled or unconfigured in production. Conversely, removing a visible card does not remove active routes or dependencies. Trace imports, endpoints, configuration and live calls before claiming removal. Avoid exposing provider tokens in browser assets or logs while checking connection status.

Technical references: MDN: form validation

Acceptance checks and the evidence to retain

Keep the provider contract, protected configuration names, account scope and controlled response evidence. Connection status should describe what was actually verified.

Specific answers

Common questions