The app_usage_events endpoint was not designed to be a live billing
interface. Typically what you would do is have another app that polls the
endpoint, collects the billing data, and saves it off in a format that is
easy to generate bills from.

http://apidocs.cloudfoundry.org/214/app_usage_events/list_all_app_usage_events.html

This is the reason the app_usage_events endpoint has the after_guid query
parameter. Ideally your billing system would keep track of the last guid
that it fetched, then when it polled again, it could get everything after
that event.

Be aware of the warnings at the top of the api docs. In general you should
not process app usage events that are close to the current time (within a
couple of minutes is probably fine). The reason for this is that you could
miss events that are being created in a transaction that has not yet been
committed.

The destructively_purge_all_and_reseed_started_apps endpoint is not
intended to be used monthly. This endpoint exists because the billing data
only goes back so far, and if you haven't been collecting it from the
very beginning, you don't know what apps have been started before the usage
data starts. What you should do is get your billing infrastructure in
place, then call this endpoint one time. This will seed the usage events
feed with a STARTED record for each app that is currently running. You can
then just process the changes you get from the usage endpoint after that.

And of course, as Noburou mentioned, you can always increase the
cc.app_usage_events.cutoff_age_in_days manifest parameter.

Joseph
OSS Release Integration Team