I would like to create a url button that redirects to the original location the record was opened from

You will have to have a button that they push (rather than the default pencil or eye ball buttons).

Within that button you will want to use the function "nextURL="  rather than using an RDR.

What would I set the nextURL to be. Users can  access the record from multiple locations when they hit the button I want some fields changed, the record closed and the user returned to location of origin

They this

URLRoot() & "db/" & Dbid() & "?a=API_EditRecord" &
"&rid=" & [Record ID#] &
"&apptoken=##########" &
"&_fid_16=COMPLETED" &
"&_fid_13= " & Today()
& "&z=" & Rurl()

As per http://www.quickbase.com/developer/articles/using-zrurl-and-rdr-formula-url-fields  "&z=" & Rurl() does not work for a=API_EditRecord. Also I may be mistaken but it seems that even if it did work it would bring me back to the same record I was on when pressing the button. In my case I want it to return me to the previous page, the one I was on before opening the record - as if I pressed save and close

Sorry, I don't know of a different answer than Matthews, but I suppose that you can make a bunch of different buttons each with a different &NextURL suffix.

APIs that return XML, JSON or other data interchange formats are not really designed to have their URLs loaded as new pages except perhaps in diagnostic situations as their response are not generally considered to be human readable. This of course applies to a=API_EditRecord (which returns XML) as well as the vast majority of methods in QuickBase's HTTP API.  When this is done the common convention among QuickBase users is to redirect away from the XML response by using an rdr parameter. This is a hack from the 90s. You should be using script instead of rdr parameters to control what happens next after calling your primary API. After the API is executed under script control you can redirect to any page you want or chain other processing or API calls into the workflow.

Continuing to use rdr parameters and other crude redirection schemes will continue to hold back QuickBase's progress.

I was drafting when a comment came in so I continue here:

Continuing to use rdr parameters and other crude redirection schemes will continue to hold back QuickBase's progress. In fact, the widespread introduction of redirection into formula URLs is probably one of the reason QuickBase did a reboot of their development plans. Using page redirection in formulas is preventing QuickBase from adopting a more modern "single page application" architecture.