Leaderboard

Hi all, Thanks very much for your feedback on the invoice immutability and credit/debit notes implementation in v9.0. We heard you loud and clear, and I'm pleased to say that in v9.1 we have implemented an admin-configurable Invoice Immutability setting. You can enforce invoice immutability, relax it while keeping billing notes, or turn it off entirely. For more information check out our release highlights, try it out yourselves, and share your feedback in the v9.1 Beta Discussion Board

This new "feature" is terrible and is a fundamental change. This feature does not conform to most businesses and should be an option if there are other regulatory purposes in other countries. It severely limits the flexibility of the system and limits its function. I highly recommend a switch to disable this new "feature".

Glad to see more customers speaking up about this… it’s a simple, fixable issue. All they need to do is keep allowing the switch: Add ($allow_adminarea_invoice_mutation = true;) in your WHMCS configuration.php . WHMCS choosing a one-size-fits-all strict model is what’s really causing the pain… let us decide if we need to deal with regional compliance and added accounting complexity, not force it on everyone.

A system should be designed to be functional for its paying customers, rather than being dictated by external regulations that may or may not be applicable to all users. Implementing such a feature without a proper disable option is impractical and appears to be an oversight. The current suggested workarounds are ineffective for the majority of standard web design and hosting businesses. Remember, most projects start off with two 50% (published) invoices (deposit and final) from the quote when converted and the final invoice typically gets tweaked for various reasons. This change would prevent that quick 10 second update to it. WHMCS should focus on developing efficient software that delivers value to its users, allowing us to manage legal compliance independently, rather than introducing features that hinder usability.

Yes, I agree they should be an option

While I understand that bugs are part of any Release Candidate cycle, it's concerning that we are still discussing basic optimization issues like proper OPcache support. And let's not even get started on the fact that we still don't have 100% native Nginx support. This becomes particularly ironic with the introduction of the new WHMCS Cloud Solution. With cloud hosting, the resource costs are on their side, so you'd think they'd be rushing to support Nginx to reduce their own infrastructure expenses. It's like being sold a high-performance engine but being told you have to power it with hamster wheels. Maybe once their bills start rolling in, Nginx support will suddenly become a priority. This all points to the bigger issue: the development velocity. Core development feels like it's just about "keeping the lights on" (PHP/ionCube updates) rather than actual innovation. This stagnation has allowed third-party developers like ModulesGarden to build entire businesses by selling us functionality that should have been in the core a decade ago. When you look at the "Total Cost of Ownership" license fees + necessary third-party modules, the value proposition is slipping. Newer platforms like Upmind are entering the market with an API-first architecture and modern features built-in from day one. If WHMCS continues to outsource innovation to the community while raising prices for maintenance updates, that competitive threat is going to become an exodus very quickly. We need core features that match the modern hosting landscape, not just compatibility patches.

Can't say I agree there. This will likely bite you at some point, badly.

@WHMCS John If you want this to be the new default Stripe module, a migration path from the current default Stripe module will be necessary.

Yeah this is a nightmare

This is what one WHMCS Staff tell me You have the option to make the change to your WHMCS configuration.php file and add the line $allow_adminarea_invoice_mutation = true;, but it is your decision whether to do so. When this line is present in your configuration.php file, the system will permit most of the changes to invoices that existed before WHMCS version 9.0, notably: Line items can be changed for invoices in any status (when in the "Manage" mode and with the correct admin user permissions set). All attributes are available in the Options tab regardless of the invoice status (when in the "Manage" mode and with the correct admin user permissions set). Payments can be applied in the Add Payment tab regardless of the invoice status (with correct admin user permissions set). Please note that using this configuration line ($allow_adminarea_invoice_mutation = true;) in your WHMCS configuration.php The file is highly discouraged, as it may permit changes that are not compliant with regional/country business regulations and complicate accounting. To bring awareness of this, a Warning health check will appear in the System Health Check summary when the value is present in your WHMCS configuration.php file. Additionally, all “full administrators” will see an Admin Warning banner (which can be dismissed up to every fortnight). You may want to add it temporarily if you do need to make the changes listed above, which were changed in WHMCS version 9.0 to improve invoice management and ensure tax compliance by keeping invoice records consistent. If you do not see any warnings or have issues with editing invoices or changing their status when this line is added, please let us know. Starting with WHMCS version 9.0, non-Draft invoices are immutable. This means you cannot edit transactions (now listed under the Ledger section on the invoice), add or remove items, or modify descriptions on an invoice once it’s no longer in the "Draft" status. This change is intended to improve invoice management and ensure tax compliance by keeping invoice records consistent. For more information on invoice management in WHMCS version 9.0, please refer to the following documentation: https://docs.whmcs.com/9-0/billing-and-invoicing/invoice-management/

I never imagined that a simple update could introduce so many problems — and even worse, apparently without proper testing. It is absolutely ridiculous for a financial management system to have its own financial logic broken. In the last 24 hours, I finally received a response on the open support ticket, along with a so-called “patch” (attached). In practice, this patch only fixes the reports by hiding the incorrect ledger entries. However, in several other areas of the system, the incorrect postings are still happening. For example, the “Transactions” tab inside the client profile continues to show wrong values and misleading entries. So, in short, this patch does not actually fix the root problem — it only masks it in specific reports. For now, apply it if you want to slightly reduce the visible impact, but be aware that the financial logic is still broken in multiple parts of the system. At this point, we are seriously considering rolling back to a previous version — or even migrating away from WHMCS entirely. Year after year, the pricing increases exponentially, while the quality of support continues to decline and critical issues like this keep happening. The current level of instability and support simply does not justify the price they are charging anymore. whmcs_v9.0.0-supporthotfix.1_750a0b77ff.321_WHMCS-24949.zip

Okay, maybe I was too quick about credit notes. It seems a lot of the features are "coming soon™️". This is not a Release Candidate lol. This is not even alpha. This is internal development. Nothing can convince me that this release didn't just happen because WHMCS promised us a release in December.

Automatic MarketConnect Account Registration: If your install isn't linked to a Marketplace account, 9.1 now attempts to create one during upgrade, with a starter credit applied. WHMCS has now reached a this point. I'm sure the community cannot wait for this highly requested feature. 🤣 it's clear that WHMCS is now at the stage of milking the software and community as much as possible.

I've recently had to investigate one of those slightly annoying WHMCS problems: the cron job appears to be running correctly, but some executions never actually finish. This can be surprisingly easy to miss. Having cron.php started every 5 minutes only tells us that cron is starting it every 5 minutes. It doesn't tell us whether the previous execution actually completed. If an automation task hangs — because of an external API, a registrar/module, a network problem, a database issue, custom code, etc. — you may eventually end up with several overlapping cron.php processes without immediately noticing what is going on. I put together a debugging approach that gives visibility into three different levels: whether the PHP cron process actually starts and terminates; whether the WHMCS automation cycle enters and exits normally; which individual WHMCS automation task starts but never returns (or simply takes an unusually long time). The basic idea is to use the PreCronJob / AfterCronJob and PreAutomationTask / PostAutomationTask hooks, combined with a simple external shell wrapper and a check for overlapping processes. Instead of just knowing: "The WHMCS cron seems to get stuck sometimes." you can hopefully get to something much more useful, such as: cron.php started DomainSync started another cron.php process started another cron.php process started DomainSync never returned At that point, at least you know where to start looking. I've written up the complete procedure, including the hooks, shell script, logging examples and some additional notes here: https://eurossl.eu/knowledgebase/whmcs-cron-job-stuck-debugging/ I'm posting this because I'd still like to contribute useful technical information back to the WHMCS community. However, after fighting over the years with the community's occasionally ("creative" code editor, formatting issues, disappearing posts and similar adventures), I've decided to keep the full article and code somewhere I can actually maintain them. 🙂 Hopefully this will save someone a few hours of debugging.

Trying to download ImportAssist from Marketplace (https://marketplace.whmcs.com/product/46-importassist ) Using Chrome: the download process just gets stuck, without any error message Using Edge: I got the error "ImportAssist_v1.5.3.69 (2).zip can't be downloaded securely" Using Opera or Tor: the download is completed successfully

Seems it's an error I'd say. I randomly checked a few others in the marketplace, and that's the only one doing that. Frustrating it's the WHMCS addon, but things like this can creep in, especially on an addon that's been around a long while.

That's a small red flag. Anything that is using http today indicates a lack of care, error or just ignorance.

Honestly the worst thing I could have done. Modules are supported. Invoices can't be edited. Worst move ever.

I just had Claude.ai help me create a module and hook to allow me to click a button to revert the invoice back to Draft and it also allows me to click a button to zero out a late fee. I am all set.

Hello @sahostking Thank you for your message. We are aware of this issue in WHMCS 8.13.4, which is currently being tracked under case WHMCS-26568 with our development team. A hotfix has been attached to this message to address this issue for you and anyone else. Please upload and extract the contents of the attached file into your WHMCS installation directory, allowing it to overwrite the existing files. I hope this helps! WHMCS-26568-hotfix.zip

Hi everyone, I would like to share a free community addon I created for WHMCS 9.x: CW Invoice Mutability for WHMCS 9.x Repository: https://github.com/RicRey1988/cw-invoice-mutability-whmcs-9.x WHMCS 9 introduced invoice immutability for non-Draft invoices. I understand the reason behind this change from an accounting and audit-trail perspective, but I also noticed that some administrators still need a controlled way to manage invoice editing in specific internal cases, especially before an invoice is paid or before it is synchronized with an external tax/e-invoicing system. This addon provides an admin interface to manage the current WHMCS invoice mutability compatibility option without manually editing configuration.php. Main features: Enable or disable invoice mutability from the WHMCS Admin Area. Automatically add or remove the current WHMCS compatibility flag: $allow_adminarea_invoice_mutation = true; Create a backup of configuration.php before modifying it. Optionally hide the WHMCS Admin Area warning banner about invoice immutability being disabled. Advanced/emergency mode to convert eligible Unpaid invoices back to Draft. Audit log table with invoice snapshot, invoice items, transactions, admin ID, IP address, reason, and timestamp. Safety checks to block Draft conversion when the invoice has transactions, payment date, or possible external/tax authorization references. PayPal donation link included for anyone who wants to support the project. The advanced Draft mode is intentionally restricted. It is not intended for already-paid, fiscalized, externally authorized, or tax-reported invoices. In those cases, the correct workflow should normally be credit notes, cancellation, voiding, or re-issuance according to local accounting rules. Installation: The folder must be named exactly: cw_invoice_mutability Final WHMCS path: /modules/addons/cw_invoice_mutability/ Required structure: modules/ └── addons/ └── cw_invoice_mutability/ ├── cw_invoice_mutability.php ├── hooks.php ├── README.md └── lib/ └── CwInvoiceMutabilityTools.php You can clone it directly with: cd /path/to/whmcs/modules/addons git clone https://github.com/RicRey1988/cw-invoice-mutability-whmcs-9.x.git cw_invoice_mutability Then activate it from: Configuration > System Settings > Addon Modules After activation, go to: Addons > CW Invoice Mutability This addon is free and community-oriented. It is not affiliated with WHMCS. If it helps you, donations are welcome: https://paypal.me/hostingsupremo Feedback, improvements, and pull requests are welcome.

I’m trying to install ModulesStack from https://modulesstack.com/installation/ I followed the steps, but I’m not sure if I’m doing it correctly. The installer runs, but the modules don’t appear in my admin panel. Has anyone successfully installed it? What am I missing?

I’ve added: $allow_adminarea_invoice_mutation = true; Honestly, this change is a nightmare for our daily workflow. We need to edit invoices every day, and with this new restriction, what used to be a simple operation has become an everyday problem. In my opinion, this was a very bad decision from a usability point of view, especially for companies that manage billing operations daily and need flexibility when handling invoices.

Unbelievable that all of our questions lately are being ignored. What's the point of this community?

Not everyone wants SAAS solutions, or keeping data with a third party due to concerns about client data. I'm one of those businesses.

Request WHMCS to make it a confugurable option instead of removing it?

The one question I have is "why"? Clearly there's a need and demand for it, why is it not even considered being made optional, with warnings about not doing it or what have you. Why is it simply removed, with no options and so on.

Whats stupid is as a developer this is as simple as adding a checkbox to the config to allow us to choose ourselves. I've never in my life understood why software companies lock you in, instead of giving you the option. You keep increasing prices year after year and you want us to stay with you, but if you keep doing this crap most of your base is not gonna find value in your ever increasing prices.

Welcome to the common sense reasons why were frustrated about WHMCS enforcement of preventing us from editing our OWN invoices we created in the first place. Credit / debit is useless in real world standard practice. If they want to provide a switch to disable editing published invoices or changing status fine, but dont force it on the customer base. That's dumb.

Are there still issues after the 9.0.3 release?

add this line to your configuration.php it will go back to normal behavior $allow_adminarea_invoice_mutation = true;

Thank you for the terrible WHMCS support. This is now the tenth client who has made a bulk payment and the late fee is simply not added to the invoice, and none of the outstanding invoices are automatically marked as paid. I’m not even going to mention the credit and debit issues anymore, because it seems the WHMCS developers themselves don’t even know what they’re doing. Does anyone have a suggestion for another system similar to this garbage?

I think you guys may be dramatically underestimating what AI is capable of, but I suppose we shall see. As for the post being suitable or not, Webpros has done everything in their power to alienate their client base - this type of post is the inevitable consequence of that.

"Luck" isn't really a component here. If you haven't played around with agentic coding I can see why this would seem like a stretch for you, but it's quite trivial to get a fairly simple billing system up and running quite rapidly. And like I said this is with current-level tools, in a year or two, replicating the entirety of WHMCS would likely be very doable.

Yeah, except for adding AI to domain search, this release doesn't really provide on any of the other promises. Credit notes doesn't work either. When you cancel an invoice, WHMCS just adds a transaction to the invoice. If the invoice has a total of $100, WHMCS just adds a transaction of $100 and cancels the invoice. There's no credit note or anything.

How WHMCS have set this as a RC instead of a Beta is insane. It's a huge upgrade in terms of it's impact on themes/modules. No beta, no reply from WHMCS, no forums specific to v9.

Your process sounds good apart from WHMCS. I would never recommend trying to import tables to new files. You need to update your existing install as normal. You can update from your version but you may have more luck doing a manual update. Backup everything, upload the new v8.13 files, adjust your hosting/server settings to meet the requirements (e.g you may need to update PHP) then run the installation script.

@BENELUX, Today's the day!! https://blog.whmcs.com/133775/whmcs-90-release-candidate-out-now

This week or next! It sure would be nice to double the size of the engineering team temporarily for one release every few years!

@stormy, I'm glad to hear the e-invoicing feature will be a real value add for you. We are working with expert solution-providers in this space, so we're confident about delivering an easy to use and compliant solution with the broadest coverage. @andp97, Yes, by the end of the year in a pre-release version of WHMCS you will have access to this new feature. This bullet point actually describes two significant features which we're very excited about: 1. A RESTful API which provides access to the product catalogue and shopping cart logic. This will provide a suite of new endpoints to get product catalogue information, add, manipulate and get information about items in the cart (including price breakdowns and totals) and much more, all without touching the cart.php file or PHP session data. This means that power users could create their own highly-bespoke frontends whilst WHMCS handles the maths in the background, before seamlessly passing visitors to the checkout page to complete payment. 2. A brand new thin client powered by the aforementioned new API capabilities, providing a thoroughly modern purchase experience based on Vue.js. I've attached a sneak peak below. The new BuyFlow is a compiled Single-page application, meaning the layout isn't manipulated through templates, but you will be able to customise the colours to match your theme through a custom.css overrides file. The shopping cart as it exists today (cart.php and order form templates) isn't going away and will still be available if you'd like to stay with the familiar experience. Stay tuned to our blog and socials over the coming weeks for more information!

Well Another year another price increase. we just got this email 17.70% price increase thats 180,48 USD Extra per year. Source: WHMCS Customer Licensing Guide 2027 - WHMCS we only use WHMCS as a client management system we dont do payments via WHMCS. There has to be a cheaper alternative to this?

Thanks for sharing this! WizardPanel Lite looks like a useful option for beginners who want to build a website directly with WHMCS. I especially like that it doesn't require WordPress. I'll definitely check it out.

Nice. Thanks for sharing!

AI wont kill WHMCS right now and any near future. The logic behind a system like WHMCS its too huge to replicate easily, domain renewals is one thing, but making it all work together with invoices, dns, hosting, etc etc etc. You need to spend alooooooot of tokens for doing that. So no, right now AI wont kill WHMCS, but give it 2-3 years surely yes WHMCS will be replaced by other systems.

Update PHP first to a version that's compatible with BOTH the existing and the new version to be installed. Make sure the existing system health page reports everything is OK. Then try updating WHMCS. Once update is successful, and you have a working WHMCS, you can attempt to update PHP again to the latest supported version, for whatever version of WHMCS you are upgrading to.

It would be a nightmare. A lot of add-on modules (that need to be updated too, cause of the different PHP version), and a lot of custom hooks (that also will need to be modified in order to work with a higher PHP version). I guess it will last for at least a few working days, maybe more... so the straight update is not viable. The database migration is also safest (anything going wrong during migration? Not an issue, just roll back and study how to fix it...) So, again, the original question: according to WHMCS doc the database migration is a breeze ( https://docs.whmcs.com/8-13/system/system-tutorials/move-whmcs-to-a-new-server/ ), but will it work with such a high version difference?

Key Features List Our WhatsApp Gateway: Authentication and User Management: Login, registration, and logout using CodeIgniter Shield. User group system (admin & user). User profile management. User Dashboard: Subscription overview (active plan, remaining days, message/device limits). Usage statistics (messages sent, devices connected). Alerts for expired subscriptions or reached limits. API token management for external access. WhatsApp Integration: Multi-session device management (multiple WhatsApp accounts per user). Sending of text and media messages (images, etc.). QR code scanning to connect WhatsApp devices. Message logging (delivery status, WhatsApp message ID). Message limit checks based on subscription plans. Subscription and Plan System: Various plans with device and message limits. Usage tracking (messages sent, active devices). Subscription management (active, expired). Plan upgrade/downgrade. Admin Panel: User management (create, edit, delete users). Assign groups and plans to users. RESTful API: Endpoints for sending WhatsApp messages via token. Integration with Node.js backend for WhatsApp operations. Modules: Invoices, Orders, Payments. Multi-language support (English, Indonesian, Spanish, UAE/Arabic, Chinese). Node.js Backend (whatsapp-web.js): Node.js server for running WhatsApp clients. Multi-session support with LocalAuth. Handling of QR codes, connections, and message/media sending. Logging and error handling. Security and Logging: Input validation and CSRF protection. Message and user activity logging. Environment variables for sensitive configuration (NODE_URL, etc.).

Thanks for opening a new thread, I had posted in the 2025 one. In my case, they will be extracting an extra $25/mo in exchange for absolutely nothing. The email is hilariou,s though: "We understand any change in pricing directly affects your business, which we do not take lightly." HOWEVER, if they succeed in doing the European E-invoicing right, which I highly doubt, then the price increase would be worth it. The problem is - can we trust WHMCS with something that can get you us legal and financial trouble?

For businesses that heavily utilise WHMCS's API, you may be sending API requests from many different IP addresses or IP ranges, all of which need to be whitelisted at System Settings > General Settings > Security (tab) > API IP Access Restriction in the Admin Area. Each individual IP address must be added to the allow list (it is not possible to list IP ranges in CIDR notation at this time). The process of adding a range of IP addresses can be sped up by using a PHP script to add them in bulk. Before we begin, WHMCS support does not recommended directly interacting with the database where it can be avoided. We would therefore only recommend following this guide if you have an existing understanding of both PHP and database administration, and have taken a full database backup. WHMCS will not be held responsible for any data loss that might occur if you do not heed this advice. How are API Allowed IPs stored? The list of IPs allowed to interact with the API are stored as a serialized array in tblconfiguration.value where tblconfiguration.setting = "APIAllowedIPs". A serialized array, in this particular context, is a way for us to store an array as a string in the database. Handling existing data in WHMCS's database To make things easy, let's create a function that takes in the current serialized array, which you can retrieve from the database, a new IP and a note, and then returns the new serialized array. Here it is, with everything explained in inline comments: function addNewIP($currentValue, $ip, $note) { // Take the $currentValue, and unserialize it so we can interact with it directly. $data = unserialize($currentValue); // Define our new entry, based on the $ip and $note provided in the function call. $newEntry = array( 'ip' => $ip, 'note' => $note ); // Add the new entry to the existing array. $data[] = $newEntry; // Re-serialize the array. $newValue = serialize($data); // Return to the serialized version of the new array. return $newValue; } Iterating through IP ranges We now need to iterate through all IP address in a given range and add them to our array. Let's create another function to do this: function addNewIPRange($currentValue, $startIP, $endIP, $note) { // Convert the start and end IP addresses to long integers so we can iterate through them $startIP = ip2long($startIP); $endIP = ip2long($endIP); // Initialize $newValue $newValue = $currentValue; // Iterate through the IP range for ($ip = $startIP; $ip <= $endIP; $ip++) { // Convert the current IP back to string format $newIP = long2ip($ip); // Call the addNewIP function for each IP in the range $newValue = addNewIP($newValue, $newIP, $note); } // Return the modified value return $newValue; } Note that we'll still need to provide the current value from the database, and this will be updated each time an IP in the range is added. Testing it out First of all, we need to retrieve the current serialized array from the database. This can be done programmatically using Capsule, but in this case we'll just retrieve it manually: SELECT value FROM tblconfiguration WHERE setting = 'APIAllowedIPs' Then we can call addNewIPRange to add an IP range, or just addNewIP if we only want to add a single address. Of course, when you're using this you wouldn't need to add all of the extra echo lines or comments - these are just included to help demonstrate how this is working. // Store current APIAllowedIPs value in variable $currentValue = 'a:5:{i:0;a:2:{s:2:"ip";s:0:"";s:4:"note";s:0:"";}i:1;a:2:{s:2:"ip";s:12:"10.3.137.243";s:4:"note";s:0:"";}i:2;a:2:{s:2:"ip";s:7:"8.8.8.8";s:4:"note";s:7:"Testing";}i:3;a:2:{s:2:"ip";s:7:"1.1.1.1";s:4:"note";s:7:"Testing";}i:4;a:2:{s:2:"ip";s:11:"12.13.14.15";s:4:"note";s:7:"Testing";}}'; // Let's see our $currentValue in a more readable format so that we can compare it to our new version echo "<h1>Starting value</h1>"; echo "<pre>"; print_r(unserialize($currentValue)); "</pre>"; echo "<br/><hr/>"; // To add a new IP range, call addNewIPRange, and pass in the $currentValue, IP range and a note: $testRange = addNewIPRange($currentValue, '10.20.30.40', '10.20.30.60', 'Test IP Range'); echo "<h1>With our added IP range</h1>"; echo "<h2>Serialised version:</h2>"; echo $testRange; echo "<h2>Unserialised version:</h2>"; echo '<pre>'; print_r(unserialize($testRange)); '</pre>'; echo "<br/><hr/>"; // To add a single IP, call addNewIP, and pass in our new value, address and a note: $testSingle = addNewIP($testRange, '192.168.1.1', 'Single IP'); echo "<h1>And with one more address</h1>"; echo "<h2>Serialised version:</h2>"; echo $testSingle; echo "<h2>Unserialised version:</h2>"; echo '<pre>'; print_r(unserialize($testSingle)); '</pre>'; echo "<br/><hr/>"; You can then add the new data to the database manually, or using Capsule. Doing the latter is beyond the scope of this article. The final script Let's finish by tidying up the scirpt a bit, and showing an example. Let's say we wanted to whitelist the following: 192.168.45.23 - management VPN 192.168.45.24 - development VPN Range from 10.20.0.126 to 10.20.10.159 - backend servers Here's what your script would look like: <?php function addNewIP($currentValue, $ip, $note) { $data = unserialize($currentValue); $newEntry = array( 'ip' => $ip, 'note' => $note ); $data[] = $newEntry; $newValue = serialize($data); return $newValue; } function addNewIPRange($currentValue, $startIP, $endIP, $note) { $startIP = ip2long($startIP); $endIP = ip2long($endIP); $newValue = $currentValue; for ($ip = $startIP; $ip <= $endIP; $ip++) { $newIP = long2ip($ip); $newValue = addNewIP($newValue, $newIP, $note); } return $newValue; } $currentValue = 'a:5:{i:0;a:2:{s:2:"ip";s:0:"";s:4:"note";s:0:"";}i:1;a:2:{s:2:"ip";s:12:"10.3.137.243";s:4:"note";s:0:"";}i:2;a:2:{s:2:"ip";s:7:"8.8.8.8";s:4:"note";s:7:"Testing";}i:3;a:2:{s:2:"ip";s:7:"1.1.1.1";s:4:"note";s:7:"Testing";}i:4;a:2:{s:2:"ip";s:11:"12.13.14.15";s:4:"note";s:7:"Testing";}}'; $manVpnIP = addNewIP($currentValue, "192.168.45.23", "Management VPN"); $devVpnIP = addNewIP($manVpnIP, "192.168.45.24", "Development VPN"); $backendServers = addNewIPRange($devVpnIP, "10.20.0.126", "10.20.0.159", "Backend Server"); echo $backendServers; The output of this script would be the new serialized array, and you can set this directly in the database! Again - please make sure to take a backup before manually interacting with WHMCS's database. UPDATE tblconfiguration SET value = '<add your serialized array here>' WHERE setting = 'APIAllowedIPs'; Important: You must use single quotes and not double quotes, else the command's format will not be valid (since double quotes are used in the serialized array itself). Once you have run this, login to the WHMCS admin area and navigate to System Settings > General Settings > Security (tab). You should now see a list of all your IPs listed in the API IP Access Restriction setting. Further considerations After adding so many IP addresses, you may find that you are no longer able to add any more addresses via the Admin Area. This will be because your PHP max_input_vars is being exhausted. It is not a bug with WHMCS, nor is it something that we can mitigate - this is how PHP is configured by default. https://www.php.net/manual/en/info.configuration.php#ini.max-input-vars To rectify this, please increase the max_input_vars value in your PHP configuration. Should you need assistance with doing this, please contact your hosting provider or system administrator. It is also possible that you might reach the maximum size for the value column in tblconfiguration. In the event of this occurring, you can change the type of the column to MEDIUMTEXT. Please keep in mind that this is not officially supported, and you should definitely take a database backup before proceeding. Customising/extending this script Feel free to customise this script to you heart's content, whether you want to change how it behaves or extend its functionality. However, please keep in mind that our Technical Support team won't be able to help you troubleshoot any problems that you may encounter should you make any changes. Use at your own risk. Suggestions for other "Tips & Tricks' articles If you'd like to see an example of how we can customise WHMCS in other ways, please do give us your suggestions!

We're pleased to advise that the issue has now been resolved: