I have some interface feedback for the portal.
Whenever I log into the Portal, there is a max of 10 DIDs being shown. For someone who has more than that, it creates friction and wastes time. It’s the same for a call record review. It shows way too few calls and every time by default I have to switch to the longer amount to review things the way I want.
I would urge the voip.ms to consider changing this to at least a higher value if not allow an menu option to change it.
This happens everywhere on the site for me too, even in the call logs. They are set to 10, you change them to 100, and they snap back to 10 again. It is very annoying and adds extra steps every time you review anything.
In an email at the beginning of the year, @DavidR announced that in 2026 they will be working on “A customer portal revamp.” So maybe we will see improvements concerning all these little things. 
Thanks Alex. I can confirm that a customer portal revamp is coming. We’re currently building a brand-new API that will power a fully API-first customer portal :-).
This really should not require a full portal revamp. It is a very small line of code to fix the default pagination value, and customers have been reporting it for a long time. It should have been corrected already.
These restrictions appeared about 10 years ago, probably to reduce the load on the servers. Even today VOIP.MS’s website is slow sometimes, maybe because of low server capacity (easy to fix) or inefficient data structures (hard to fix).
This DID search…
https://voip.ms/m/orderdid.php?type=starts&query=606&state=KY&action=didsearch
…returns 500 results (the maximum). In the past, such a search would take perhaps 20 seconds; today, it’s much faster, which is nice. (The search may depend on the speed of Bandwidth’s DID inventory API, which is beyond VOIP.MS’s control.)
Feel free to correct any of my info above.
I’ve never seen the current website be slow.
I do not think the “10 per page” setting has anything to do with server load or speed. When the page first opens, all 500 entries appear to load immediately. I do not know the exact technical term for how the interface handles this, but setting it to 10 seems to only limit what is displayed at one time.
If I type something into the filter field, the search still finds entries that are not currently visible, which tells me the full dataset is already loaded in the background. The pagination setting just hides the additional rows rather than reducing the amount of data being retrieved.
So from what I can see, the 10‑item limit is only a display preference, not a performance requirement.