Return to Question

https://api.stackexchange.com/docs/vectors

When passing a vector, sepeate each id with a semicolon. For example, /users/1;2;3;4;5?site=somesite would fetch users with ids 1 through 5 on somesite.

sepeate => separate

https://api.stackexchange.com/docs/min-max

Another handy trick is to only request the total field when all you care about is the quanity of items meeting some criteria, such as when calculating statistics. The ?filter=total built-in filter is provided for just this purpose.

quanity => quantity

https://api.stackexchange.com/docs/wrapper

The error_* fields, while technically elligible for filtering, will not actually be excluded in an error case. This is by design.

elligible => eligible

https://api.stackexchange.com/docs/paging

total is also a useful property when displaying paging controls. In this case applications would want to include both items and total on a filter rather than making two seperate requests.

seperate => separate

https://api.stackexchange.com/docs/compression

While effectively all browsers will always request compressed content, many (if not all) of the applications using our API will be on decidely less mature HTTP stacks. The likelihood of many applications not opting into compression, and being materially worse for it, is unacceptable.

decidely => decidedly

Few other words, not sure they are typos:

https://api.stackexchange.com/docs/wrapper

When building filters, this common wrapper object has no name. Refer to it with a leading ., so the items field would be refered to via .items.

refered => referred

https://api.stackexchange.com/docs/filters

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time ...

unneccessary => unnecessary

https://api.stackexchange.com/docs/users-by-ids

{ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for user_id on user or shallow_user objects.

programatically => programmatically

https://api.stackexchange.com/docs/vectors

When passing a vector, sepeate each id with a semicolon. For example, /users/1;2;3;4;5?site=somesite would fetch users with ids 1 through 5 on somesite.

sepeate => separate

https://api.stackexchange.com/docs/min-max

Another handy trick is to only request the total field when all you care about is the quanity of items meeting some criteria, such as when calculating statistics. The ?filter=total built-in filter is provided for just this purpose.

quanity => quantity

https://api.stackexchange.com/docs/wrapper

The error_* fields, while technically elligible for filtering, will not actually be excluded in an error case. This is by design.

elligible => eligible

https://api.stackexchange.com/docs/paging

total is also a useful property when displaying paging controls. In this case applications would want to include both items and total on a filter rather than making two seperate requests.

seperate => separate

https://api.stackexchange.com/docs/compression

While effectively all browsers will always request compressed content, many (if not all) of the applications using our API will be on decidely less mature HTTP stacks. The likelihood of many applications not opting into compression, and being materially worse for it, is unacceptable.

decidely => decidedly

Few other words, not sure they are typos:

https://api.stackexchange.com/docs/wrapper

When building filters, this common wrapper object has no name. Refer to it with a leading ., so the items field would be refered to via .items.

refered => referred

https://api.stackexchange.com/docs/filters

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time ...

unneccessary => unnecessary

https://api.stackexchange.com/docs/users-by-ids

{ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for user_id on user or shallow_user objects.

programatically => programmatically

https://api.stackexchange.com/docs/vectors

When passing a vector, sepeate each id with a semicolon. For example, /users/1;2;3;4;5?site=somesite would fetch users with ids 1 through 5 on somesite.

sepeate => separate

https://api.stackexchange.com/docs/min-max

Another handy trick is to only request the total field when all you care about is the quanity of items meeting some criteria, such as when calculating statistics. The ?filter=total built-in filter is provided for just this purpose.

quanity => quantity

https://api.stackexchange.com/docs/wrapper

The error_* fields, while technically elligible for filtering, will not actually be excluded in an error case. This is by design.

elligible => eligible

https://api.stackexchange.com/docs/paging

total is also a useful property when displaying paging controls. In this case applications would want to include both items and total on a filter rather than making two seperate requests.

seperate => separate

https://api.stackexchange.com/docs/compression

While effectively all browsers will always request compressed content, many (if not all) of the applications using our API will be on decidely less mature HTTP stacks. The likelihood of many applications not opting into compression, and being materially worse for it, is unacceptable.

decidely => decidedly

Few other words, not sure they are typos:

https://api.stackexchange.com/docs/wrapper

refered => referred

https://api.stackexchange.com/docs/filters

unneccessary => unnecessary

https://api.stackexchange.com/docs/users-by-ids

programatically => programmatically

https://api.stackexchange.com/docs/vectors

When passing a vector, sepeate each id with a semicolon. For example, /users/1;2;3;4;5?site=somesite would fetch users with ids 1 through 5 on somesite.

sepeate => separate

https://api.stackexchange.com/docs/min-max

Another handy trick is to only request the total field when all you care about is the quanity of items meeting some criteria, such as when calculating statistics. The ?filter=total built-in filter is provided for just this purpose.

quanity => quantity

https://api.stackexchange.com/docs/wrapper

The error_* fields, while technically elligible for filtering, will not actually be excluded in an error case. This is by design.

elligible => eligible

https://api.stackexchange.com/docs/paging

total is also a useful property when displaying paging controls. In this case applications would want to include both items and total on a filter rather than making two seperate requests.

seperate => separate

https://api.stackexchange.com/docs/compression

While effectively all browsers will always request compressed content, many (if not all) of the applications using our API will be on decidely less mature HTTP stacks. The likelihood of many applications not opting into compression, and being materially worse for it, is unacceptable.

decidely => decidedly

Few other words, not sure they are typos:

https://api.stackexchange.com/docs/wrapper

When building filters, this common wrapper object has no name. Refer to it with a leading ., so the items field would be refered to via .items.

refered => referred

https://api.stackexchange.com/docs/filters

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time ...

unneccessary => unnecessary

https://api.stackexchange.com/docs/users-by-ids

{ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for user_id on user or shallow_user objects.

programatically => programmatically