OLO2OLO Panservice: migrations and codes

Scope and prerequisites

The module manages migration codes, operator and COW catalogs, outgoing migrations, incoming requests and related OLO2OLO Panservice communications. An enabled module, assigned permissions and provider API access are required.

Configure version and token

Open Settings → OLO2OLO → API. Enter the provider HTTPS domain and select v2 — full module. Version v1 supports migration-code creation and verification only.

Create a static token in the OLO2OLO portal Profile section. Tokens obtained through API login expire after 24 hours. The saved token is not displayed: leave the field blank to keep it on the same domain; enter the appropriate token when changing the domain.

Saving v2 checks authentication before accepting the new settings. The profile cannot be verified with v1.

Understand token errors

Choose Verify saved connection to check the token in the saved settings. This requires v2 and confirms validity only at the time of the check.

An authentication error means the token is expired, revoked or invalid; Panservice does not always distinguish these causes. An authorization error means the token lacks access to the function. Update the token or ask the provider to check permissions. A missing function requires checking the domain and version; a network failure does not establish token expiry.

Operators and COWs

With v2, open Operators and filter by current name, original name or native COW. The detail panel provides operator references. The COW page supports searching by operator, native COW and usable code.

Create and verify a code

In the service page open Migration-code management → Create migration code, choose the COS and enter the COR resource, containing 6–12 alphanumeric characters. Confirm creation to associate the returned code with the service. OLO2OLO management must be enabled on the service.

In code verification, enter the complete 9–19 character code. Read COW, COR, COS and checksum separately. Code validity does not prove ownership or portability: compare the data with the customer documentation.

Create a migration

With v2, open Migrations, enter the full code and a unique order reference of up to 64 characters. Optional first and last names allow up to 40 characters; notes allow 255. Enter up to 10 directory numbers of 6–12 digits each, separated by commas, semicolons or new lines.

The code is checked before submission. Creation confirms that OLO2OLO received the request and displays its identifier; it does not confirm migration completion. Search the reference before submitting again. If the outcome is uncertain or local saving fails after acceptance, check the portal and contact support.

Read communications

For outgoing migrations, choose Refresh for all local requests or enter the reference shown in the local list. Incoming requests concern migrations where the ISP is the donating operator.

Communications are separated by type, including formal and management checks; previously acquired entries are updated. A communication date alone does not establish progress. Communication acquired does not mean migration completed. Review phase, resource and rejection reason.

Incoming requests also receive periodic updates for enabled ISPs; outgoing communications are refreshed from their page.

Send a management rejection

For an incoming request, choose Management response and an allowed reason. Submission is permitted only while OLO2OLO allows that response in the current request state.

Send rejection communicates a negative result to the operator: check the order and reason first. Free-text notes are not supported for this response. Refresh communications after sending to read the result; do not repeat a submission with an uncertain outcome.

Permissions and good practice

Read permission allows consultation and connection verification. Creation, communication refresh and management responses require write permission. Each ISP accesses its own requests.

• Use v2 for the complete module and a dedicated static token.
• Verify the connection after authentication errors.
• Keep a unique order reference.
• Check the line, customer and migration authorization.
• Check the portal before repeating an uncertain submission.
• Never share tokens or personal data in support messages.