Changelog

SIM Swap – eSIM and pSIM Support

The existing SIM Swap journey has been extended to support both eSIM and physical SIM (pSIM) as the target SIM type.

Previously, SIM Swap supported eSIM-to-eSIM swaps only. With this release, all SIM Swap combinations are supported:

• eSIM → eSIM
• eSIM → pSIM
• pSIM → eSIM
• pSIM → pSIM

The existing SIM Swap endpoint and order type remain unchanged.

This change applies to API versions 2025-01-28, 2025-07-31, 2026-02-05 and Next.

Non-Breaking Changes

• SIM Swap Order:

  The swap_subscription_sim order now supports an optional sim_profile object, allowing partners to explicitly specify the target SIM type.

  Supported values for sim_type are:

  • esim
  • psim

  When sim_type is set to psim, a reservation_id must also be provided to identify the reserved physical SIM.

• pSIM Reservation:

  Before performing a SIM Swap to a pSIM, the physical SIM must be reserved using the existing SIM profile reservation flow.

  The resulting reservation_id must then be included in the sim_profile object when submitting the SIM Swap order.

• Backward Compatibility:

  The sim_profile object is optional.

  Existing integrations that do not provide sim_profile will continue to use the existing eSIM-to-eSIM SIM Swap behavior without any changes.

MNP Netherlands — Early Termination and Continuation Support

Non-Breaking Changes

• Portings (all countries, port-out): A new processing object has been added to every port-out porting response (GET /portings, GET /portings/{porting-id}), containing action, an optional phone_number, and (for NL, ES, IE) processing_at.

  • processing.action mirrors the value previously exposed via the now-deprecated root processing_action field.
  • For NL specifically, processing.action can also be terminate_early, in addition to terminate and swap_phone_number.
  • Existing integrations reading the deprecated root fields are unaffected — this is purely additive.

• Portings (NL, port-in): Introduces an optional contract_action field inside donor_details when creating an NL port-in, controlling how the donor contract should be handled:

  • terminate_at_expiry — standard behaviour: terminate the donor contract if possible (default when omitted).
  • terminate_early — terminate the donor contract even if an active commitment exists.
  • swap_phone_number — keep the donor contract active and swap in a new phone number.

  Existing integrations that don't send this field keep getting the default terminate_at_expiry behaviour.

• Portings (deprecations): The root-level processing_action field (all countries) and processing_at field (NL, ES, IE) are now marked deprecated. They remain present and populated for backward compatibility — use processing.action and processing.processing_at instead going forward.

Scope

• API versions affected: 2026-02-05.
• Schemas affected: CreateDonorDetailsNL, PortingDonorDetailsNL (port-in), and every PortingOut*<COUNTRY> response schema (port-out) — DE, PL, NL, ES, GB, IE.

Example — Create Porting (NL) with contract_action

{
  "direction": "in",
  "country": "NL",
  "subscription_id": "subs_01JXHRZ848P7D1KMN3EK1P8RDE",
  "phone_number_id": "pn_01JXHRZ875YFVHHG4RPM704623",
  "msisdn": "+31651528362",
  "donor_details": {
    "account": {
      "account_number": "123456789"
    },
    "contract_action": "swap_phone_number"
  }
}

Example — Port-Out response processing object

{
  "processing_action": "terminate",
  "processing": {
    "action": "terminate",
    "processing_at": "2026-09-01T10:00:00.000Z"
  }
}

Summary of Changes

Subscription Deactivation Reasons

Connect API now supports an optional deactivation_reason when deactivating a Subscription.

The reason is retained as the Subscription progresses to a final state and cleared if it returns to active.

Supported reasons are:

The field is optional, so partners can continue to deactivate Subscriptions without providing a reason.

MNP Ireland - service_type for Port-In

Updates

• Portings (IE): Updates Ireland port-in account details to use service_type for donor account selection in create requests and returned porting resources.

  • service_type now accepts the previous IE donor account values: prepaid_unregistered, prepaid_registered, prepaid_multi_line, postpaid_single_line, and postpaid_multi_line.
  • service_type also accepts the generic values prepaid and postpaid.
  • account_number is required for postpaid, postpaid_single_line, and postpaid_multi_line.
  • Submitting prepaid or postpaid allows IE port-in retry to try the configured account variants after eligible donor account-type rejections.
  • Submitting one of the previous five specific values sends that exact donor account variant and no account-type retry is attempted.
  • IE porting responses now return the donor account selection in donor_details.account.service_type.

  This change applies to API versions Next and 2026-02-05.

Added brand field for embedded Service Provider in Porting Contracts

The embedded Service Provider object returned within Porting Contracts now includes a new optional brand field, used to identify the internal porting brand associated with the service provider.

Non-Breaking changes

• Service Provider (embedded in Porting Contracts):
  Added the optional brand field to the embedded Service Provider object. This field is populated for internal porting identification purposes and does not affect existing integrations.

Phone Number can be created in terminating status

• Subscription:
  Introduces support for creating phone numbers in a terminating status during port-in operations. The supported phone number status depends on the API version:

  API Version	Phone Number Status
  Earlier than 2025-07-31	terminated
  2025-07-31 and later	pending_termination

  This change applies to all API versions. The phone number status differs based on the API version.

MNP Netherlands — Smart Validation

Non-Breaking Changes

• Portings (NL):
  Introduces smart validation as an alternative path for creating a port-in in the Netherlands. A verification_id (obtained from a completed Verification session) can now be provided instead of donor_details.

  • donor_details and verification_id are mutually exclusive — provide exactly one.
  • Existing integrations using donor_details continue to work without modification.

  This change applies to API version 2026-02-05 and Next.

Changes

The service_provider_id field inside donor_details of the Create Porting (ES) request body (CreatePortingES / CreateDonorDetailsES) is now optional.

Previously, service_provider_id was required when creating a porting request for Spain (country = "ES"). With this update, partners may omit the field and let the Connect API resolve the donor service provider automatically.

This is a non-breaking change. Requests that continue to include service_provider_id are processed exactly as before — the supplied value is used as-is and no lookup is performed.

Scope

• API versions affected: 2026-02-05.
• Schema affected: CreateDonorDetailsES (Spain only).
• Other countries (DE, IE, NL, PL, UK, …) and other porting schemas are not affected.

Example — Create Porting (ES) without service_provider_id

{
  "direction": "in",
  "subscription_id": "subs_01J9XJ11WTYFWFH5JD2YM1S18S",
  "msisdn": "+34612345678",
  "country": "ES",
  "preferred_schedule": {
    "type": "specific_date",
    "preferred_porting_at": "2026-06-10T09:00:00Z"
  },
  "donor_details": {
    "account": {
      "type": "personal",
      "service_type": "prepaid",
      "iccid": "8934075500001234567"
    }
  }
}

When service_provider_id is omitted, porting resolves the donor service provider. If the lookup cannot identify the donor, the porting request will be rejected with the usual validation error and the caller may retry by supplying service_provider_id explicitly.

Summary of Changes

New preferred schedule type option first_possible_date for Port-In

This feature introduces support for the first_possible_date preferred_schedule.type option across all countries except NL where the partner does not provide a preferred schedule on porting creation.

When the first_possible_date option is selected, the system will automatically determine the earliest possible porting date based on country-specific constraints, regulatory requirements, and operational availability. This computed date will then be used as the official scheduled porting date.

When the first_possible_date option is selected in the Port-In request, the response will indicate the preferred schedule type as first_possible_date, and the computed scheduled porting date will be returned in the preferred_porting_at field of the response.

Non-Breaking changes

• New preferred schedule type option first_possible_date for Port-In:
  The new option first_possible_date can be selected as the preferred schedule type in Port-In request. The other existing options for the preferred schedule type are still valid and remain unaffected and work as before.

New Order Reason Field

Connect API now supports an optional order_reason field for Orders and Order webhooks.

This field provides additional business context about why a specific order was created.

The new field is currently populated for:

• Quick transfer SIM swap flows on iOS
• Activation orders with porting
• Payment overdue flows for prepaid subscriptions
• Downgrade flows from voice plans to data-only plans

This enhancement improves observability for partners integrating advanced subscription lifecycle and recovery flows.

Supported Order Reasons

The following values are currently supported:

API and Webhook Changes

The Order resource and Order webhooks now support:

order_reason:
  type: string
  description: The Order reason
  enum:
    - quick_transfer
    - porting
    - payment_overdue
    - inactivity_downgrade

New Physical SIM Activation Support

Connect API now supports physical SIM (pSIM) activation journeys using activation codes and SIM Profile reservations.

Partners can now:

• Reserve a Physical SIM Profile using an activation code
• Activate subscriptions using a reservation_id
• Retrieve Physical SIM Profile details
• Retrieve Physical SIM and PUK information through dedicated APIs

This extends the existing activation order flow to support physical SIM onboarding.

Physical SIM Activation Flow

The Physical SIM activation journey now follows this flow:

1. Partner creates a Physical SIM Profile reservation using the activation code printed on the physical SIM package
2. API returns the reserved Physical SIM Profile information and a reservation_id
3. Partner creates an activation order using sim_type = "psim" and the returned reservation_id
4. Partner may later retrieve Physical SIM Profile details and PIN/PUK information when needed

Key Capabilities

Physical SIM Profile Reservation

A new Physical SIM Profile reservation endpoint allows partners to start the Physical SIM activation journey using an activation code.

POST /sim-profiles/reserve

The reservation response includes:

• Physical SIM Profile details
• reservation_id
• Reservation expiration timestamp

Physical SIM Activation Orders

Activation orders now support Physical SIM activation using a reservation reference.

{
  "type": "activate_subscription",
  "subscriber_id": "subr_01HXF4F4VYTCPVMBPBK3T52TN7",
  "purchase_location": "CA",
  "sim_profile": {
    "sim_type": "psim",
    "reservation_id": "resv_01HV3KWPNRCT870WV3XG41CAT3"
  },
  "products": {
    "plan": {
      "product_offering_id": "prdoff_01HRD00B0K1EPRZ9WEVGEMUIJ6E"
    }
  }
}

When sim_type = "psim", reservation_id becomes mandatory.

Physical SIM Profile Retrieval

Partners can retrieve Physical SIM Profile details using:

GET /sim-profiles/{sim-id}

For Physical SIM profiles, the response includes reservation-related information and SIM status details.

PIN/PUK Retrieval

Partners can retrieve the original PIN and PUK associated with a Physical SIM Profile using:

GET /sim-profiles/{sim-id}/secret-codes

This supports customer service and SIM recovery journeys.

Summary of Changes

MNP Ireland

We are introducing Mobile Number Portability (MNP) support for Ireland. This implementation enables customers to move their mobile numbers between service providers in compliance with the Irish recipient-led porting model.

The system supports both Port-In (importing a number into your network) and Port-Out (exporting a number to another provider) processes, including full lifecycle management, validation, and status tracking.

Non-Breaking Changes

• IE-Specific Porting Schemas
  Added Ireland-specific request and response schemas to support regulatory and operational requirements for MNP. These include validation rules, rejection reasons, and lifecycle states tailored to the Irish market.

Notes

• This release does not introduce breaking changes to existing APIs.
• The new functionality is additive and applies only to Ireland (IE) porting flows.
• Existing integrations remain unaffected unless explicitly adopting MNP features.

Add new Webhook Throttling Lifted on Products

Non-Breaking changes:

To keep our partners fully informed about their product status, we now send webhook notifications whenever throttling is lifted:

• product.throttling.applied : Triggered when product throttling is applied.
• product.throttling.lifted : Triggered when product throttling is lifted.

These notifications ensure an up-to-date view of product throttling.

MNP United Kingdom and Porting Authorization

We are introducing Mobile Number Portability (MNP) in the United Kingdom. This implementation enables customers to move their mobile numbers between providers while complying with the UK’s donor-led porting model. The system supports Port-In, Port-Out, PAC and STAC requests, along with the necessary Porting Authorization handling and related webhooks, ensuring a compliant and efficient porting process for UK customers.

Non-Breaking changes

• UK-Specific Porting Schemas:
  The system now supports Mobile Number Portability (MNP) in the United Kingdom, allowing customers to port their mobile numbers between providers while adhering to the UK’s donor-led porting model. This includes handling Port-In and Port-Out requests, as well as managing PAC (Porting Authorization Code) and STAC (Service Termination Authorization Code) requests, ensuring a seamless and compliant porting experience for customers in the UK.

• Porting Authorization APIs/Resources:
  New Porting Authorization APIs have been introduced to support end-to-end lifecycle management of PAC and STAC requests. These APIs provide capabilities to create, retrieve (get), list, cancel, and close porting authorization records, ensuring complete operational control and visibility over the porting authorization process within the system.

• New Webhooks for Porting Authorization:
  To support PAC and STAC requests, the system introduces a Porting Authorization component that manages the creation and lifecycle of these authorization codes. When a customer requests a PAC or STAC, a corresponding Porting Authorization record is created and maintained in the system. Additionally, related webhooks are implemented to notify external systems about important events and status changes associated with the Porting Authorization process, ensuring proper coordination and timely updates during porting and service termination workflows.

New Activation Order Type for Port-In

A new order type has been introduced to support subscription activation using a ported-in number, allowing partners to onboard users without issuing a temporary MSISDN.

Orders created with on_hold_condition = porting now enter an On Hold state immediately after subscription creation. This gives partners full control to start and manage the port-in process while the order waits safely.

Key Capabilities

Non-Breaking Changes

New On-Hold Order Flow

• A new order flow allows activation to pause until the port-in is completed.
• Partners receive the subscription via webhook and can initiate the port-in whenever appropriate.

New Webhooks

• order.on_hold – triggered when the order enters On Hold.
• Existing porting webhooks (e.g., porting.completed, porting.failed) now apply naturally within this flow.

Manual Resume Supported

Partners may manually resume the order using:
POST /orders/{orderId}/resume

• If port-in is completed → activate with ported MSISDN
• If not completed → fallback activation using a temporary MSISDN

Automatic Resume (Optional)

Automatic resume of the order after port-in completion can be enabled.
Partners must request this configuration through support so we can enable it server-side.

Breaking Changes ⚠️

The following breaking changes are introduced from version 2026-02-05 onwards:

• The Pending First Usage product status has been replaced by a generic Pending status
• A new reason field is introduced to differentiate activation flows:
  • First Usage Activation
  • Activation with Porting

MNP Netherlands & Spain

Mobile Number Portability (MNP) has been introduced for both the Netherlands and Spain, enabling users to seamlessly port their MSISDN both into and out of the network. With this release, customers in these markets can now migrate existing mobile numbers from other operators (port-in) as well as transfer their numbers to external providers (port-out), ensuring full number portability support.

MNP Netherlands

Breaking changes ⚠️

• Portings: Additional fields have been added to porting-related contracts to ensure clearer separation and prevent specification mappings from being incorrectly associated with other objects during end-to-end (E2E) flows. Introduced timestamp fields for lifecycle states applicable to both port-in and port-out:

  • pending_at for the Pending status
  • processing_at for the Processing status

Non-Breaking changes

• New Webhooks for Porting:
  To support the agreed status for port-out requests in the Netherlands, a new webhook has been introduced to notify downstream systems when a port-out reaches the agreed state.

MNP Spain

Non-Breaking changes

• Subscribers:
  Adds an identifications object to support richer subscriber identity data. This is primarily used for KYC and portability requirements.

  • Identification types for Spain:
    • NIE (Número de Identificación de Extranjero)
    • Tax Id (Número de Identificación Fiscal)
    • Passport (existing identification; optional nationality field added)

Removal of unsupported fields from Phone Number schema

Non-Breaking Changes

Removed the port_out_expires_at field from the Phone Number schema when the status is terminated, as this field was not part of the contract definition.

This release introduces a new response header: Idempotent-Retriable.
It helps API consumers understand whether an unsuccessful request (HTTP 4XX or 5XX) that included an Idempotency-Key can be retried using the same key.

Change summary:

• Header (Response): Idempotent-Retriable
  • true: The request can be retried with the same idempotency key.
  • false: The request should NOT be retried with the same idempotency key.
    Subsequent attempts will return the same result.

We've introduced a new ended_at field in Subscriptions, which records the timestamp when a subscription ended and more specifically, when its status changed to TERMINATED or CANCELED during its lifecycle.

A new optional metadata field is now supported on Account creation and update.

This enhancement allows partners to store tenant-specific key/value information (e.g. affiliate identifiers) directly on the account entity. The metadata is persisted and returned in account retrieval endpoints, without impacting existing consumers that do not use this capability.

A new optional field, metadata, has been added to the Product Offering API. This key-value pair allows partners to add or remove custom metadata and information of their choice within an existing product offering. This is a non-breaking change.

A new addon validity type has been added: end_of_plan_cycle. With this validity type, the addon is set to expire at the end of the current billing cycle, no matter how many days there is before the end of the billing cycle.

To ensure that our partners remain fully informed about the status of their prepaid product renewals, we now send webhook notifications whenever a renewal is completed or terminated. These notifications help maintain an up-to-date view of the renewal lifecycle.

This release introduces idempotency guarantees for selected non-idempotent methods (POST and PATCH).

Partners can now safely retry requests using the Idempotency-Key header without risk of duplicate processing. If a request with the same Idempotency-Key has already been processed, the API skips execution and returns the cached response with the header Idempotent-Replayed: true.

Change summary:

• Header (Request): Idempotency-Key (UUID v7 or ULID format recommended)
• Header (Response): Idempotent-Replayed (true for cached response, false for original)
• Retention: Keys stored for 24 hours

Refer to the "API Reference" for endpoints supporting this feature.

This release introduces enhancements to the management of prepaid subscription lifecycles, including the addition of “Renewals” and “Renewal Groups”. These features allow partners to retrieve the renewal status of prepaid products and update renewal details as needed.

Extended the Credit Note API to support creation of credit notes. Previously, only retrieval (GET) operations were available; partners can now issue new credit notes to adjust finalized invoices.

• New Order Type: Partners can now trigger a product cancelation order for an active subscription using the new cancel_subscription_products order type. This enables users to cancel multiple products in a single request. Product cancelation can be executed immediately (specific_date) or scheduled for the end of the current billing cycle (end_of_cycle).

• Add payment_intent_id to Orders API: A new optional field, payment_intent_id, has been added to the Order API: Activate, Top Up and Change Plan Orders. This field links an order to its successful payment intent, improving payment reconciliation for partners using our payment checkout. This is a non-breaking change.

This release introduces a number of breaking changes that may require updates to your integration. Please review the full changelog carefully to assess the impact on your systems. Key changes include removed fields, modified field requirements

In addition to the breaking changes, this release also brings several new features and enhancements across billing (invoices, credit notes), porting, subscription, and account APIs. These improvements are designed to give partners greater flexibility, better visibility, and more control over lifecycle events.

Breaking changes ⚠️

• Product Offerings: Adds a new category field for product offerings of type addon, with possible values: allowance and additional_phone_number.

• Portings: Replaces termination_action field by processing_action to better reflect available actions during port-out.

Non-Breaking changes

• Portings: Adds all portability flows for Poland. New required field cancelation_requested_at was added for portings in DE in status cancelation_requested.

• Credit Notes & Files APIs: Introduces new API functionalities for managing credit notes and uploading/retrieving files via the API. These provide additional billing and documentation flexibility for portability.

• Invoices : You can now retrieve the details of a specific invoice item, allowing for more granular billing visibility and easier reconciliation.

• Product Offerings: Adds a refundable field to indicate whether a product offering is eligible for refunds.

• Orders: Expands support for non_service product offerings and phone_number objects.

• Accounts: Adds billing_address object to the object owner and regonfield for business accounts

• Subscribers: Adds intentifications object to support richer subscriber identity data. This is primarily used for KYC and portability requirements.

• New Webhooks for Invoice, Subscriptions, Phone Numbers and Porting : To keep partners fully informed, we now send webhook notifications for phone numbers lifecycle changes , invoice paid, Poland porting lifecycle and subscription sim profile country changed.

We’ve introduced several important updates to improve the flexibility and lifecycle management of subscriptions and products via the API. These enhancements respond to partner feedback and enable smoother customer experiences across multiple use cases:

• New Order Type: Partners can now trigger a plan change for an active subscription using the new change_plan order type. This enables users to upgrade or downgrade their plan. Plan changes can be executed immediately (specific_date) or scheduled for the end of the current billing cycle (end_of_cycle).

• Cancel Scheduled Orders: We’ve added the ability to cancel scheduled orders before they are executed. This provides flexibility in managing future changes that are no longer needed.

• Webhook for Canceled and Expired Products: To keep partners fully informed, we now send webhook notifications when an order is canceled or when the products expired. This helps maintain an up-to-date view of the subscription lifecycle and ensures accurate user-facing status.

• RLAH Support and Webhooks: Products now support Roam Like At Home (RLAH) as part of the product offering configuration. A webhook is triggered when usage crosses defined thresholds, helping partners monitor consumption and inform users in real time

This API update introduces code and brands for service providers, and code for network operators. Additionally, embedded service providers and network operators in porting have been extended to include code.

This API update introduces the ability for partners to use a new Order type for eSim Swap, swap_subscription_sim, for a specific subscription ID. This addresses customer requests where an eSIM is lost, or a user changes their phone, allowing for easy replacement via a new eSIM. This order triggers the issuance of a new eSIM profile, seamlessly transferring the existing product and phone number, and notifies partners upon completion with the new ICCID ready for installation.

We've expanded the subscription status options by adding new enum values. This update provides greater flexibility and more precise status tracking, ensuring better alignment with real-world subscription states.

We’ve made important updates to our subscriber resource. The address object now includes additional fields, providing more detailed location information. Additionally, we’ve introduced a birth_date field in the subscriber object, ensuring better compliance and validation for porting requests. These improvements help streamline the porting process and improve overall reliability.

Exciting updates are here! We've expanded our API capabilities to give you even more control and flexibility. Now, managing port-ins and port-outs is easier than ever with our new number portability API, ensuring a seamless transfer experience. We’ve also introduced an API for managing network operators and service providers, simplifying integrations and operations. Plus, our brand-new phone number management API empowers you to handle number assignments and configurations effortlessly. These enhancements are designed to make your experience smoother, faster, and more efficient. Try them out today!

We’re excited to announce the release of 1GLOBAL Connect API VoX.

With this update, we’ve added robust new features designed to enhance connectivity, integration, and global scalability for our partners and clients.

With the launch of Connect API VoX, we are offering improved scalability and performance for our services. The Connect API v2 will remain fully operational until it reaches the end of its lifecycle, at which point a sunset plan will be communicated. However, new customers will no longer be onboarded onto v2.

Our commitment remains to continually refine and consolidate our services to ensure enhanced performance and security across our platforms. The production version of Connect API v2 will continue to be available for reference.

Explore the new possibilities with VoX and elevate your global connectivity solutions