Before reading this page, please make sure you are familiar with both expansions and filters.

An expansion is a lot like any other API response: it can include a variety of data fields and related endpoint links, and those related endpoints can be expanded further. But what if you want to specify filters or other options on a particular expansion? You can't do that with _expand. There is an alternative way to specify expansions which gives you increased control and flexibility: _config.

The value of _config is a JSON object, which makes it easy to express complex configuration data.

Consider this example:

400: Invalid request

In the example above, we see that the main request is for /api/v2/user/cmac, but a configuration has been supplied via the _config query parameter. It's tough to read that flattened and URL-encoded JSON, so here it is formatted for reading:

400: Invalid request

You might also notice that this example includes both "filter" and "filteruri" at the top level. This is equivalent to supplying _filter and _filteruri query parameters. You might prefer to put all your filters in _config for consistency.

Query parameters for expanded responses

You might want to send a query parameter to an expanded response. In this example, we send the count parameter to control the number of albums returned:

400: Invalid request

Again, the JSON is easier to read when formatted:

400: Invalid request

Multi-args: getting one expansion multiple ways

You might want to expand the same related endpoint twice, with different query parameters each time. You can do this with "multiargs":

400: Invalid request

Again, the JSON is easier to read when formatted:

400: Invalid request

Note that "multiargs" is incompatible with "args". You can use "multiargs" at the top level to request the base endpoint multiple times, with different query parameters each time.