Migrating v2 to v3

This guide helps you migrate existing integrations from WeTravel Partner API v2 to v3.
It explains what changed, why it matters, and how to update your integration.

Overview

Partner API v3 introduces a cleaner, more consistent data model aligned with WeTravel’s internal
trip and payment systems. Compared to v2, v3:

• Uses a simpler, more consistent endpoint structure.
• Replaces many sub-resources with nested objects and arrays.
• Standardizes field naming.
• Removes explicit publish actions.

Migration requires updates to:

• Base URLs.
• Request payload shapes.
• Response payload shapes.
• Field names.
• Some filtering and pagination behavior.

Scope of this migration

This major version applies only to Trips and Payment Links APIs.
Other APIs such as Authentication, Leads, Suppliers, Bookings, and Transactions
are not part of this migration and remain on their existing structures.

Versioning policy (reference)

The Partner API is versioned using a major version in the base URL.
All endpoints for a given version share the same base path.

Example base URL:

https://api.wetravel.com/v3

Versioning policy:

• Major versions (v3, v4, …) may include breaking changes.
• Breaking changes are never introduced within the same major version.
• Minor and patch changes are backward-compatible.
• Additive changes can occur at any time. Clients should ignore unknown fields.

Deprecation

When a major API version is deprecated, it will remain available for a period of time
to allow partners to migrate. Deprecation timelines and migration guidance are
communicated in advance.

Base URL changes

Example:

• v2: /v2/draft_trips
• v3: /v3/trips

Breaking changes summary

Structural changes

• Requests are no longer wrapped in { data: { ... } }.
• Many sub-resources are replaced with nested arrays and objects.
• Separate publish endpoints are removed.

Naming changes

• Many legacy field names are renamed for consistency.

Behavioral changes

• Trips and payment links are published immediately on create and update.
  • In v2, trips were drafts and required an explicit publish call.
• Pagination defaults changed.
• Filtering parameters changed.

Pricing units

All pricing and currency rules for Partner API v3 are documented in the
Pricing and currency units guide.

Refer to that guide for exact validation rules and examples.

Endpoint mapping (v2 → v3)

Trips

Payment links

Trips: request and response changes

Pagination and filters

⚠️ Important: If you rely on default pagination, you must explicitly set per_page in v3
to avoid incomplete data retrieval.

Trip field mapping (v2 → v3)

Sub-resources replaced by nested fields

Payment links: request and response changes

Behavioral changes

• No publish_status.
• No publish_immediately.
• Created payment links are immediately usable.
• Updates use PATCH, not PUT.

Payment link field mapping

Example requests

List trips (v3):

GET /v3/trips?page=1&per_page=25
Authorization: Bearer <ACCESS_TOKEN>

Get trip:

GET /v3/trips/{uuid}
Authorization: Bearer <ACCESS_TOKEN>

Create trip (simplified example):

{
  "title": "Epic London Trip",
  "external_id": "LON-2026",
	"description": "Test",
  "currency": "USD",
  "start_date": "2027-05-07",
  "end_date": "2027-05-12",
  "min_people": 1,
  "max_people": 25,
  "destination": {
    "title": "London"
  },
  "trip_options": [
    {
      "name": "Standard Package",
      "type": "package",
      "price": 150000
    }
  ]
}

List payment links:

GET /v3/payment_links
Authorization: Bearer <ACCESS_TOKEN>

Create payment link:

{
  "title": "Deposit payment",
  "external_id": "LON-DEP-001",
  "currency": "USD",
  "package": {
    "price": 50025,
    "deposit": 20050,
    "payment_plan": {
      "allow_partial_payment": true,
      "installments": [
        { "amount": 15025 },
        { "amount": 15025 }
      ]
    }
  }
}

Migration checklist

• Update base URLs to /v3.
• Remove { data: { ... } } request wrappers.
• Rename legacy fields.
• Replace sub-resource calls with nested payloads.
• Remove publish calls.
• Update pagination defaults.
• Expect additive fields. Not all response fields may be documented immediately; clients should ignore unknown properties.

Compatibility guidance

• All request fields are documented in the UI.
• Response fields may evolve over time; treat newly added fields as additive.
• Avoid breaking on unknown properties.
• Expect richer responses in v3.

Testing and validation tips

After migration:

• Verify trip counts match between v2 and v3.
• Confirm payment links work end-to-end.
• Test pagination edge cases.
• Compare one migrated trip field-by-field.

Notes and assumptions

• Publish behavior in v3: Trips and payment links are published immediately upon create/update.
• Deprecation timelines: Not specified in current docs/code. Contact support for confirmation.

Need help?

If anything in this guide does not match your use case or current behavior,
contact WeTravel support before deploying to production.

Final note

This migration is structural, not cosmetic.
Plan time for careful testing before deploying to production.