API missing input parameter

David Richardson

I have a two API requests that use the same strategy to get information.  One GET is for a user that requires a parameter that shows up like this:

/artist/{member_id} 

the other GET

/artist/artistPortfolio

The latter also requires the {member_id} parameter but the parameter  doesn't show up in the API request as expected.  Is there an explanation for this?  Bug? Feature?  Thanks.

Sean Montgomery

 we previously had a bug where you could accidentally get into this state. The bug is fixed but the fix only prevents you from doing this again - not dealing with existing bad state.

If you have an endpoint with a variable, then you can't have a constant that would get mapped to that variable.

In your example it thinks artistPortfolio is member_id.

The quick fix is to just change the 2nd endpoint to something like /artist2/artistPortfolio

You can pick something nicer naming wise, but it just needs to not be confused with the variable entry.

David Richardson

Actually my dyslexia struck again!  I said in my original post the second API was /artist/artistPortfolio/ when it's actually /artistPortfolio/ - which is incorrect.  It should be /artistPortfolio/{member_id}

I can see why you thought what you did and suggested what you suggested.  My bad.

What I'm doing from a JS coding perspective is getting the webflow-member-id from Memberstack (the WMX tutorial) when the page loads and then appending the ID to the API request (actually all the APIs to maintain security) for GET and POST API requests.  I figured that out myself thinking I was clever but a coder friend assured me that's just the way it's done.  Seems like a more practical implementation of the WMX functionality.  

I cloned the /artist/{member_id} and did an "addon" to get the portfolio. Then just ditched the API that's compromised.

David Richardson

re WMX • Part 2 • How to build a Membership site with Webflow, MemberStack, and Xano.

What I WANT to do - use the webflowMemberId as the input parameter to generate datasets in Xano specific to each user and specific to the membership they have in Memberstack.

After noodling around with different strategies to obtain the webflowMemberId for each page I loaded - the solution that worked was I generated a cookie.  Cookies live on the client machine so values are readily available with no latency.  I set the cookie (name:value pairs) for the id and the membership name and that I can use where users access data - registration, updating account information, all the CRUD, specific to each account.

I found some JS code examples online that sets a cookie but I also had to figure out HOW to set the cookie AFTER the value landed on the page AFTER logging in or signing up.  THAT required the user to interact with the page.  The steps were not all that clear to me initially but here are the steps that did finally work:
1) Home page -> log in or sign up through Memberstack ->
2) Memberstack modals -> redirect back to your site to the...
3) Welcome page -> with buttons or links (that set cookie)
4) User clicks -> Cookie set with the WMX values then ->
5) redirects to pages on your site to fill out or modify user accounts data.  

Since the cookie is available on the other pages on the site you can read the cookie and concatenate the membership id to do all the Xano CRUD APIs.

On the "Welcome" page, I used a onmouseover event hovering over a button that took the user to the next page.  The hover event triggered setting the cookie.  I believe there are legal requirements to gain permission to set a cookie.  I will generate that step soon and THAT will probably be the event that sets the cookie with the Memberstack values. The user interaction allowed the page to load fully and values to load from Memberstack - taking milliseconds maybe but too much time where I was in "can't read a null value" hell.

Webflow limits users to a single webhook for form submissions (many complaints already registered on that one).  That Webflow limitation requires a custom Xano API to sort through all your different form names to figure out which form was submitted AND what input variables will be in the data packet from Webflow.  The JSON data packet is "data" (see Prakash's videos).  (I put the form name in a hidden field in the form for simplicity but it's available in the JSON packet from Webflow).  

Webflow forms make it very easy to redirect a user to a different page clicking the "SUBMIT" button.  The default form element is the "email form" but deleting the input fields - or setting their CSS to "display none" - leaves the HTML button element that can easily be edited in the Webflow environment. 

You can edit the form name from "email form" to anything you want.  But EVERY form submission (or modified button click) will be fed through your ONLY Webflow webhook ending up in your Xano custom API that sorts all this out.  You will need to build this custom API for your website for all this to work.

I figure the first part of that function stack will be a function that catches form names with a leading underscore and thereby disregard them:  like "data.formName:_myButton" Subsequent functions in the function stack figure out how to handle the data packets that actually have CRUD data.  Those form names will NOT have the leading underscore.

Memberstack memberships offers the ability to restrict users to pages only those pages logged in membership members SHOULD see - account pages or forms to update their accounts or to track their likes or purchases. 

The way I set this up in the "Welcome" page is the buttons from each of the different form elements redirects the logged in user to the appropriate page.  When the user hovers over the button to click it, that hovering triggers setting the cookie with the webflowMemberId.  That value and the membership they signed up for restricts what pages they can view during the rest of their logged in session.

Memberstack offers code snippets that show and hide certain menu items in the main menu.  I haven't learned how to use them yet, but they exist.  That allows me to hide and expose registration page links and even website folders.

Now I can SET a cookie and easily use the cookie values to show or hide data relevant to particular member / users throughout the entire site.

Retrieving API data - especially larger data sets - may require the use of JavaScript promise code that is rather confusing to use.  But if your page is slow to load, might be a problem.  That might be something the people at Xano could make a video on.