agent merged two different providers' docs - the generated client sends Stripe-style ids to a non-Stripe API

Isolate each provider's docs and conventions in the agent's context: ID formats, error shapes, and field names must come from one provider only. Audit the generated client for cross-provider patterns - prefixes like cus or in sent to a non-Stripe API are the classic tell - and replace each with that provider's real documented format.

agent merged two different providers' docs  -  the generated client sends Stripe-style ids to a non-Stripe API

Steps

1. Choose the one provider's docs as the single source of truth. Remove the other provider's docs, guides, and examples from the agent's context and working files so the blend cannot continue.

Expected: Only one provider's docs remain in context.

1. Grep the generated client for foreign patterns: ID prefixes from the wrong provider, field names the provider never documents, and error-handling code shaped for the other API.

Expected: You have a list of every foreign convention in the client, with file and line.

1. Replace each foreign pattern with the provider's documented equivalent. Check the IDs or objects section of their reference for the real formats - do not guess from memory.

Expected: No ID prefix, field name, or error code from the wrong provider remains.

1. Re-run the integration tests and confirm IDs validate, fields parse, and error handling matches the real provider's shapes.

Expected: Requests validate against the real provider and no foreign patterns remain in the client.

Use this when

• generated code mixes conventions from two different providers
• IDs or fields look like another API's format, for example Stripe-style prefixes on a non-Stripe API
• the agent was given both providers' docs in one context window

Not for this skill when

• one provider's docs are stale relative to their live API - that is drift, a different fix
• the integration genuinely talks to two providers - keep them in separate modules instead
• the format is wrong but only one provider was ever involved - check for training-data pattern matching

Variant phrasings

wrong provider ID format

Stripe-style ids wrong API

mixed API conventions

merged provider docs

Why it happens

When two providers' docs share a context window, the agent blends them, especially for things that look interchangeable like ID formats and pagination styles. Stripe conventions are overrepresented in training data, so they win the blend by default: the agent reaches for cus_ the way it reaches for common words. Each individual line looks reasonable, which is why review misses it.

Edge cases

• Some providers intentionally mimic Stripe's format - verify against their docs before rewriting
• Multi-provider integrations need strict module boundaries: one client module per provider, no shared ID helpers
• Shared HTTP helpers and middleware can leak conventions between providers - keep them convention-free
• Error-code handling is the sneakiest blend: retry logic written for one provider's codes misfires on the other's

Provenance

Resolved from the public thread: https://vectle.com/posts/pstiaxiDELSC3EcAhIH-qTlg