REST, GraphQL, or MCP?
Connect AI products safely.

A startup ships an integration to close a customer gap. The first customer connects successfully. Then the second customer’s data appears in the first customer’s workflow, a revoked account keeps working through an old token, or a webhook retry creates the same record twice. The feature looked complete in a demo; the trust boundary was not.

These failures rarely come from choosing REST instead of GraphQL. They come from unclear identity, hidden assumptions about retries, credentials with too much reach, and no one owning the connection after launch. A founder pays for that gap in engineering interruption, support escalation, delayed procurement, and customer confidence. This guide shows where failures begin, what they cost, and how to engineer against them.

Choose the interface after defining the trust boundary

REST and GraphQL describe request/response interfaces. Webhooks carry provider events into your system. MCP lets AI hosts discover and invoke tools or retrieve context. They solve different communication problems; none decides whether a request is authorized or safe to repeat. First define who is acting, on whose behalf, and what the action is allowed to do.

One product can use all four. Identity, authorization, limits, audit, and recovery must remain coherent even when protocols differ.

Failure chain 1: one shared token quietly becomes cross-customer access

The shortcut: store one provider credential in an environment variable and use it for every workspace. It works, and there is no per-customer connection state to build.

How it fails: a request reaches the provider with the application’s broad credential, while your product relies on a customer ID parameter to filter records. One missing tenant filter, background job, or log replay can cross that boundary. The provider sees the same application identity for every customer and cannot enforce each customer’s narrower access.

What the startup pays: support escalation and a rushed permission audit; at worst, customer data exposure, notification and remediation work, a delayed security review, or a prospect declining to connect. One shared secret also creates a wide blast radius when leaked.

How Infoshyla handles it: establish tenant and user context at the integration boundary; store customer connections separately; request only required provider scopes; keep secrets server-side; and check tenant ownership on every read and write. Tests deliberately attempt cross-tenant access. Logs record connection and action while redacting credentials and sensitive payloads.

Failure chain 2: “connected” outlives the user’s permission

The shortcut: treat token acquisition as one-time setup. Save a token, let the client or agent reuse it, and treat expiry as a generic retry error.

How it fails: a user loses provider access but a cached token remains usable; a refresh token is shipped in a browser bundle; or an AI tool uses an application-wide identity where the action should be limited to the requesting user. Host authentication does not automatically authorize every tool operation inside your product.

What the startup pays: revoked employees may retain access, customer onboarding and offboarding become manual support work, and security reviews expose that the company cannot explain revocation. Engineers then rotate credentials across environments under incident pressure.

How Infoshyla handles it: map issuer, audience, scopes, expiry, refresh, storage, and revocation for each token. Keep confidential credentials on trusted servers. Enforce authorization at the service that performs the action, preserve delegated user context, and make disconnect and revoke flows observable. Sensitive agent tools check permissions server-side; prompts are not access controls.

Failure chain 3: retries repeat the business action

The shortcut: assume a provider sends each webhook once, or assume a request timeout means the write did not happen.

How it fails: your service creates an invoice, then crashes before acknowledging the event. The provider retries and creates another invoice. Or a timed-out user-creation request is retried and sends a duplicate invitation. Many delivery systems provide at-least-once delivery; duplicates are part of the operating model.

What the startup pays: duplicate charges or records, inconsistent CRM and product state, manual reconciliation, and engineering time spent reconstructing the event sequence. Customer trust takes longer to repair than the code.

How Infoshyla handles it: verify webhook signatures; persist event IDs before acknowledging; deduplicate deliveries; and make side-effecting operations idempotent with stable operation keys. Process long work asynchronously with bounded retries and a dead-letter path. Reconcile local state against provider state instead of assuming every event arrived.

Failure chain 4: provider slowness becomes your product outage

The shortcut: call the vendor inside a customer request, use a generous timeout, and retry immediately after failure.

How it fails: the provider rate-limits your app. Retries tie up workers, increase load, and make your own endpoints slow. Users retry too; duplicate work accumulates. A provider outage becomes your product incident.

What the startup pays: customer workflows stall, errors spread beyond the integration, and the team must choose between disabling the feature or risking corrupt state. A launch-critical path can miss its release window.

How Infoshyla handles it: set timeouts around the user experience; cap retries with backoff and jitter; respect provider limits; isolate work with queues or circuit breakers when appropriate; return a clear pending state; monitor provider health separately; and provide safe pause and replay controls.

What a secure integration should leave behind

A connector is not done when the happy-path request succeeds. Another engineer should be able to explain its boundary and operate it without reverse-engineering a production incident. Document:

• Identity map: user, tenant, application, and provider identities.
• Permission map: required scopes and server-side enforcement points.
• Secret lifecycle: storage, ownership, rotation, expiry, revocation, and redaction.
• Failure contract: limits, timeouts, retries, idempotency, replay, dead letters, and reconciliation.
• Operational view: traces and audit events without credentials.
• Recovery procedure: pause, revoke, repair state, and resume safely.

How Infoshyla handles integration work

We map the user journey and system boundaries before recommending a protocol or rewrite. We identify identities, data crossing each boundary, side effects, and provider failure behavior. Then we agree on an implementation slice and acceptance checks for expired credentials, cross-tenant requests, duplicate events, rate limits, and provider downtime.

We build around explicit contracts, least-privilege access, server-side authorization, bounded retries, and observable state. At handover, your team receives the integration flow, ownership notes, operational signals, and recovery steps with the feature.

This does not remove every provider risk. It makes the boundary explicit, narrows the blast radius, and gives the product team a way to detect and recover before a failure becomes a mysterious customer-data problem.

Vertical example: a conversational commerce order path

A sales assistant may read catalog and inventory data, qualify intent, create a draft order, generate a payment link, and later answer fulfillment questions. Each step touches a different trust boundary: the customer’s identity, the storefront account, the payment provider, and the order system. A single broad credential shared by all steps makes it difficult to limit blast radius or explain which component performed an action.

Map each operation to a principal, resource, scope, and business effect. A read-only product search should not inherit permission to mark an order paid. The payment provider’s webhook should be authenticated, deduplicated, checked against the expected amount and order, and recorded before the CRM status changes. A delayed or replayed event must not create a second fulfillment action. Token refresh should preserve the customer-to-provider connection boundary; revocation should stop future use and invalidate cached access where applicable.

Measure authorization denials, credential refresh failures, webhook verification and duplicate counts, provider throttling, incomplete cross-system transactions, and time to reconcile a pending order. Review these by provider and workflow. A high retry count may point to a bad backoff policy; a rise in pending orders may indicate a provider or reconciliation problem. The goal is not to expose every integration detail to customers, but to give operators enough evidence to locate the failed boundary without logging secrets or full payment data.

If the answer is “we’ll check the logs” or “the provider should only send it once,” the integration still has an unowned failure mode. Scope that engineering work before a customer discovers it for you.