# API's Lack of Unit Reported -- Causing Issues in WHMCS

**URL:** <https://forums.interworx.com/t/apis-lack-of-unit-reported-causing-issues-in-whmcs/12796>\
**Category:** InterWorx API Discussion\
**Created:** [October 13, 2010, 9:15pm UTC](https://forums.interworx.com/t/apis-lack-of-unit-reported-causing-issues-in-whmcs/12796 "2010-10-13T21:15:00Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![int](https://forums.interworx.com/letter_avatar_proxy/v4/letter/i/54ee81/32.png) [@int](https://forums.interworx.com/u/int)\
**Post date:** [October 13, 2010, 9:15pm UTC](https://forums.interworx.com/t/apis-lack-of-unit-reported-causing-issues-in-whmcs/12796/1 "2010-10-13T21:15:00Z")

</div>

I’ve been having an ongoing problem with WHMCS and Interworx. It seems that because the Interworx API does not report back the units of a query, it is causing WHMCS (and I’m sure other billing systems) to improperly report, for example, bandwidth usage. Here’s the response from the folks at WHMCS:

–

Unfortunately it seems this is a limitation of the InterWorx API as they don’t supply any units with the data returned. This is the data that comes back for the domain in question:

[32] =\> Array  
(  
[id] =\> 46  
[domain] =\> \<masked\>.com  
[bandwidth\_used] =\> 26.24  
[bandwidth] =\> 50  
[storage\_used] =\> 4.16  
[storage] =\> 3000  
)

As you can see no indication of units, and one is in GB and the other in MB but no way WHMCS could know that, so [there] doesn’t seem to be a solution.

–

Can you guys implement/suggest a fix/workaround for this?

---

<div class="post-metadata">

**Author:** ![Paul](https://forums.interworx.com/user_avatar/forums.interworx.com/paul/32/6_2.png) [@Paul](https://forums.interworx.com/u/Paul)\
**Post date:** [October 22, 2010, 10:45pm UTC](https://forums.interworx.com/t/apis-lack-of-unit-reported-causing-issues-in-whmcs/12796/2 "2010-10-22T22:45:33Z")

</div>

Well this is a sticky situation. The storage data reported by this action will always be in MB, and the bandwidth data will always be in GB - but it probably wouldn’t be prudent at this point to just change the output of the API command be “26.24 GB” - if an API author was using that value as a number, the “GB” might break their implementation. Perhaps we should do a poll of our known billing system integrators and see if they’re using these values for anything more than display purposes right now, and at least prepare them for a possible change.

Paul