Schema

The Punchh API is a RESTful API over HTTPS. A valid authentication signature through HTTP header x-pch-digest must be included with all requests. Our API uses industry standard SSL/TLS encryption and must be accessed only over HTTPS. Plain-text HTTP access is not available.

Base Endpoint

All requests must be sent to a resource name by prepending the API base URL. Currently, we provide two environments: production and sandbox.

Production API Base URL

Examples in our API documentation assume that the production API base URL provided by your Punchh representative will be used. For each and every request, send the request along with the required parameters and authentication signature through headers.

https://SERVER_NAME_GOES_HERE.punchh.com

Sandbox API Base URL

Sandbox is for testing only. For Sandbox, replace the production API base URL with the Sandbox API base URL provided by your Punchh representative.

Parameters

Many API methods take optional parameters. We accept parameters in two different ways:

a). Query string: For GET requests, parameters can be passed as an HTTP query string. For example:

Using auth

$ curl -i "https://SERVER_NAME_GOES_HERE.punchh.com/api/auth/users?name=EMAIL_GOES_HERE -H 
    "x-pch-digest:SIGNATURE_GOES_HERE

In this example, we want to fetch users via the API where the name parameter with value EMAIL_GOES_HERE is passed in the query string.

b). JSON in the request body: For HTTP POST, PATCH, PUT, and DELETE requests, parameters should be sent in the HTTP body as JSON; application/json included in the request's Content-Type header and SHA1 SIGNATURE value should be included in the x-pch-digest header.

JSON Formatting

JSON must be serialized, as specified in RFC4627, and encoded as UTF-8, as specified in RFC3629, using one to four bytes per Unicode code point.

For example:

Using auth

$ curl -i "https://SERVER_NAME_GOES_HERE.punchh.com/api/auth/users" \
       -H "Content-Type:application/json" \
       -H "Accept: application/json" \
       -H "x-pch-digest:SIGNATURE_GOES_HERE"  \
       -X PUT \
       -d '{"name":NAME_GOES_HERE,"client_key":CLIENT_KEY_FOR_PUNCHH_DASHBOARD_HERE}' \
       -u 'USER_TOKEN_HERE:x' \

In this example, we send an HTTP PUT request to list users through the auth API while name and client_key are passed as parameters. We provide authentication using HTTP basic auth USER_TOKEN_HERE for authentication and signature using x-pch-digest header, which is generated using the URL and body through the SHA1 digest algorithm. For more information, see Generating x-pch-digest Header for Online Ordering APIs.

Response Data Format

All responses are in JSON.

Blank Fields

Blank fields are included as null (empty) instead of being omitted.

HTTP Verbs

Where possible, API auth strives to use appropriate HTTP verbs for each action.

Verb Description
HEAD Can be issued against any resource to get just the HTTP header information
GET Used for retrieving resources
POST Used for creating resources, or performing custom actions (such as merging a pull request)
PATCH Used for updating resources with partial JSON data. For example, an Issue resource has title and body attributes. A PATCH request may accept one or more of the attributes to update the resource. PATCH is a relatively new and uncommon HTTP verb, so resource endpoints also accept POST requests.
PUT Used for replacing resources or collections. For PUT requests with no body attribute, be sure to set the Content-Length header to zero.
DELETE Used for deleting resources

Error Codes and Responses

The Punchh API attempts to return appropriate HTTP status codes for every request.

Code Text Description
200 OK Success!
304 Not Modified There was no new data to return.
400 Bad Request The request was invalid or cannot be otherwise served. An accompanying error message will explain further (e.g., "Invalid parameters").
401 Unauthorized Authentication credentials were missing or incorrect.
404 Not Found The URI requested is invalid or the resource requested, such as a user, does not exist.
412 Precondition Failed Invalid signature
422 Unprocessable Entity Invalid entity

Date Format

We use ISO 8601 as our data format. All timestamps are returned in the following format:

YYYY-MM-DDTHH:MM:SSZ

Copyright © 2025 PAR Technology Corporation. All rights reserved.
PAR Technology Corporation 8383 Seneca Turnpike, Suite 3 New Hartford, New York 13413 (315) 738-0600 legal@partech.com. PAR Tech is a leading global provider of software, systems, and service solutions to the restaurant and retail industries.
You may learn about its product offerings here.
Before using this application, please read the Limited License Agreement and the PAR Tech Terms of Use.