Add numbers to an existing porting project

Account and project access

Use an enabled API account over HTTPS from an allowed IP address. The project must belong to that account and must not be deleted. Use the project’s unique ID from the port-order workflow, not its numeric database ID or a phone number. URL-encode the project ID when building a request.

Prepare the addition

This operation changes an existing porting project. Confirm the numbers and customer authorization through your port-order workflow first. Format each number as full international digits, remove duplicates yourself and check the project’s existing number list. Do not use this endpoint to test arbitrary numbers.

The current portal validates and normalizes numbers before calling this route. The raw legacy endpoint does not provide the same safeguards: it trims input but does not validate phone-number format, country code, duplicates or the project’s workflow status.

POST request

Create a local numbers.json with the following structure. The numbers are fictional; replace them with authorized numbers for the selected project.

{
  "numbers": [
    "12025550123",
    "12025550124"
  ],
  "isocode": "US"
}

curl --silent --show-error --user "$API_USER:$API_PASSWORD" \
  --header "Content-Type: application/json" \
  --data-binary @numbers.json \
  "https://api.multitel.net/v3/lnp/project/$PROJECT_ID/addnumbers"

Use POST with application/json for this example. Form POST input is also read. The method does not define an idempotency key or an endpoint-specific safe batch-size contract; reconcile manageable batches rather than relying on a guessed limit.

Reported result

Fictional response example.

{
  "status": {
    "code": 200,
    "msg": "Success add numbers"
  },
  "response": {
    "uniqueid": "PROJECT_EXAMPLE",
    "count": 2,
    "numbers": [
      {
        "id": 21,
        "number": "12025550123",
        "status": 0,
        "status_str": "Pending",
        "isocode": "US"
      },
      {
        "id": 22,
        "number": "12025550124",
        "status": 0,
        "status_str": "Pending",
        "isocode": "US"
      }
    ]
  }
}

The response labels attempted additions Pending. It does not verify each database insert result before reporting it. A count or returned ID alone is therefore not proof that every row was persisted. A Pending addition is not carrier acceptance, a scheduled transfer or completed activation.

Reconcile before retrying

1. Read the project’s number list before adding numbers and keep the intended addition in your own request records.
2. Send the addition once.
3. Read the project number list again and compare every intended number. Check duplicates and per-number statuses.
4. If the request times out, returns an error, or reports an ambiguous result, read back before retrying. Some additions may already exist.
5. Resolve missing or duplicated rows through the port-order workflow or support rather than blindly repeating the complete request.

The handler inserts entries one at a time without a transaction or duplicate protection. An interruption can leave earlier writes in place; a failed insert that returns false can still be included in the reported count. Repeating a request can add duplicate rows. The handler does not itself write an event or complete a carrier transfer.

Legacy errors

A method other than POST returns API code 403. A missing, deleted or unowned project returns API code 404. Empty number input also returns API code 404. Authentication and source-IP restrictions apply. These legacy codes do not establish that no earlier insertion occurred after processing began.

Billing and transfer scope

The reviewed handler inserts project-number rows and contains no direct account debit or carrier submission. This does not make the overall porting service free or override agreed porting fees. Complete the project’s authorization, document and review requirements before expecting a transfer.