Could my object use static methods? Anything I need to do to make the code better? With the Zend coding convention in the back of my mind, I have set this up.

It lets you communicate with the API of the vendor TargetSMS. They allow you to bill customers trough SMS. For now I've only spent time on the NonSubscription option.

I would just like to know if it's ok, or what could be better.  I am mostly interested in knowing if the TargetSms object could use static methods.  For example, I think the isAllowedIp method could be static, since I would like to use it even if the object is not initiated (I was told that's the idea behind static methods).

TargetSMS object

&lt;?php
/**
* TargetSMS object with TargetSMS related methods.
*/

namespace TargetPay\Sms;

class TargetSms
{
    /**
* The allowed IP of TargetSms.
* @var array
*/
    protected $_targetSmsIp = array('89.184.168.65');

    /**
* The ok response code for TargetSMS.
* @var number
*/
    protected $_responseCode = 45000;

    /**
* Check if the request is comming from TargetSMS.
* @param string $ip
* @return boolean
*/
    public function isAllowedIp($ip = '')
    {
        if (in_array($ip, $this-&gt;_targetSmsIp)) {
            return true;
        }
        return false;
    }

    /**
* Get the TargetSMS required responsecode.
* @return number
*/
    public function getResponseCode()
    {
        return $this-&gt;_responseCode;
    }

    /**
* Add a new allowed ip address to the array with allowed ip addresses.
* @param string $ip
*/
    public function addAllowedIp($ip = '')
    {
        $this-&gt;_targetSmsIp[] = $ip;
    }
}
If you wanted to make isAllowdIp static (and there's nothing wrong with that, per se), you -indeed- don't need an instance of your class to call that method. But owing to there being no instance, you won't have access to any non-static properties of your class, either.
To get around that, you'd have to change:

protected $_targetSmsIp = array('89.184.168.65');


To 

protected static $_targetSmsIp = array('89.184.168.65');


And change these method, too:

public static function isAllowedIp($ip)
{//don't check empty strings, they're always invalid ips!
    return !!in_array($ip, self::$_targetSmsIp);
}
public static function addAllowedIp($ip)
{//don't allow '' defaults! adding empty strings aren't valid ips
    if (!filter_var($ip, FILTER_VALIDATE_IP))
    {//check what you're adding to the OK-list!
        throw new InvalidArgumentException($ip. ' is not a valid IP');
    }
    self::$_targetSmsIp[] = $ip;
}


This, by itself isn't code that makes my eyes water, but it doesn't exactly sit well with me, either: It's hard to tell what the actual task of your class is: validate IP's/data? Is it the API connection layer?
I gather it's the latter. In which case, I'd define my methods to only accept objects of a given type. This object is where you can filter, check and validate all input... For example, the IpObject:

class IpObject
{
    private $ip = null;
    private static $valideIps = array();
    public function __construct($ip = null)
    {
        if ($ip)
        {
            $this-&gt;setIp($ip);
        }
    }
    public function getIp()
    {
        return $this-&gt;ip;
    }
    public function setIp($ip)
    {
        if (!filter_var($ip, FILTER_VALIDATE_IP) || !in_array($ip, self::$validIps))
        {
            throw new InvalidArgumentException($ip.' is not valid');
        }
        $this-&gt;ip = $ip;
        return $this;
    }
}


The major problem with your creating statics here is that, by changeing the allowed IP's for one instance, you're changing the allowed IP's accross the board: you can't black-list or OK ip's for instances of your object individually, so after a while it'll get quite tricky to work out which IP's are allowed and which aren't.

All in all, an array in this object won't add too much overhead... not that you notice, and it will make life easier when testing/debugging.
Instead of using statics. having an instance at the ready is 99.99% of times the better option.