Luminate API documentation updates

Elizabeth Favre

Do you use the Luminate Online APIs? Do you know where to find the documentation? Is the documentation helpful? What improvements would you like to see in these documents?

Jeremy Reynolds

@Elizabeth Favre
It'd be great if we could get some filters to find things.

• super-amazing would be if there was an ability to input a specific server response we need and see all the methods that can return that.
• Filters for the servlet (CR/SR), HTTP Methods (GET/POST), and RequiresAuth. The boxes at the top of each method page are helpful, but it takes forever to check each page one-at-a-time.
  • And RequiresAuth might be a little too simple. We've got methods that need a non-login public token, others that can use an SSO token, others that need username/password, and a mix of “forbidden for administrators” CR methods.

Implementation examples and libraries are over a decade old, dunno if there's new stuff out there.

• I don't think that LuminateExtend or Angular Luminate Utils are anywhere.
• Worth considering adding some really core techniques, such as creating a “Roll Your Own API” in PageBuilder, or “Here are a generic JS fetch() and jQuery $ajax() implementations to capture a public token using getLoginURL.”
• Cross-linking to S/L/T/U/A Tag documentation…I can't think of many implementations that don't include some sort of “make a PageBuilder page then use S51 to spit it into your ____”

Some specific documentation I recall having trouble with in the past:

• Parameter formats. For example, documentation might say the param is boolean, but doesn't tell whether we should use “false” or “F” or “0” to specify that.
• GetTeamRaisersByInfo (and some other locations)… &full_search requires a boolean, but then the doc says you can use status codes instead. Either that feature is broken, or there's an undocumented param to specify the desired code (e.g. &full_search=false&status=123).
• Authentication documentation could probably benefit from a rewrite. ReCaptcha v3 documentation was fairly rough, if I recall.
• list_sort_column and list_filter_column can be just about impossible to figure out, as many of the server responses don't match the SQL header. For example, I recall there being one where the fundraising result could be sorted by results, but it was amount, dollars, or total depending on whether you're looking at the S42 tag, JSON response, REST URL, or the field names in LO.

It's be rad if method pages had a “try it” like what's in the NXT API.

Won't get too deep into the SOAP stuff, but would quickly mention that it could be helpful to give a little more detail around query language and webconsole. It's kinda odd that the language is a downloadable file instead of being on-page like it used to be on convio. It's a little bit unclear exactly elements of SQL are allowed, for example it mentions aliases without mentioning AS command, or join without specifying inner/outer/left, etc.

Elizabeth Favre

@Jeremy Reynolds
This feedback is extremely helpful. Thank you so much for taking the time to share!

Kelly Bodie

@Elizabeth Favre
Hello again!

Stumbled across this because I tried KB 63194 about survey scrape and I have a hunch the better process is to use LO API (based on other community things I read).

I have never used LO API, so my feedback is going to be much different from Jeremy.

In Getting Started > Testing > Client API testing, I got as far as step 9, then received an error code. I see that error code is listed under Reference, but I don't know how to fix it or where in the documentation it helps me troubleshoot.

Now I'm looking at getSurvey. As a beginner, I don't know where I can put that block of code on top. Any website (my final goal is a popup on Wordpress)? A pagebuilder page? Somewhere else entirely? Do I have the wrong idea all together?

It's okay to tell me: Kelly, better leave API to the actual developers. But in the case you're hoping your documentation will help lay-coders like myself, I'm missing a piece or twelve. ?

Erik Leaver

@Kelly Bodie The API approach is technically much more challenging than scraping a survey. If you want to get started, the best approach is to use the luminateExtend library that Noah Cooper developed. You'll see in the examples, he includes an email sign up survey:

Elizabeth Favre

@Kelly Bodie
I am right there with you Kelly! Being a lay coder myself, I often wonder what is the audience for our API docs. It's great if it is engineers and developers look at

and think, “I can do that!" But I look and that and think, “I have the code, but where do I put it?”

I don't have the answer yet about the right level of technical information, but I can tell you that we are doing some user research to find out.

I really appreciate your input!