X API v2 Migration: Define Fallback and Pagination Recovery

Recovery contract for an X API v1.1-to-v2 migration

A service moving from Twitter API v1.1 to X API v2 needs an explicit recovery contract for paginated reads and side-effecting writes. The versions are not interchangeable contracts: endpoint coverage, response fields, errors, authentication requirements, and pagination behavior can differ, with availability dependent on the project’s current access tier.

The unresolved decision is whether a v1.1 fallback remains active during the v2 rollout, who owns its routing and deprecation, and how a failed cutover is distinguished from a transient request failure. For paginated v2 reads, the application must also define whether recovery resumes from the last successful token or restarts the query. A write timeout leaves the outcome ambiguous, so retry policy depends on reconciliation rather than assuming rejection.

Assume a v1.1 integration is being replaced by v2, with endpoint availability and scopes checked against current documentation and the project console. Validation should cover representative reads and writes, pagination-token failure, timeout behavior, and deployment rollback without assuming feature parity.

• Should the v1.1 fallback remain during the v2 rollout, and which component owns it?
• Should a paginated v2 read resume from its last successful token or restart?
• What reconciliation boundary should precede retrying an ambiguous write?