smallbizapps's dashboard

smallbizapps replied on December 01, 2009 10:36 to the question "Difficulty assigning a newly-created subscriber to a free trial plan" in Spreedly:

I decided to leave this question up, with the hope that it might help someone else diagnose a similar mistake. If it is felt that it's not helpful, I'd be happy to delete my post.

smallbizapps replied on December 01, 2009 10:29 to the question "Difficulty assigning a newly-created subscriber to a free trial plan" in Spreedly:

NEVER MIND!! It was my fault. I specified the wrong plan ID (one for a "paid" plan) and that's what was causing the 404. Once I specified the correct plan ID for a free trial plan, everything worked without a hitch.

A comment on the question "Manipulating subscriber and plan properties programmatically" in Spreedly:

Funny, I hadn't checked the response body, but I just did and I have found that it very nicely communicates what the problem is. Spreedly for the win! :-) – smallbizapps, on December 01, 2009 01:49

smallbizapps asked a question in Spreedly on December 01, 2009 01:41:

Difficulty assigning a newly-created subscriber to a free trial plan

I've successfully written a function that creates a new subscriber via the API. I've also written a function that successfully assigns a gjven subscriber to a free trial plan. Now, I would like to automatically assign a newly-created user to the free trial plan. Unfortunately, this is causing problems. If I attempt to call the "assignToFreeTrial" function right after creating a new subscriber (which successfully returns a 200,) the free trial assignment returns a 404.

Could this be due to a small lag as the actual subscriber is created?

If I "manually" summon the free trial assignment, it works just fine.

Any ideas?

A comment on the question "Manipulating subscriber and plan properties programmatically" in Spreedly:

I suppose that the Spreedly UI is fine, but I just didn't know what I could do and what I could not do. I have received the 403 error and because it wasn't documented I didn't know whether this issue was indeed the problem or it was something else. – smallbizapps, on November 30, 2009 16:54

smallbizapps asked a question in Spreedly on November 29, 2009 20:00:

Manipulating subscriber and plan properties programmatically

It appears that some subscriber properties are directly manipulable (that is, they can be set when updating a subscriber) whereas others must be handled by a Spreedly operation (e.g., allow this subscriber to be eligible for another free trial). Am I correct in this assumption?

If so, it would be very helpful to have a chart or other documentation illustrating which properties can be set directly. In addition, if a property cannot be set directly, it would be useful to know what affects the property's value.

On that note, this information would be useful for subscription plans as well.

I would have guessed that the <lifetime-subscription> property would be directly manipulable, but I can't seem to set it programmatically (via subscriber update). Is this true, and if so, is that by design? Otherwise, how *do* you set it programmatically?</lifetime-subscription>

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.