Storing data from an API, in database or memcached

I am in a situation where I can't make up my mind. I have a client management system (Whmcs) that our company uses to sell web hosting, vps,... At the moment I am writing a new standalone client interface that uses the API of WHMCS to retrieve the client's details, invoices, support, tickets and products. All other logic happens in the new application (Configuring products, paying invoices,...)

These API requests happen on a private network, speed is not the issue here. But, I would like to store them either in Memcached or in a separate database to reduce these requests to the bare minimum.

If I work with a database, I would work with some kind of webhook that the WHMCS will call if, for example, when a user has a new invoice. This would be send to the webhook and the database gets updated only if something changes in WHMCS. The downside I see here is that some of the data is present on two systems and a lot of events and webhooks will have to be written to achieve this.

The other solution is using our memcached cluster and store the needed API requests there, if a user logs in, the data that is needed gets returned then stored in memcached. This way there will only be one API request untill something has changed. This way is relatively easy to achieve, brief example below:

    public function getInvoices($status = null)
    {
        if (!Cache::has('invoices_' . $status . $this->id)){
            $data = $this->fetchInvoices($this->id, $status);
            Cache::put('invoices_' . $status . $this->id, $data, 30);
        }

        $data = Cache::get('invoices_' . $status . $this->id);

        //Check if user owns the invoices
        if (Gate::denies('owns-data', $this->id)){
            abort(401);
        }

        return $data;
    }

What would be the best approach for this?