smallbizapps's dashboard

smallbizapps replied on November 19, 2009 21:35 to the question "Trouble updating subscribers via the API" in Spreedly:

Great. Thanks, Duff. I'll be on the lookout.

smallbizapps replied on November 19, 2009 21:24 to the question "Trouble updating subscribers via the API" in Spreedly:

Would Spreedly server logs reveal anything about my requests and perhaps why the API is returning a 401?

smallbizapps marked one of Duff OMelia's replies in Spreedly as useful. Duff OMelia replied to the question "Please clarify subscription terminology".

smallbizapps replied on November 19, 2009 15:45 to the question "Please clarify subscription terminology" in Spreedly:

OK. I think that clears up a lot. As I start to implement more specific examples, I'm sure a few more questions will come up. Thank you!

smallbizapps asked a question in Spreedly on November 19, 2009 09:50:

Please clarify subscription terminology

Can someone please define/discuss the following concepts and how they related to one another, if they do?

1) Active vs. inactive subscriptions (active=true vs. active=false)

2) Complimentary subscription (only for inactive?)

3) Complimentary time extension (only for active?)

4) Free trial

5) Lifetime subscription

6) Subscription with auto-renew stopped

I would appreciate a brief commentary/discussion here but. ideally, I really think this should appear somewhere in your integration guide. I can't be the only one who would want to know the distinctions between these entities and how Spreedly defines/handles them. Lastly, I realize that some of the details/relationships could quite possibly still be in the process of being hashed out.

smallbizapps replied on November 19, 2009 08:14 to the question "Trouble updating subscribers via the API" in Spreedly:

I sent the two functions that I've written to your support e-mail address. Please treat it as pseudocode, as it's code that runs on a cloud computing platform and may not look like what you might be expecting. That said, you should be able to get the idea of what I'm doing. Again, the create code works, the update does not. (always returns 401).

smallbizapps replied on November 19, 2009 02:17 to the question "Trouble updating subscribers via the API" in Spreedly:

Thank you, Duff!

smallbizapps replied on November 19, 2009 00:26 to the question "Trouble updating subscribers via the API" in Spreedly:

Well, now I'm getting 404 errors even though the customerID I'm specifying exists. Guess it's better than a 401!

smallbizapps replied on November 19, 2009 00:02 to the question "Trouble updating subscribers via the API" in Spreedly:

HMMM.

Accordng to the main URL reference (http://www.spreedly.com/manual/integration-reference/url-reference/), an update is called via POST, not PUT. (Contradiction, anyone?)

Trying that now...

smallbizapps asked a question in Spreedly on November 18, 2009 20:54:

Trouble updating subscribers via the API

I've been able to successfully create subscribers and poll existing subscribers, but I'm having a lot of trouble updating an existing subscriber.
I keep getting 401 errors, which don't even show as a possibility on the documentation page. What's interesting is that I haven't changed how I'm specifying authentication information. If I use the same the code that attempts to perform an update, BUT change the URL to the one to create a subscriber AND change the PUT to a POST, the creation proceeds flawlessly. (Of course, I'd have to provide an unused ID and screen name...)

One thing I noticed in the documentation is that the update call via Curl (definitely NOT the methodology I'm using) sends the header in the body of the request. Is this indeed necessary?

As an aside, I also noticed that, according to the documentation (http://www.spreedly.com/manual/integration-reference/update-subscriber/), one updates a subscriber (via PUT) by specifying the screen name as follows:

<screen_name>joe the man</screen_name>

In contrast, the documentation for (http://www.spreedly.com/manual/integration-reference/programatically-creating-a-subscriber/) shows that one creates a subscriber (via POST) by specifying the screen name thusly:

<screen-name>freddy</screen-name>

Is the PUT example accurate? Why the difference in element names?

smallbizapps replied on November 18, 2009 20:32 to the idea "Accept Amazon Payments?" in Spreedly:

Got it. As long as it's on the radar. I'll stay tuned.

smallbizapps replied on November 18, 2009 20:31 to the idea "Site information should be able to be accessed programmatically" in Spreedly:

What I had in mind was to be able to have a real-time correlation between the sites listed in Spreedly and the sites an application knows about. Of course, you wouldn't want the object model to broadcast the authentication tokens for each site, BUT, at least Spreedly could indicate to the application that a site exists and that one needs to explicity associate the authentication token with the site object in order to access the sites data (subscribers, plans, etc.) programmatically.

Did that make any sense?

smallbizapps replied on November 17, 2009 18:52 to the idea "Accept Amazon Payments?" in Spreedly:

So, would PayPal also be considered "offsite", because I realize Spreedly offers that. Just wondering. I also realize that I was perhaps a bit too vague in my request. I think I should have been asking specifically for support of Amazon Flexible Payments service:

https://payments.amazon.com/sdui/sdui/business?sn=devfps/o

smallbizapps replied on November 17, 2009 18:44 to the question "Spreedly via WSDL?" in Spreedly:

I can't really describe them, so I figured I'd let Wikipedia help:

http://en.wikipedia.org/wiki/Web_Services_Description_Language

As for ease of implementation, I think importing a WSDL file would have made implementation and integration easier for me. I've finally figured out how to successfully integrate with Spreedly's API, but I think the WSDL process is more intuitive and I wouldn't have had to create as much code as I did / am doing.

smallbizapps shared an idea in Spreedly on November 17, 2009 15:56:

Site information should be able to be accessed programmatically

Much like individual sites, each account could have its own unique API authentication token. That way, one could determine the sites belonging to one's account programmatically. Site-specific details (name, short name, etc.) could be accessed through this addition to the object model.

smallbizapps asked a question in Spreedly on November 17, 2009 00:21:

Spreedly via WSDL?

Does Spreedly provide a WSDL for API access?

smallbizapps shared an idea in Spreedly on November 16, 2009 23:39:

Accept Amazon Payments?

Any plan to support Amazon payments?

smallbizapps replied on October 06, 2009 13:46 to the question "Builder seems to have gone AWOL again..." in Bungee Labs:

Yay. Thanks, Andrew!

smallbizapps asked a question in Bungee Labs on October 06, 2009 13:22:

Builder seems to have gone AWOL again...

The builder seems to have completely evaporated this morning. All I'm getting is:

Not Found

The requested URL /launch/1245/runtime was not found on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

Even if there is a planned maintenance, there's got to be a better way to handle this...

smallbizapps reported a problem in Bungee Labs on September 29, 2009 19:29:

Unusable dialog box(es) on small-format screens (read: netbooks)

The following is a request/demand/plea:

I often use a netbook for mobile computing and it has a relatively small screen. Now, I'm not expecting *everything* to be formatted for small screens, but screens/dialogs that can be, *should*

For example, it is currently not possible to post a solution because the version/comments dialog is so large that one cannot see/reach the post/accept/OK button at the bottom of the dialog box. Luckily, the Esc(ape) key allows you to back out of it (or I would have been in serious trouble). The Enter key should cause the dialog to be accepted. In addition, the comments box could be made smaller and/or provide a scroll bar.

I haven't necessarily run into this with other dialogs specifically, but these guidelines should be applied across the board, where possible.

With the popularity of netbooks increasing, this just makes sense.