nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Feedback on the RE NXT SKY API

Jonathan Kay

Hi all,

We have been working with a Blackbaud customer to create a RE NXT version of our software (we already have editions for use with other CRM systems). We've now reached the point at which UAT testing can begin, but getting to this stage wasn't easy.

The client has given me permission to post an ‘Issues log’ that we've been maintaining during the course of the development. There are sections relating to each endpoint (just those we've needed to use so far) and within each section is a list of issues along with an ‘Impact’:

Unexpected API behaviours, inconsistencies or things that end up requiring more API requests than we'd normally expect. These items don't concern the client directly (and we've employed workarounds where necessary).

Medium

Has a minor impact on the client and we cannot provide a workaround.

High

Has a major impact on the client and we cannot provide a workaround.

I'm sharing this with the group for other developers to review (hopefully including those at Blackbaud that work on the API). I expect some of these things have been seen before and perhaps there are other options we're not aware of. In particular, I'd like to know if there are any solutions/workarounds to the ‘Medium’ and ‘High’ impact issues (it's quite possible we may have missed something in the documentation).

Thanks in advance,

Jon.

SKY API ISSUES LOG.pdf

Find more posts tagged with

Comments

Alex Wong

@Jonathan Kay

Below are my opnion as I have extensively used SKY API and have data warehouse setup myself for my org, and i do not work for Blackbaud.

1.1 - not sure what you mean by prettified. but minified JSON or not should not affect the way you parse the returned data for use, while you did list as LOW, not sure why it's even listed
2.1 - pro/con to what you asking for, but the upcoming QUERY API will take care of a LOT of this
2.2 - rather than having multiple “object” for email, phone, etc. It is better to just add these as array of these objects
2.8 - this is a bug. The API support the creating of note with summary (webview terminology) > description (db view label) where this field does have a 255 characters limit. The bug is, the 50 character limit is on the title (db view label) field, which is not even available on webview to pull from existing data in db nor in API. You should report this as a bug to support.

Most other comment you have I agree with, though I work around limitation.

I'm surprise you did not have any comment on the limitation on pledge and stock related, makes me wonder what integration you built for your client, but understand it is confidential info to not share.

Jonathan Kay

@Alex Wong

1.1 - Thanks for your reply. Regarding this (and 3.1), prettified JSON is intended to be human readable and contains lots of unnecessary whitespace. This significantly increases the response size and affects performance (more data to send back over the wire). It's because we don't need to read it that I reported it. I omitted many other inconsistencies around naming standards, error messages, etc, but this is bad-form in a production environment.

2.1 I'll look forward to the ‘Query API’. In the worst case we're having to make up to 15 requests to update information for a single constituent. Do you have any further details on this new API (time scales and the like)?

2.2 Agreed, and I mentioned an array of objects would be ideal. I was thinking of backward compatibility by suggesting up to three objects (they will need to retain at least one of each type or they'll break existing code).

2.8 I will create a case for this. I wasn't sure whether BB devs look at the messages on this board.

Regarding Pledges and Stocks, these are in the ‘Gift v2’ endpoint which we've not had to use so far. We likely will in the near future and your comment here doesn't fill me with confidence!

Jon.

Heather McLean

@Jonathan Kay
Thank you for this feedback. I will review it against my known gaps and workarounds list.