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. Review validation - WARP automatically validates TNs when they are added and flags missing or inconsistent data.
  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.

Enter the BTN as one 10-digit US telephone number. Enter the service location as a numeric street address, city, two-letter state, and five-digit ZIP, for example 21699 E Quincy Ave, Aurora, CO 80015. A billing PO box is not a service address.

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 a current LOA for each losing-carrier group before submission. Generate and sign the WARP LOA, or upload an externally signed LOA from that carrier group's action. If the number set changes, WARP marks the prior LOA stale and asks for a replacement; prior revisions remain in the audit history.

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

Statuses and FOC

WARP uses a short customer vocabulary: Draft, Validating, Ready to submit, Processing, With carrier, Action required, Port scheduled, Ready to activate, Activating, Ported, Cancelled, and Needs support. It does not expose the carrier's LSR/CSR processing steps.

After submission, open the request's Your next steps section whenever WARP shows Action required. It can ask for a corrected LOA, updated account details or PIN, another requested date, or an acknowledgement. Only actions currently allowed by the carrier workflow are shown. WARP checks for updates in the background and while the request page is open.

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 use the revalidate action for the affected TNs.

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/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