The key mistake here is neglecting the Wrapper Object, and this is a big flaw with the filter documentation.
The wrapper is the box that everything you get from the API comes in. You always get the wrapper object except in the grossest of server/API errors. (In your case you were getting a wrapper of
The stuff you care about, the payload, is the
total and/or in the
For this reason, every filter should have
.wrapper.total selected. More on this, below.
Furthermore, your filter must return the error properties and the quota remaining, or your app/script WILL get restricted or denied by the API at some point.
A safe/proper base filter always includes:
-- You need to monitor, and handle, errors and depleted quota, or bad things will be done to your app and/or your account.
Plus one of
This is the stuff you care about, and without
items, the non-wrapper filters are effectively turned off.
The reason I say "one of" is because of experience and this bit of the Paging doc:
Fetching total can be equally as expensive as fetching items. Put another way, an application fetching total when not needed is potentially halving its performance. It is for this reason that total is not returned by default.
I've observed(But admittedly did not collect data) that filters that have both
items tend to bring the
backoff hammer that much quicker. See below for more on paging.
Recommended properties to also always include:
-- these are useful sanity checks for debug, development, and API errors. And they do not seem to "cost" anything.
Note that the
type property can be useful for libraries, but is seldom needed otherwise.
For the above reasons, the Built In Filters from the Filters doc have terrible advice.
Never use the
total built in filters as these leave you vulnerable to undetected and unhandled errors.
Filters for paging:
For obvious reason, if your app expects lots of results, your filter should also the
has_more properties. I also recommend the
Note that several paging bugs are still unresolved, so cross checking is recommended.
For paging, I make an initial call for just the total (plus the other base properties). Then I make addition
items calls(without the
total) to page through the results, cross checking page numbers and
has_more against the previous total.
List of canned, useful filters:
In practice, none of the "built in" filters are good.
total omit crucial wrapper properties.
withbody include too much cruft for every scenario I've seen.
Here's some filters I recommend:
- Minimum base:
!GeDDagKb4Bn(8 or with paging:
- Getting just the total of something:
- General, most useful fields (includes paging):
To use these, refer to this other answer:
Open the appropriate doc page for the path you are using. EG /questions doc.
This automatically shows you only the filter sections that are relevant for that API path/query.
Click the filter  control and paste in the minimum base filter from step 1 above. Press enter for it to take effect.
Now, add back in the payload properties that you care about. In your example they are
questions.creation_date. (But you probably need
Be sure to add back the
page_size properties if more than one item (or total) is expected.
Press the save button.
Carefully copy the resulting filter string for use in your app.
Note: Don't bother with
/filters/create. It is more trouble than it's worth and only useful if your app needs to generate filters programmatically -- which is rare.