Getting Started with the Classe365 REST API v2 | Classe365 Support and Help Center

The Classe365 REST API v2 provides a powerful, programmatic interface to access and manage your institution’s data—including students, classes, sessions, departments, and more. Built on standard HTTP and JSON conventions, it allows you to seamlessly integrate Classe365 with third-party tools, automate routine administrative tasks, and build custom applications on top of your tenant.

Core API Characteristics

To ensure a predictable and consistent integration experience, our API adheres to the following principles:

Standard HTTP Verbs: We utilize standard methods like GET for reading data and POST for creating or updating records. The correct action is automatically determined based on whether a unique resource id is supplied in your request.
JSON Everywhere: All request bodies sent to the API and all responses returned from it use standard JSON format. Field names consistently use lowercase with underscores (snake_case).
Meaningful Status Codes: We use standard HTTP status codes combined with a consistent response envelope to help you handle results gracefully:
- 2xx – Success
- 4xx – Client-side errors (e.g., bad syntax, missing fields)
- 5xx – Server-side errors
Secure Transport: Every single request must be transmitted securely over HTTPS.

Base URL

Every API request you make begins with a Base URL structured specifically around your unique tenant subdomain:

Plaintext

https://<your_subdomain>.classe365.com/restv2

Note: Replace <your_subdomain> with the actual subdomain of your institution's Classe365 URL. For example, if you log in via evaluate3x.classe365.com, your base URL will be https://evaluate3x.classe365.com/restv2.

IMPORTANT:

Check out the documentation in the portal clicking on this link:

Authentication

The Classe365 API relies on HTTP Basic Authentication. Every single incoming request must include an Authorization header containing your tenant credentials.

How to Construct Your Credentials

Your authentication credentials consist of two parts:

Username: Your tenant's subdomain (e.g., if your URL is evaluate3x.classe365.com, the username is evaluate3x).
Password: Your unique API Key. This can be generated directly within the admin portal by navigating to Settings → API Keys.

Generate API Key

Click on ➕ Create API Key button to add an API key

Choose whether the API key applies to all modules or to specific modules, and select the modules that the API key will have access to.

For security reasons, the API key is displayed only once at the time of creation; please ensure that you copy the API key.

Notes:

Do not share your secret API keys in publicly accessible areas such GitHub, client-side code, and so forth.
To use your API key, assign it to Classe365.api_key. The PHP library will then automatically send this key in each request.
It is recommended to make all API requests be made over HTTPS. Calls made over plain HTTP is not secure and is not recommended. API requests without authentication will also fail.

To authenticate, join these two strings together with a colon (subdomain:api_key) and encode the entire string using Base64.

Required Request Headers

When constructing an API request, include the following headers in your payload:

Header	Expected Value	Required?	Description
Authorization	`Basic <Base64(subdomain:api_key)>`	REQUIRED	Authenticates your application with your specific tenant instance.
Content-Type	`application/json`	OPTIONAL	Required whenever you are sending a JSON payload in a request body (e.g., during a `POST` request).

Authentication Example (cURL)

Below is an example of how a standard request header looks when constructed in a tool like cURL:

Bash

curl -X GET "https://evaluate3x.classe365.com/restv2/students" \   -H "Authorization: Basic ZXZhbHVhdGUzeDpreXNqZDRmNThzYWRmODk0Y2Zh" \   -H "Content-Type: application/json"

Understanding the Response Envelope

To make integration predictable, the Classe365 REST API v2 wraps every API response in a small, consistent JSON envelope. This design allows you to write a single parsing function to handle data structure variations across all endpoints.

The HTTP status code in the response header signals whether the request succeeded or failed (it is never repeated inside the response body). Instead, the JSON body carries a predictable set of top-level fields based on the outcome:

Single-resource success: The requested resource is returned under the record key.
List success: An array of multiple resources is returned under the records key, occasionally accompanied by a meta object.
Empty success (204 No Content): Returns a brief message field; record and records are omitted.
Errors: Returns a human-readable message that ends with a stable (error_code: ...) segment, plus an optional errors array detailing specific validation failures.

Envelope Fields Reference

Field	Type	Appears In	Description
`record`	Object	`2xx` – Single	The single resource returned by the endpoint.
`records`	Array<Object>	`2xx` – List	The list of multiple resources returned by the endpoint.
`meta`	Object	`2xx` – Optional	Supplemental information about the dataset (e.g., pagination details like `total_count`, `current_page`, `records_per_page`, or custom fields). It is never part of an individual record. Note: Treat `meta` as additive; ignore unknown keys.
`message`	String	`204`, `4xx`, `5xx`	Provides context for the status. On a `204`, it explains why nothing was returned (e.g., `"Department not found with id 12"`). On errors, it contains a human-readable explanation paired with a stable error code segment (e.g., `"Required parameter(s) missing: id."`).
`errors`	Array<Object>	`400` – Validation Only	Used exclusively for data validation failures. Contains a list of objects detailing the specific `{field, code, message}` that failed validation.

HTTP Status Codes

Always inspect the HTTP status code in the response header first. The response body provides supporting details but will not restate the status code itself. Codes fall into three predictable bands:

2xx (Success): The request was understood and successfully processed. The body carries a record, records, or a message (for 204 statuses).
4xx (Client Error): Something about the request needs to be modified before retrying (e.g., bad credentials, missing fields, or structural validation errors). The body carries a message with an (error_code: ...) segment.
5xx (Server Error): Something went wrong on the server side. These are safe to retry after a short backoff period.

Code Reference Table

Code	Status	Meaning / Behavior
200	OK	The request succeeded (typically used for successful data retrieval or resource updates).
201	Created	A new resource was successfully created.
204	No Content	The request succeeded, but there is nothing to return. This happens if the requested record does not exist or a list endpoint matched zero rows. The body contains only a `message`; `record` and `records` are omitted.
400	Bad Request	The request is missing required parameters, contains malformed data, or failed validation checks (inspect the `errors` array for details).
401	Unauthorized	Authentication failed due to missing or invalid credentials in the `Authorization` header.
403	Forbidden	The credentials are valid, but you lack permission or the feature is disabled for your tenant instance.
405	Method Not Allowed	The wrong HTTP verb was used for the endpoint (e.g., attempting a `GET` on an endpoint that requires a `POST`).
500	Internal Server Error	An unexpected error occurred on the server. Your request can be safely retried later.

Questions? Write us to [email protected]

OR use in-app chat tool

Classe365 API Introduction

Integration with Stripe - Classe365

Rest API update : Phase 1