WARP

WARP guide

Porting Numbers Into WARP

How to use the WARP port-in wizard, understand LOA requirements, track statuses, and recover from validation or carrier issues.

Use the port-in wizard when numbers are currently with another carrier and you want to bring them to WARP. This is an industry port-in. It requires accurate carrier account details and a Letter of Authorization.

If the number is already on WARP under another customer account, use an on-net transfer instead. On-net transfers use a transfer PIN and do not need an LOA or FOC date.

Port-In Workflow

The normal port-in workflow is:

  1. Preview portability - enter the numbers to check whether they appear portable.
  2. Create a draft - save a port request so you can work through the steps.
  3. Add telephone numbers - add the TNs being ported.
  4. Enter carrier details - provide losing-carrier account number, PIN, and required group details.
  5. Generate and attach the LOA - complete the authorized signer attestation.
  6. Validate - let WARP check required data and flag missing or inconsistent fields.
  7. Submit - send the request into the carrier porting process.
  8. Track FOC and progress - watch status and milestones.
  9. Activate and configure services - after completion, configure routing, E911, CNAM, and SMS.

Work in order. Later steps depend on earlier steps being complete.

Portability Preview

Run preview before collecting every detail. Preview helps identify numbers that may not be portable before you invest time in carrier details and documents.

If preview says a number is not portable, do not force it into a request without understanding why. Confirm the number, current carrier, and account status first.

Carrier Details

Carrier details must match the losing carrier's records. Mismatches are the most common reason for rejection.

Before entering details, gather:

  • Current carrier name.
  • Account number from a recent bill or portal.
  • Account PIN or passcode.
  • Authorized billing name and service address.
  • Any losing-carrier-specific requirements.

Do not disconnect service with the losing carrier before the port completes. Disconnecting early can cause rejection or loss of the number.

Letter of Authorization

The LOA authorizes WARP and the involved carrier parties to request the port. WARP generates the LOA in the portal for the request and group.

The signer must be the account holder or an authorized representative. The attestation should be completed by someone with real authority over the losing-carrier account. If you are unsure who is authorized, confirm before submission.

Off-net ports require the LOA before submit. If a submit action reports that an LOA is required, return to the Documents or LOA step, generate the LOA, and complete the signer attestation.

LOA content and authority can have legal consequences. Buzz can explain the workflow, but it should not provide legal approval.

Statuses and FOC

Common statuses:

  • draft - the request is still being prepared.
  • validating - WARP is checking request data.
  • ready - the request has enough information to submit.
  • submitted - the request has entered the carrier process.
  • FOC - Firm Order Commitment has been issued. This is the committed date the losing carrier agrees to release the numbers.
  • completed - the numbers have moved to WARP.

Plan cutover around the FOC date, not the desired date. The desired date is a request; FOC is the carrier commitment.

Fixing Validation Errors

Validation errors usually identify missing fields, malformed data, document gaps, or carrier-detail mismatch. Fix the specific fields named by the wizard, then revalidate.

Use notes and history on the port detail page to track what changed and why. If the port is rejected after submission, read the rejection reason, correct the named issue, and supplement or resubmit when the action is available.

After Completion

Ported numbers land on your account, but service configuration still matters. After completion:

  1. Confirm the numbers appear in Numbers.
  2. Route voice to the correct trunk.
  3. Configure E911 and CNAM if needed.
  4. Enable SMS and assign campaigns if needed.
  5. Place inbound and outbound test calls.

Scopes and API Reference

Read operations use porting:read:

  • POST /v1/porting/preview
  • GET /v1/porting/requests
  • GET /v1/porting/requests/:id
  • GET /v1/porting/requests/:id/progress
  • GET /v1/porting/requests/:id/statistics
  • GET /v1/porting/requests/:id/error-groups
  • GET /v1/porting/requests/:id/notes
  • GET /v1/porting/requests/:id/history
  • GET /v1/porting/requests/:id/documents

Draft and edit operations use porting:write:

  • POST /v1/porting/requests
  • POST /v1/porting/requests/:id/tns
  • PUT /v1/porting/requests/:id/groups/:spid/details
  • POST /v1/porting/requests/:id/groups/:spid/loa
  • POST /v1/porting/requests/:id/validate
  • POST /v1/porting/requests/:id/auto-fix
  • POST /v1/porting/requests/:id/revalidate
  • POST /v1/porting/requests/:id/notes
  • POST /v1/porting/requests/:id/documents
  • DELETE /v1/porting/requests/:id/documents/:docId
  • DELETE /v1/porting/requests/:id

Lifecycle actions use specific scopes:

  • porting:submit for POST /v1/porting/requests/:id/submit
  • porting:activate for POST /v1/porting/requests/:id/activate and auto-activation settings
  • porting:cancel for POST /v1/porting/requests/:id/cancel
  • porting:supplement for supplement and resubmit actions