---
title: "Validate port-in data"
method: POST
path: "/v1/port-ins/validate"
tags: ["Port-Ins"]
---

# Validate port-in data

`POST /v1/port-ins/validate`

## Request

- Base URL: `https://api.telgea.com`
- URL: `https://api.telgea.com/v1/port-ins/validate`
- Auth: API key in header `x-api-key`

Validates port-in data against provider requirements without creating a port-in. Use this endpoint to check whether the submitted fields, phone number, and execution date would pass provider validation before committing to a port-in submission.

The `executionDate` must be one of the type's `executionDate.dates` from `GET /v1/port-ins/fields/{countryCode}`, which hold until its `validUntil`. The date is checked once everything else passes: a date outside them is then refused with 400 BAD_REQUEST, not `valid: false`.

This is a dry-run operation — no resources are created or modified.

## Headers

- `idempotency-key` string: A value unique to this request, of 1 to 255 printable ASCII characters — a UUID is the usual choice. Retry with the same key within 24 hours and you get the original response back, even if it was a failure, and nothing is done twice. Send a new key whenever you change the request. Keys are private to your API key and organisation.

## Request body

- ValidatePortInBody
  - `countryCode` string, required: ISO 3166-1 alpha-2 country code
  - `type` string, required: Port-in type as returned by the fields endpoint (e.g., "personal", "business")
  - `msisdn` string, required: Phone number to port in, in E.164 format
  - `executionDate` string, date, required: Requested porting date in YYYY-MM-DD format. Must be one of the type's `executionDate.dates` from `GET /v1/port-ins/fields/{countryCode}`, which hold until its `validUntil`.
  - `fields` object, required: Port-in fields as defined by the fields endpoint. Must include authorizationCode.

## Response `200`

Validation completed. Check the `valid` field to determine if the data passed. If `valid` is false, the `errors` array contains details: each error names its `field` and carries a stable `code` to branch on.

- ValidatePortInResponse
  - `valid` boolean, required: Whether the port-in data passed validation
  - `errors` PortInValidationError[], required: List of validation errors, empty if valid
    - `message` string, required: Validation error description
    - `field` string: The field that caused the validation error
    - `code` 'REQUIRED' | 'FORMAT_INVALID' | 'LENGTH_INVALID' | 'NOT_ALLOWED' | 'DATE_NOT_ALLOWED' | 'CHECK_DIGIT_INVALID' | 'WRONG_CUSTOMER_TYPE', required: Why the value was refused, as a stable code to branch on. A code is never renamed or removed, but new ones can be added: show the `message` for a code you do not recognise.

## Other responses

- `400`: Request body failed schema validation, or everything else passed and the `executionDate` is not one the market offers
- `401`: Missing or invalid API key in the X-API-Key header
- `403`: Insufficient permissions to validate port-ins
- `409`: The number cannot be ported in: Telgea already holds it, or a port-in for it is already in flight. Creating the port-in would be refused the same way.
- `429`: The API key has used its request quota for the current window. `Retry-After` says how many seconds until it resets.
- `500`: Internal server error. Contact support if this persists.

---

[API](https://skmtc.dev/telgea/apis/telgea-api.md) - [All operations](https://skmtc.dev/telgea/apis/telgea-api/llms.txt) - [OpenAPI document](https://skmtc.dev/telgea/apis/telgea-api/revisions/4e8f8c04fe9e?raw)