Foxy Forum Status

We're no longer responding to questions via our forum, but we will keep it up for historical reasons. If you can't find the answer you're looking for, please visit our knowledge base or contact us. If there's enough interest in the future, we may bring the forum back.


itisnot_meitisnot_me Member
in Help edited February 2011
i know that i have a few discussions open but they are kind of all different.

ok so looking over the api i am lost at what is really to do.

the documentation just looks like it gives you the options and what is needed if you can to use an option. but what it doesnt tell me is how to actually put it into the script (example script) so i can do what i need.

i know that you need to start with the datafeed key

but everything else is confusing. what do i do?
  • lancelance Member, Community Support Member

    If you aren't familiar with working with APIs in general, it can be a daunting task.

    Have you reviewed the sample PHP script that is available in the docs?

    Obviously this is very rough example, but it should help you see how to use curl in PHP to access the API. Essentially, you set all of your variables in an array. To call a particular METHOD, you set a key / value pair in the array, like this:
    $foxyData['api_action'] = 'action_method';
    where 'action_method' is the API method you want to use.

    After you have set the method, you assign additional key / value pairs with the KEY being the name of the field and the VALUE being the value you want to get or assign (depending on the method).

    So, for example, if we wanted to unset the is_fed status of transaction is 123456, we would do something like this:

    $foxyData = XXX; // your token
    $foxyData = 'transaction_modify';
    $foxyData = '123456';
    $foxyData = '0';

    Then you would pass the array to curl and read out the result.

    Does this help?

  • so what i got to do is say which actions that i would like to do within the api_action and then if it calls for required fields put them in the $foxData variables with the value after =.

    ok so lets say that i was going to make a subscription end right now then send the subscription through. would i do

    $foxyData["api_action"] = "subscription_datafeed";
    $foxyData["customer_email"] = "the_email";
    $foxyData["end_date"] = "2011-02-09";
    $foxyData["sub_token"] = "sub_token_url";
  • lancelance Member, Community Support Member
    Close, but not quite.

    If you pass the
    method that will cause the Subscription XML Datafeed to be sent immediately. You do not set any of the other options.

    If you want a subscription to end today, you would FIRST send an API call using the
    method and set the
    to today for the particular
    . After that, you would make a separate API call to the
    . This would cause the Subscription XML Datafeed to feed immediately, and you would be able to parse the expired subscription from the XML and process whatever logic you need in your system.

    Note that there is also a
    API method, but this sets the expiration for tomorrow, so it won't show up as an expired subscription until tomorrow's Subscription XML Datafeed.

    Does this make sense?

  • ok so i did it like this

    $foxyData["api_action"] = "subscription_modify";
    $foxyData["customer_email"] = "the_email";
    $foxyData["end_date"] = "2011-02-09";
    $foxyData["sub_token"] = "sub_token_url";
    rest of the code

    then i do

    $foxyData["api_action"] = "subscription_datafeed";
    rest of the code

    i get SUCCESS from both

    Then when i check my DB to see if there was any changes there was nothing. Also to make sure that the datafeed actually gets sent i put an echo 'worked'; to create an error and i dont even get any errors. Or the stats is not running. so i get the feeling that its not sending.
  • brettbrett FoxyCart Team
    Just a thought: What's your datafeed endpoint looking for in the POST value? This has actually bit me before, but for a normal datafeed the encrypted data will be in $_POST, but for the sub datafeed it'll be in $_POST. Is that the issue, perhaps?
  • lukeluke FoxyCart Team
    I think you have to set the "end date" to tomorrow as subscriptions are only cancelled once a day when the subscription processor runs. So when you use the api as described here the subscription template will be updated (that's the transaction that is repeated each time), but it won't actually modify the subscription itself until the processor runs and sees that the template has a subscription end date.

    If you want to cancel a subscription directly, you can use subscription_cancel or use subscription_modify and set is_active to 0. If you deactivate it directly using the is_active bit, it won't show up in the subscription datafeed since an end date wasn't set.

    Does that help?
  • so if it is already active 0 then if i set it to active 0 again and then force the datafeed will it go through properly. also luke can you see the whisper i sent to brett.

    and if i set end date for today and force the datafeed will it still send to the datafeed right?

    im just confused as why it doesnt send through. im going to try and set up send a thing to the db when the begining of the foxy subscription to collect and see if it actaully really is starting to run.
  • lukeluke FoxyCart Team
    Hey itisnot_me. Yes, all whispers can be seen by the forum admins.

    The data in the datafeed only shows up based on the criteria listed here:

    So in answer to your question, it will show up if the end_date is set to today, otherwise one of the other criteria would need to be true. Setting the is_active doesn't actually "cancel" it in that it won't be processed through the xml subscription datafeed. Only subscriptions set with an end_date get cancelled on the day of the end_date.

    Hopefully that helps. If not, please let us know how we can help you further.
  • ok so what you are saying that if i set a cancel date for right now, (its almost 12 so ill use the new date) 2011-02-16 and then force the data feed to be sent to the subscription post that it actually does not tell the post that it is actually a cancel until the subscription processor on your end makes it a cancel.

    cause if that is the case then it doesnt make much sense to use the api cancel a subscription cause we still have to wait for your system to do the work.

    On another note i have a little piece of script that runs at the start of the post subscription part and it doesnt run even when i force feed a datafeed.

    i am at a loss at what is or is not happening. is there a way you can check to see if i got sent a datafeed and if it was successful?
  • lukeluke FoxyCart Team
    It all depends on your requirements. If you want to manage things through the subscription processor then setting it to cancel will do that by setting the end date to tomorrow. That way when the processor runs, the subscription will be deactivated and the data will be included in your subscription datafeed. If you want to mange things yourself directly, you can use the api to just set the subscription to be inactive and do whatever else you need to do right then.

    The api shouldn't actually let you set the end date to today. If it does, we'll have to look into that since the actual processing happens the next day for a given transaction. They run around 4am which is when they get set to inactive as the other subscriptions are processing.

    If your script is not showing activity it would probably be a good idea to revisit the requirements for when a subscription data feed is sent to ensure you have data in there. If there's no data to send, it doesn't send anything, even if you force it to run.

    We really appreciate your input and feedback on this. It may not be ideal how it's currently setup but we haven't fully mapped out how to improve things in a way that works for everyone in various timezones. Any ides you have would be helpful.
  • when i set the cancel date for today it does take. but then the next transaction date it for the next day. im not sure if that is what is supposed to happen but thats what i see on the response.
        string(10) "2011-02-16"
        string(10) "2011-02-17"
        string(10) "2011-02-16"

    as per software integrations we would need something that runs the almost right away. So that way we could have there account canceled. It would be good if the cancel processor could actually run more than once a day. it would be real cool to have it hourly. If it was hourly then you could reduce the strain on the processor, instead of sending out all the data at once.

    Im at a loss at why my thing did not run even when i canceled it and it was supposed to cancel the first time
  • brettbrett FoxyCart Team
    I'll let Luke address the "why my thing did not run" issue, but I want to clarify something (if not for you @itisnot_me, maybe for somebody who stumbles on this thread and may still be confused):
    as per software integrations we would need something that runs the almost right away. So that way we could have there account canceled.
    It might not be clear (and we'd love feedback), but as Luke described there are two ways to use the API to cancel a sub.
      [li]Set the sub_enddate to a date in the future.[/li]
      [li]Set the is_active to 0.[/li]

    The important things are these:
    When you set the sub_enddate, the subscription processor still has to run in order to actually cancel it. The subscription processing currently happens between 4am-7am PST, depending on your store version. Doing it this way will include the cancelled subscription in the sub XML datafeed, and you can take action there (disable an account, send an email, etc.).

    The is_active method, however must be called explicitly by your own script, so that happens separately from the sub datafeed. The rationale is this: If your system is making an explicit request to disable a subscription, you shouldn't need that subscription sent through in the sub datafeed since you already know that it's cancelled, and you can take whatever action you need to take immediately, right then. I _think_ that addresses your "as per software integrations" comment above, yes?

    Sorry if we're talking around each other. Let me know if this is making sense or if I'm totally missing you.
  • well for the software integrations i was talking about "without" using the api. After they cancel within the hour or so (cancel would have a timestamp), the cancel subscription processor would run and send through the sub xml datafeed. so that way we could cancel the account.

    The way i have it set up now is they go through the cart to cancel there subscription. so i dont use the api at all. The reason i was starting to use the api is for testing purposes. Even if i did set up an cron job for the api to see who cancels today that would be a huge amount of request to the api and i would be concerned about it not canceling the subscription even if i cancel the account on my servers.

    now with that being said do you think that it would be the best practice for software integrations to use the api. that way we can cancel the account right then and there. After it gets sent to the api and comes back with a success. Now i do see a potential problem here in that i know you wont let a subscription cancel if they have a past due amount. And if we cancel the subscription through the api we wont be able to get that payment (im not sure how they would have a past due amount).
  • lukeluke FoxyCart Team
    What timezone are you in? Ideally the system should not let you set a cancel date unless that date is tomorrow or further in the future. When you add the sub_cancel=true, that's what it does. Setting a sub to cancel today should not work, but should throw an error... if it doesn't we need to fix that. I feel like we should back up a bit... what store is this for and what version is it?
  • lukeluke FoxyCart Team
    FYI, we rolled out a fix for this today while also fixing a bug in the admin that was letting you set the next transaction date to today. Now both the next transaction date and the end date for 070 and 071 must be at least one day in the future (i.e. tomorrow) to ensure they hit the correct processors for that day. As always, keep an eye on the changelog for the latest fixes and updates we're working on:
Sign In or Register to comment.