Almost two years ago, Simon Solutions announced our API Beta program and gave our Pro customers the ability to access their data programmatically.

When we first built the API, we had a clear and practical goal: to give CharityTracker and Oasis Insight a way to talk to other software. Our agency partners needed their data to connect with the tools they were already using, and programmatic access was how we made that happen.

That foundation worked, but partners began asking the API to do more. They reached for it to power business intelligence, data visualization, and efforts to keep their data in sync across systems. These were genuinely new uses, and they pushed on parts of the API we hadn't built for them. Our data is complex and deeply interconnected, so partners ran into friction finding their way through it, and the growing volume of requests put real strain on our systems as we worked to meet each one's needs.

So over the past two years, we've been steadily upgrading our infrastructure and codebase. The goal wasn't just to support these specific uses, but to build a foundation strong enough to carry the bigger initiatives we know are coming.

Today, we are excited to announce the first round of these upgrades are coming next week on Wednesday, June 17th, 2026 - API Beta Version 1.2!

Beginning with Beta Version 1.2, we will be using a new API documentation platform which will combine our in-depth endpoint-by-endpoint documentation with our API tutorial documents.
​
We have further organized our endpoint action documentation based upon the core resource - for example the GET, PATCH, and POST documentation are now organized underneath the CASE model.

In order to provide better clarity into the structure of how your data is organized within CharityTracker and Oasis Insight, we've prepared Entity Relational Diagrams at the category level for most endpoints which encompass the models within the category. Some categories however only have ERDs at the model level due to complexity.
​
We are working on descriptive documentation for all data models at the category level that provides a better picture of what each model does and how it relates to the rest of the application.
​
This documentation will be made live via https://apidocs.simonsolutions.com when the Beta Version 1.2 upgrade is made available.

Additionally, we are working on updating our Postman workspace package to incorporate all the changes made in the Beta Version 1.2 upgrade. While the workspace will not be available at the initial release, we expect it to be available shortly after!

By default, the API will still return 10 records per requested set. Users may increase this pagination set by passing a page_size query parameter - api/v1/cases/?page_size=100. At this time the max limit for page_size is set to 100, but we will be adjusting this value as our infrastructure upgrades progress further.

If you require an increase of your maximum page_size value, please contact apisupport@simonsolutions.com with your requested pagination maximum and use case. The API support team will review your request and follow up with additional information.

In prior versions of the API only certain related record fields supported expansion. Starting with API Beta Version 1.2, all foreign record fields will be accessible for expansion via an expand query parameter - api/v1/cases/?expand=household.

Additionally, these field expansions may be used in combination, like so: - /api/v1/cases/?expand=household&expand=entry_agent

Finally, we've also added support for full recursive expansion via the "all" property for the expand query parameter - /api/v1/cases/?expand=all.

As the "all" property will expand all related models, we recommend allowing for additional processing time in your requests to accommodate the additional data prepared by the system.

One of the major focuses for us throughout the upgrade process has been enhancing and expanding filtering support. Starting with version 1.2, filters are now globally accessible upon every endpoint for every applicable field.

We have also enhanced the functionality of existing field-level filters:

Wildcard Filtering:

Wildcard filtering has been added for all fields that support user alphanumeric input. If you are implementing this for the first time, we recommend using Asterisk "*" filtering. (See Deprecation of % Wildcard below).

Date / DateTime Filtering:
In addition to __before and __after suffix filters on date fields, users will now have access to __gte and __lte (greater-than-or-equal-to and less-than-or-equal-to respectively) suffixes. These filters accept both date strings in the currently supported YYYY-MM-DD format, as well as datetime timestamps such as 2026-06-01T12:30:45.

Boolean (True/False) Filtering:

We have enhanced our boolean field filtering support to include common aliases for True values: true, t, 1, on, yes. All other values are evaluated as False.

Phone Filtering:

In order to support future enhancements for the international E.164 standards, we have enhanced our phone number filtering for records that support it. We have also added wildcard filtering to support both E.164 format (+12223334444) and NANP format (222-333-4444). Please refer to the updated API documentation on Phone Numbers for more information.

Filtering by Related Record Value:

You may now filter primary records via related record values via double-underscore ("dunder") notation. For example, if you wanted to see all cases entered via agents of a specific agency, you may use either of the following:
​/api/v1/cases/?entry_agent__agency=1
​/api/v1/cases/?entry_agent__agency__name=My%20Agency%20Name

Note: You cannot filter based upon related record sets such as the casedetail_set list on the Case endpoint api/v1/cases/. In situations like these, you can use a combination of reverse-filtering and expansion from the set's record endpoint, such as /api/v1/casedetails/?detail=13&expand=case.

Filtering by Lists:

You may now filter integer-represented records via list formats, such as:

/api/v1/casedetails/?detail=10,13,18

/api/v1/casedetails/?detail=10|13|18

/api/v1/casedetails/?detail=10&detail=13&detail=18

/api/v1/casedetails/?detail[]=10&detail[]=13&detail[]=18

Note: List formatting filtering performs an additive OR joining operation and does not support conjunctive AND filtering, meaning results matching any of the provided values will be returned, not only those matching all of them. List filtering is only available for integer or integer-represented fields such as record IDs.

Another enhancement we've added to the API is the ability for users to order datasets based upon their prioritized field. This may be achieved by adding the order_by query parameter to your request. By default these fields are ordered in ascending order, but you may add a minus sign (negation notation) to the ordering field to swap to descending order.
​
For example to order cases by the newest cases to oldest cases entered:
​api/v1/cases/?order_by=-entry_date

For users using the API to maintain data parity with external systems, we have introduced a new utility for every endpoint to assist with this endeavor - /get_ids/.

This endpoint will return a paginated set of 100,000 record IDs which may be used to determine records added to or deleted from the system.

Additionally for users that are interested specifically broad metrics or in validating external datasets, filter and ordering parameters are passed into the parent endpoint. For example: /api/v1/cases/get_ids/?entry_date__gte=2026-06-05T15:40:30 will only return IDs that would be returned from the same /api/v1/cases/?entry_date__gte=2026-06-05T15:40:30 query.

Affected endpoints:

Merged Case records will now have two new additional fields, "status" and "errors" which display the the current status of a merge being processed and any errors that may have occurred during the merge.

For users with solutions that establish contract-payload schemas with strict validation, you will need to update your schema definitions with these new fields.

Affected Endpoints:

Previously the API returned file values that pointed to the mounted file location on the server system, an inaccessible path that was only marginally useful if you had a media export archive.

We have replaced these fields with file_name and file_url which provide the web accessible resource for all endpoints.
​

For Release of Information records, these fields are listed as uploaded_roi_name and uploaded_roi_url instead of file_name and file_url.

Originally our team included percentage sign wildcards "%" as an assistive and familiar element for users that are familiar with its usage in several database environments.

Unfortunately this usage, when not URL encoded, conflicts with URI formatting standards. You may find more info about this standard here:

RFC 3986 - https://datatracker.ietf.org/doc/html/rfc3986

In order not to conflict with established URI standards, we will be deprecating the usage of the "%" wildcard in favor of the asterisk wildcard "*" with a future release. If your solutions use the percentage wildcard, we recommend changing to the asterisk format as soon as possible.

Deprecation of this functionality will begin on September 30th, 2026.

As part of our ongoing efforts to streamline and maintain the API, we will be retiring the hyperlink serialization functionality (?use_hyperlinks=true) in a future release.

If your solutions use hyperlinks returned in data payloads by the API, we recommend creating the appropriate request harnesses and switching to the standard serializer as soon as possible.

Deprecation of this functionality will begin on September 30th, 2026.

We're excited about what these improvements make possible for your integrations and look forward to supporting you through the transition!

As a reminder - the API is not supported in the same way as the rest of CharityTracker and Oasis Insight. Please do not submit tickets, live chat requests, or phone calls to the support team. Instead, please direct all inquiries to apisupport@simonsolutions.com