Charity administrators can configure which channels are requested from end-users. View more details here

We now more accurately represent this logic in the /marketingPreferences end-points where unused channels return as "null" rather than "false" which can impact data recorded in a third-party system such as a CRM.

Example response for "Post" channel disabled

[
        {
            "answeredAt": "2025-03-04 09:00:01",
            "supporterId": 9876543,
            "charityAccountGuid": "a12345b6-7890-1cd2-345e-f678f90gh1ij",
            "emailOptIn": true,
            "phoneOptIn": true,
            "smsOptIn": true,
            "postOptIn": null,
            "charityId": 1234,
            "allowedToContact": true,
            "permissionStatement": "We'd love to keep you up to date with our projects and fundraising activities. Please let us know if it's okay to contact you. We'll never share your data.",
            "campaignGuid": null
        }
  ]

Previous response for "Post" channel disabled

[
        {
            "answeredAt": "2025-03-01 09:00:01",
            "supporterId": 9876543,
            "charityAccountGuid": "a12345b6-7890-1cd2-345e-f678f90gh1ij",
            "emailOptIn": true,
            "phoneOptIn": true,
            "smsOptIn": true,
            "postOptIn": false,
            "charityId": 1234,
            "allowedToContact": true,
            "permissionStatement": "We'd love to keep you up to date with our projects and fundraising activities. Please let us know if it's okay to contact you. We'll never share your data.",
            "campaignGuid": null
        }
  ]

Today we release enhancements to the above mentioned endpoints in lieu of a page cursor parameter implementation to ameliorate issues some of our larger charities encounter with the page parameter.

More efficient use of the date_from and date_to parameters is proffered as the interim solution and clients are encouraged to use them alongside the limit parameter. The idea is to while holding date_from param steady shift the value of the date_to param relative to the value returned from last record in the most recent result set and to totally ignore or stop using page parameter.

Clients who, for example, run a daily schedule to retrieve /registrations are encouraged to provide date_from=<date_previous_day> 00:00:00 and date_to=<date_previous_day> 23:59:59 with limit=100 like so:

curl --location '<https://dataapi.enthuse.com/registrations?access_token=><token>&limit=100&date_from=2025-02-10%2000%3A00%3A00&date_to=2025-02-10%2023%3A59%3A59'

Subsequent calls can then be made with:
date_from=<date_previous_day> 00:00:00 and date_to=<response’s final entry’s changed_at> with limit=100 and can carry on doing this until there are less than 100 items in the last response.

Clients who run a daily schedule to retrieve /supporters are encouraged to provide date_from=<date_previous_day> 00:00:00 and date_to=<date_previous_day> 23:59:59 with limit=100 like so:

curl --location '<https://dataapi.enthuse.com/supporter?access_token=><token>&limit=100&date_from=2025-02-05%2000%3A00%3A00&date_to=2025-02-05%2023%3A59%3A59'

Subsequent calls can then be made with:
date_from=<date_previous_day> 00:00:00 and date_to=<response’s final entry’s last_updated_at> with limit=100 and can carry on doing this until there are less than 100 items in the last response.

As of Dec 16th 2024 pagination will work as expected for /payouts/{payoutUuid} endpoint. This enhancement ensures that calls to this endpoint for large payouts will no longer timeout. It provides clients with the ability to retrieve payments in a payout in a paged manner using the page and limit parameters as is available across the API. The /payouts/{payoutUuid} endpoint also now provides 1-based page numbers instead of 0-based pages. In other words, the first page is now page 1 as opposed to page 0.

When page is not provided the endpoint defaults to returning page 1. When limit is not provided the endpoint defaults to returning the 25 payments in a payout. The maximum limit for returned records clients can specify is 100.

Clients will receive a 400 error when providing page numbers below 1. Clients will also receive a 400 error when providing limit below 1 or more than 100.

We have introduced a V2 Registration API endpoint on the November 1st 2024.

The following data is now available in RegistrationV2:

These enhancements will improve the data we are able to offer and increase flexibility in how we manage and deliver information to you. Find out more in our developer centre here.

The following new filtering options are available in RegistrationV2:

The following aspects have been removed from V2 but remain available in V1:

V1 registration end point will remain available to ensure you still can access the current data you need as part of your registration journey.

A null value was being returned between Sept 24th 2024 and Oct 15th 2024 instead of an empty array.

This issue has been resolved as of Oct 16th 2024 with an empty array being returned where applicable.

Donation data had not been populating within the Registrations endpoint with null values returned.

This issue has been fixed with data for donation_id and donation_amountnow being populated as expected in the Registrations endpoint.

For example:

..
"donation": {  
  "donation_id": 12345,  
  "donation_amount": 10.0  
},
..`

As of 1st August 2024 will be adding pagination to all our public API endpoints. Each request will now return a maximum of 100 items.

Key Details

• Max Limit: Maximum of 100 items per request.
• Data Retrieval: To access more data, you will need to loop through the paginated results by making successive API calls if total rows exceeds the limit.
• Information Object: Information Object: Each response will include a page_count indicating the total number of pages for the request

Why This Change?
This adjustment is designed to ensure the reliability and efficiency of our API. By introducing pagination, we can better handle large volumes of data, thereby continue to provide stability.

Action Required:
Please review your integration and ensure all endpoints have a defined limit with pagination in place before 1st August 2024

For further details on our API's, refer to our [documentation.](API documentation.)

As part of our ongoing efforts to enhance our API capabilities, we have implemented improvements to the following endpoints:

Marketing Preferences
Schedules

With these updates, all our endpoints now benefit from enhanced performance and stability when integrating with our platform, completing our efforts to improve API reliability across the board.

In line with our ongoing commitment to enhancing our API capabilities, we have released improvements to the following endpoints:

• Payments
• Payouts
• Supporter
• Personal Fundraising
• Event Fundraising
• Team Fundraising

These changes will improve stability and performance, when integrating with the above end points on our platform.

We continue to improve our API experience and we will update you on future developments again soon.

In line with our ongoing commitment to enhancing our API capabilities, we have released improvements to the architecture of the Registrations endpoints to improve stability and performance.

These improvements guarantee smoother, more dependable interactions, when integrating with our platform.

Our dedication to delivering a great API experience remains a priority and we will update you on future developments again soon.