Payload

This code is pretty hard to read (and possibly prone to encoding errors):

data = f'{{"query":"","filters":"start_date <= {start_date} AND end_date > {end_date}{country_string}","facetFilters":["auction_phase:-cancelledAuction"],"hitsPerPage":100,"page":{page},"aroundLatLng":"{location}","aroundLatLngViaIP":false,"aroundRadius":100000}}'

Just use a plain dict for your arguments like:

    data = {
        "query":"",
        "filters": "",
        "start_date": ""
    }

And then you can either use the json or data argument in requests.post to send a properly-encoded payload depending on the type of endpoint (JSON vs multipart form). If it's really needed you can always "stringify" your dict at the end before sending the request. Reference

In fact, that's what you're doing in get_auction_items.

Harcoded values

Hardcoding the URLs in your class makes it inflexible. Consider these alternatives:

1. provide URLs in function arguments
2. using a config file

The point of writing a lib is to reuse it. So it has to be flexible and reasonably future-proof. Surely you have already imported plenty of third-party packages. And then you just start using them, you normally never have to edit the source code, unless you found a bug and you fix it.

Error handling

When you are fetching online resources you should 1) always check the status code as @Daniel Walker already mentioned 2) also verify that the data you expect in return is really present. Raise an error if those conditions are not met. Otherwise the rest of the code will not perform like it should. Maybe it will not crash but return empty data or inconsistent results. It may not even be obvious there was a problem during execution and that makes troubleshooting more difficult.

In fact, this is where your wrapper could perhaps provide some added value: by performing enhanced validation, so that the caller can have confidence that the results that are returned by your API are sound and accurate. A lib that returns garbage or unreliable data is not useful.

Formatting

Formatting can be improved. Get acquainted with PEP8, use proper indentation and line spacing, here there should be one empty line between functions inside your class.

PEP 8 suggests lines should be limited to 79 characters. I don't respect the rule absolutely strictly, but the point is to avoid excessive scrolling to read your code. Some lines are way too long because of the way you build the payloads.

Another line that is too long:

def search(self, search_type='auctions', query='', location='', country=False, page=0): #search for some listings based on query and location, leave fields blank to get all auctions

Move the comments to the next line, better yet triple-quote that section and make it a doctstring. Inline comments are OK if you don't abuse them and they should be short (typically 1-2 words)

I recommend that you choose a good IDE (+ some optional plugins) to enforce code style as you write it.

Naming

Function names should be intuitive. The function test_search should rather be named test_tokens or something like that, to reflect its stated purpose. Since you already have set_tokens and generate_tokens that would bring some harmony and consistency. At least that's a start.

Likewise, you have a function get_auction_items - we can guess what it does. But the function search has a very broad name: without looking at the source code we are not sure what it's all about.