Using API Key

Send your credentials as two HTTP headers on every request:

Header	Value
X-Gearment-Client-Key	Your Gearment client key
X-Gearment-Client-Secret	Your Gearment client secret

Both headers are required on every /api/v3/* and /api/v2/* request. They are headers, not body fields, so a GET request that carries no body authenticates exactly the same way as a POST.

curl -i -X GET \
  -H "X-Gearment-Client-Key: YOUR_GEARMENT_CLIENT_KEY" \
  -H "X-Gearment-Client-Secret: YOUR_GEARMENT_CLIENT_SECRET" \
  'https://apiv2.gearment.com/integration-handler/api/v3/catalog?paging.page=1&paging.limit=100'

The same pair authenticates a request with a body:

curl -i -X POST \
  -H "X-Gearment-Client-Key: YOUR_GEARMENT_CLIENT_KEY" \
  -H "X-Gearment-Client-Secret: YOUR_GEARMENT_CLIENT_SECRET" \
  -H "Content-Type: application/json" \
  -d '{"order_id":"EXT-1234567"}' \
  'https://apiv2.gearment.com/integration-handler/api/v3/orders/draft'

Coming from API v1/v2

v1/v2 carries api_key and api_signature inside the JSON request body. v3 never reads credentials from the body - the same two values travel in the headers above, where api_key is your client key and api_signature is your client secret. The compatibility layer still accepts the v1/v2 body form on /api/v2/* and maps it onto these headers for you, which is why old integrations keep working unchanged.

Send both headers together. A request with only X-Gearment-Client-Key is rejected the same way as a request with a wrong secret - see Authentication.