The Fitssey API is organized around REST implementation. It communicates using HTTPS resource-oriented URLs, accepting and returning JSON payloads. The API is secured using Bearer token which can be obtained in your Studio > Integrations > API Keys.

We advise you to take 30 minutes upon reading this document and this may save you time when developing your great application.

This document covers the REST API. To get notified about events in your Studio in real time, see the Webhooks documentation.

7 November, 2026

• Implemented POST /client/{user}/notes endpoint
• Implemented DELETE /client/{user}/notes endpoint

26 October, 2026

• Introduced per-key scopes

28 September, 2026

• Implemented new /report/client-pricing-option/active endpoint

9 September, 2026

• Documented POST /classroom/book endpoint
• Documented POST /classroom/cancel endpoint

15 July, 2026

• Implemented PATCH /client/{user} endpoint
• Implemented POST /client/{user}/tags endpoint
• Implemented DELETE /client/{user}/tags endpoint

20th April, 2026

• Implemented new /schedule/courses endpoint
• Implemented new /report/finance/zero-sales endpoint
• Exposed ClassService guid in ScheduleEvents
• Exposed Categories in ClassService

16th November, 2025

• Rewritten documentation to catch up with development changes
• Introduced API limit rates
• Added new /report endpoint

The base URL contains {uuid} parameter which can be found in Studio > Your Studio > UUID section and it's an integral part of each request. Thanks to the UUID, we know it's you.

https://app.fitssey.com/{uuid}/api/v4/public

For developers we have created examples that can be found in our official Github profile (https://github.com/fitssey).

Check out our Widgets integration - simply copy & paste the given code and things magically appear on your website!

Fitssey API by default uses HTTP authentication.

The very first thing you would have to do is to create an API key in your Studio > Integrations > API Keys.

Of course it's very important to keep your API keys always secure. That is why we strongly recommend to:

• use a different API key for each integration
• store and use API keys on the server-side (PHP, Python, Node.js) and not client-side (JavaScript)

The created API key must be sent along with each API request, by providing it in the HTTP Authorization request header using the Bearer method. The valid Authorization header looks as follows: Bearer live_dHar4XY7LxsDOtmnkVtjNVWXLSlXsM.

Each API key is granted a set of scopes when it is created in Studio > Integrations > API Keys. A scope allows a single kind of operation on a single resource, e.g. client:read or clientVisit:write.

Grant each key only the scopes the integration really needs.

A request made with a key that lacks the required scope is rejected:

HTTP/1.1 403 Forbidden
Content-Type: application/json
WWW-Authenticate: Bearer error="insufficient_scope", scope="client:write"

{
  "error": {
      "statusCode": 403,
      "code": 109,
      "message": "Insufficient scope. This endpoint requires the \"client:write\" scope."
  }
}

Scopes other than read also require API write access to be activated for the studio. New studios can request it in Studio > Integrations > API Keys. Until it is activated, such requests are rejected with code 110:

HTTP/1.1 403 Forbidden
Content-Type: application/json

{
  "error": {
      "statusCode": 403,
      "code": 110,
      "message": "Write access is not activated for this studio. The \"client:write\" scope requires API write access, which can be requested in Studio > Integrations > API Keys."
  }
}

Whenever you develop the application, you must always check for errors because sometimes things break. Normally, you will always get a response in JSON format explaining what the error was along with the error code for a reference.

A first digit of HTTP status code represents whether the response was successful or not.

• A code in the 2xx range indicates that a response was successful and you can handle the data in your application.
• A code in the 4xx range indicates that a response has failed due to number of reasons explained in the error message (can be validation problem, resource not found or authentication issue). Usually this error won't go away by itself.
• A code in the 5xx range indicates that Fitssey application had hiccup, meaning something happened in our app infrastructure. Only we know what causes the problem, so you won't get detailed message what's going on in the error message. In such critical errors, we are instantly notified about the problem, so it may be possible that if you retry your request it will work again.

Examples of error responses:

HTTP/1.1 403 Forbidden
Content-Type: application/json

{
  "error": {
      "statusCode": 403,
      "code": 103,
      "message": "Invalid API key"
  }
}

Sometimes we use enums as strings (e.g. scheduled) and sometimes as integers (e.g. 1 (paid)). Pay attention whether to use each.

What can I do using Fitssey API?

You can use our API to write custom applications or integrations for your website. You can do variety of things including the following:

• Display the schedule the way you want
• Book classes
• Manage client profile
• Sell products
• Manage members

Is there a rate limit?

As of late 2025, we have introduced rate limits as follows:

• 10/s (30s lockout)
• 200/5m (30m lockout from last request)
• 4000/6h (4h lockout from last request)
• 10000/24h (6h lockout from last request)

The limits apply per studio, not per API key. All API keys of a studio share the same budget, so creating additional keys does not raise the limit. Each response carries the current state in the X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset (seconds) headers.

When a limit is exceeded, the request is rejected until the lockout expires:

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
X-RateLimit-Limit: 200
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1800

{
  "error": {
      "statusCode": 429,
      "code": 0,
      "message": "Rate limit exceeded. Retry after 1800 seconds."
  }
}

Stop sending requests until X-RateLimit-Reset seconds have passed. Some lockouts are extended by every request made during the lockout, so retrying early only makes it longer.

Can my API key be suspended?

Yes. An API key that keeps sending requests while being rate limited is suspended after too many consecutive 429 responses (1000 by default). Any request that is not rate limited resets the counter, so integrations that respect the lockout are never suspended. The studio owner is notified by email when a key is suspended.

A suspended key is rejected with code 111 on every request:

HTTP/1.1 403 Forbidden
Content-Type: application/json

{
  "error": {
      "statusCode": 403,
      "code": 111,
      "message": "API key has been suspended after too many rate-limited requests. The studio can resume it in Settings > Integrations > API."
  }
}

The studio can resume the key in Studio > Integrations > API Keys. Fix the integration's retry behaviour first, otherwise the key will be suspended again.

Please treat our API with all the respect and don't abuse the calls. If possible, please cache the responses on your side.