And for the reference of other users and prospective users, I did receive an email reply to my previous question. NationBuilder also doesn’t support these characters in emails:

excl. point (!), number (#); dollar ($); percent (%); asterisk (*); f. slash (/); q. mark (?); caret (^); grave accent (`); left or right brackets ({ or }); v. bar (|); or the tilde (~). Quotes are not accepted either, so in turn, the rules that apply to quoted strings are not either.

As Lauren has explained above, this situation is pervasive throughout NationBuilder, so valid email addresses will be rejected regardless of how they’re entered.

Can you paste your payload here?

As a solution, can I suggest updating the API documentation to reflect the reality of the Address 3 field, and to include which attributes/resources are read-only?

At a more basic level, there is a relationship between people and donations at the datamodel level (i.e. the NB database has a relationship between people and donations).

This is also evident in the individual Person view in NationBuilder, donations for an individual can be seen. However, this doesn’t exist in the API. The current work-around is to request all of the donations which exist, which of course brings with it time complexity issues.

This causes several issues for anybody wanting to use the API:
1 – It prevents donations being created from an external source, as there’s no way to check if a donation against a member already exists.
2 – It prevents reporting being done on a by-member basis
3 – It prevents any external donations software from displaying an individual member’s donations
4 – It means that the API doesn’t reflect the underlying data model.

These are all significant issues, the industry standard is major relationships like this are typically reflected by the API. Any one of the solutions above would mitigate this issue, but the most robust solution is either inclusion in the person object or the creation of an individual-specific donations API endpoint.

Our site which runs over SSL would have its Facebook like/share counts set to 0 if this change were implemented.

This workaround must be at the discretion of individual sites, or will negatively affect more Nations than it will positively affect.

@Andy I agree that it should be fixed, but it’s worth noting this is more of an issue with the API than with the Explorer. It looks like the Search endpoints are much more strict than the other endpoints, and so any extra url parameters you pass will cause errors rather than just being ignored like the other endpoints. The fix I suggest here is just the quick-and-dirty method of fixing it.

This being said, if you’re using the search endpoint, I suggest using PostMan or something to test it; and being aware that 400 errors can be caused by accidentally misspelt parameters, or additional parameters which are not in the endpoint’s spec.