---
title: "Troubleshooting R365 Public API Status Codes & Errors"
slug: "public-api-troubleshooting-status-codes-errors"
updated: 2026-09-02T18:32:55Z
published: 2026-09-02T18:34:25Z
canonical: "docs.restaurant365.com/public-api-troubleshooting-status-codes-errors"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.restaurant365.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Troubleshooting R365 Public API Status Codes & Errors

> [!NOTE]
> Early Adopter (Closed)
> 
> The R365 Public API is currently available to a closed Early Adopter group. Restaurant365 is incorporating participant feedback before it opens access more broadly. Learn more about [requesting R365 Public API access](https://docs.restaurant365.com/apidocs/en/request-access).

This article lists the HTTP status codes returned by the R365 Public API and what to check for each one. For authentication setup, see [Getting Started: Authentication & Request Headers](https://docs.restaurant365.com/apidocs/en/authentication). For an overview of R365's integration surfaces, see [R365 Public APIs](https://docs.restaurant365.com/apidocs/en/r365-public-apis).

---

## Status Codes

| Issue | Cause | Resolution |
| --- | --- | --- |
| **401** | R365 could not authenticate the request. | Confirm the `Authorization` header is present and starts with `Bearer `, the token is complete (including any trailing characters), and the customer instance in `x-r365-context-tenant-id` is correct and authorized for that token. > [!WARNING] > A `401` response covers both a missing or invalid token and a customer instance the token is not authorized for. If a token works against one customer instance but returns `401` on another, the customer instance value is the thing to check. |
| **403** | The request was authenticated, but the acting user could not be resolved or is not allowed to perform the action. | Confirm the permissions of the user associated with the token. Learn more about [API Managed Users](https://docs.restaurant365.com/docs/en/api-managed-users). |
| **207** | A batch write request completed. Individual items in the batch may still have failed. | Check each entry in the response's `results` array. Do not treat a `207` response as full success. |
| **400** | A query parameter or the request body is malformed. | Check the `errors` object in the response. For example, a non-numeric `pageSize` returns a message naming the field. |
| **404** | The path or the requested record does not exist. | Check the path spelling and confirm the record belongs to the customer instance in the request. |
| **415** | The request body was not sent as JSON. | Confirm the write request includes `Content-Type: application/json`. In `curl`, the `-d` flag defaults to `application/x-www-form-urlencoded` unless the header is set explicitly. |
| **422** | The request was understood, but a business rule rejected it. | Check the `errorCode` and message in the response body for the specific rule. |
| **429** | The request rate limit for the customer instance was exceeded. | Slow the request rate and retry with progressive backoff rather than retrying immediately. |
| **500** | An unexpected error occurred on the Restaurant365 side. | Retry once. If the error persists, contact Restaurant365 Support with the `traceId` from the response body. |

---

## Reading Error Responses

Error responses follow [RFC 7807](https://datatracker.ietf.org/doc/html/rfc7807) and include a `traceId`:

```plaintext
{
  "type": "https://httpstatuses.io/401",
  "title": "Unauthorized",
  "status": 401,
  "traceId": "00-d941da5d0130684cdd13fa450988c2f7-43a32f3e40dd4402-01"
}
```

Always include the `traceId` when contacting Support. It lets Restaurant365 locate the exact request.