In some cases Ordering Platforms can receive special permission to use static credentials, in lieu of the preferred OAuth standard for delegated access.
Some standard reasons we discourage choosing to do so:
- Static credentials grant indefinite, global access, which is inferior to short-lived, scoped authorizations
- OAuth supports automatic rotation, revocation, and granular scopes
- OAuth provides standardized flows for securely obtaining tokens without exposing raw secrets
- Static credentials hinder auditing and access control changes
However, if the requirements for OAuth are unsuitable for a particular use case, we will consider allowing for this option despite the downside. One example would be the need to onboard, very quickly, a very large number of locations: the Bulk Special Case.
The Bulk Special Case has 2 additional requirements for the headers: (1) API Key ("API_KEY") and (2) API Secret ("API_SECRET") in the request headers.
Every request is expected to contain a valid set of authentication credentials in the headers, in order to return a 200 Success response.
Headers:
Content-Type:application/json
API_KEY:<client uuid provided by Checkmate>
API_SECRET:<client secret provided by Checkmate>
The Bulk Special Case also has a requirement for a location_id Query Parameter that needs to be added to some of your API requests:
- Get Menu
- Submit an Order
- Get Location
Here you can see an example cURL request for the Get Menu API with some bogus placeholder values (Note that the URL is for the Sandbox App, not Production) wherein the Static Credentials are Headers and alocation_idQuery Parameter is appended to the URL:
$ curl -X GET "https://sandbox-api.itsacheckmate.com/api/v2/menu/__the_name_of_platform__?location_id=555555" -H "API_KEY: 783f22ba-664e-4c04-b6ce-27447a4e066e" -H "API_SECRET: 783f22ba-664e-4c04-b6ce-27447a4e066e" -H "Accept: application/json"