To answer your question…

It doesn’t seem possible to restrict AppIDs as the limits don’t work on a per-site basis like that and you usually have just one AppID for all your uses/sites. See this comprehensive thread from 2010 (quoted below), I doubt much has changed. The end result is it basically doesn’t matter for a read-only application such as search results on your website.

More generally about securing JSON API calls in-browser

Checking the referrer is the best way to secure an otherwise public API. This is how Google restricts their API keys for maps, for instance: https://developers.google.com/maps/documentation/javascript/tutorial

About the only thing that will prevent fraud is activity monitoring, given that the API is called from third-party computers, one would have to track trends for abuse, perhaps by comparing a list of calls to other website activity, or by using JSONP to inspect the browser’s properties with AJAX. Google can cross-reference their API calls with their Google Analytics calls, for example, though there could always be false positives.

In the end, if the fear is CSRF, there’s this: How to reliably secure public JSONP requests?

Quoting verbatim from the eBay thread in case the URL changes again:

There is one DevID per developer account.

There could be multiple AppID, but these are only available via paid support ticket.

Each AppID can have multiple CertID. The CertID determines your call limits.

You can generate unlimited tokens for each AppID. Each token is a pairing of AppID, UserID, and the associated eBay user’s password. Tokens are currently active for 18 months. They must then be regenerated. Tokens can also be prematurely ‘revoked’ either via the API or website preferemces.

For the API families that require a token, you can use a single token based on your own UserID to retrieve most public information. However, private transaction details are only available when you use a token generated for the target UserID. Some calls actually derive the UserID from the token.

If multiple applications share the same AppID, they will both contribute towards the daily call limits. That’s why you might want to request a separate AppID.

https://www.x.com/developers/ebay/ebay-api-call-limits

The limits shown in the chart are ‘aggregate’ for the given API family. There’s an implicit per-AppID. For the Trading API, eBay further limits use on a per-call or per-time-interval basis. Some calls like AddItem have higher limits. GetApiAccessRules will return your actual limits and usage.

Per-IP-address means the IP address of the calling machine. If you were to rotate through multiple IP addresses, you’d actually multiply your limit. There are many read-only ‘widgets’ written in JavaScript or Flash which run in the client browser and thus use the client IP to make the calls. In that case, the call limit is pretty insignificant.

AppID, DevID and CertID belong to the creator of the developer account. That creator is bound by the API license provisions.

As the owner of the keys, you are not to allow any 3rd-party programmatic control of the API. Strictly speaking, that means that both the keys and any token derived from those keys should remain private (i.e. under your exclusive control).

Obviously, eBay does not enforce that strict interpretation since FetchToken is suggested for client-side applications. A sophisticated user could easily grab the token coming or going. What harm can someone do with a token based on their own UserID?

1. Burn through your daily call limit
2. Create an API application that violates the license

For more of the debate, see this earlier thread. (Link broken)

Once your application passes the eBay Compatible Application Check, you can request either 1.5M shared or 20K calls per user.

For further information about eBay’s APIs, I suggest asking on their forum.