Skip to main content

GoFundMe Pro / Classy Connector (Technical Documentation)

Written by Philippe Trussart

Overview

The Classy connector provides read-only access to data from the Classy API for a configured organization.

The connector retrieves each selected dataset from an organization-scoped endpoint and loads all available pages on every run. It does not create, update, or delete records in Classy.

The API base URL is:

https://api.classy.org/2.0/

Authentication

The connector requires:

org_id client_id client_secret

Authentication uses the OAuth client credentials flow.

The connector requests an access token from.

POST https://api.classy.org/oauth2/auth

with:

grant_type=client_credentials client_id={client_id} client_secret={client_secret}

The returned access token is then sent with API requests as:

Authorization: Bearer {access_token}

A new access token is generated at the beginning of each sync. If Classy returns 401, the connector generates another token and retries the request.

Connection test

The connection test verifies that the supplied client credentials can successfully generate an access token.

It does not query an organization data endpoint during the test. As a result, a successful connection test confirms valid credentials, but does not necessarily confirm that the credentials have permission to access every configured Classy dataset for the supplied org_id.

API Requests

There are two main request types:

Operation

Method

Purpose

/oauth2/auth

POST

Generate an OAuth access token

/2.0/organizations/{org_id}/{endpoint}

GET

Retrieve Classy data

There are no PUT, PATCH, or DELETE requests.

Data requests follow this pattern:

GET /2.0/organizations/{org_id}/{endpoint}?page={page}&per_page=100

The exact endpoint for each dataset is defined in the connector's Classy schema configuration.

Sync Behavior

The connector performs a full read of each selected dataset on every run.

There is no incremental bookmark, last-modified filter, or persisted synchronization timestamp.

For each table:

  1. Page 1 is requested.

  2. The response's last_page value determines how many pages exist.

  3. Remaining pages are retrieved sequentially.

  4. All returned records are processed.

The page size is:

100 records

which is the maximum page size configured by the connector.

Because datasets are fully reread, consumers should expect the same Classy records to be returned across multiple syncs.

Schema & Record Behavior

The connector uses a predefined Classy schema rather than dynamically discovering columns from API responses. Each dataset defines its expected columns, data types, endpoint, and unique key fields.

When an expected field is missing from a Classy response, the connector supplies:

NULL

for that field.

Configured datetime fields are normalized into ISO-style timestamps. If a datetime value cannot be parsed, it becomes NULL.

Additional API fields

The record-processing logic does not explicitly remove fields that are returned by Classy but absent from the predefined schema. It primarily adds missing expected fields and formats configured datetime fields.

Consumers should therefore rely on the documented/schema-defined fields for stable downstream models rather than assuming every additional API property will always be available.

Deletes

The connector does not explicitly synchronize deletes.

It does not:

  • Query a deleted-record endpoint

  • Generate delete events

  • Compare the current Classy dataset with a previous snapshot

  • Issue DELETE requests

Because the connector fully rereads source data but does not perform deletion reconciliation, a record removed from Classy should not automatically be assumed to disappear downstream.

Retries & Rate Limits

Failed API requests are retried up to 5 times after the initial attempt.

The connector uses exponential backoff:

30 seconds 60 seconds 120 seconds 240 seconds 300 seconds

with a normal maximum delay of 300 seconds.

For HTTP 429 responses, the connector also reads Classy's:

Retry-After

header. If Classy requests a longer wait than the normal calculated delay, that longer delay is honored.

403 Forbidden and 404 Not Found errors fail immediately rather than being retried, because retries are unlikely to resolve permission or missing-resource problems.

Known Limitations & Notable Behavior

  • Syncs are full rereads. There is no incremental state or last-modified filtering, so sync duration and API usage can increase as the Classy organization grows.

  • Deletes are not propagated. Records removed from Classy do not generate explicit downstream deletion events.

  • The connection test only validates authentication. It does not confirm that the configured org_id or every selected endpoint is accessible. Permission problems may therefore appear only during an actual sync.

  • Schemas are predefined. New Classy fields are not automatically added to the documented schema until the connector's schema configuration is updated.

  • Unexpected API fields may still be present in records. The connector does not explicitly strip them, but they should not be considered stable schema fields.

  • Invalid datetime values become NULL. This can be important when troubleshooting missing dates.

  • Large datasets require many paginated requests. Each request contains at most 100 records, so large organizations can generate significant API traffic.

  • Rate limiting can extend sync duration. 429 responses trigger exponential backoff and honor Classy's Retry-After value.

  • Access tokens are regenerated automatically. A 401 response causes the connector to obtain a new access token before retrying, so consumers generally should not need to manage token expiration themselves.

Did this answer your question?