(4) After mailing is finished - Sparkpost transaction to retrieve the bounces


This is mockup of the (3)st #SparkPost transaction in Newsletter Mailing System


GET – 
https://api.sparkpost.com/api/v1/suppression-list?
to=2017-05-17T09:00:00%2B0000&
from=2017-05-15T09:00:00%2B0000&
types=non_transactional&
limit=10000

partial result …
{
  "results": [
    {
      "recipient": "water@infostations.com",
      "description": "550: 550 permanent failure for one or more recipients ...@... cuda_nsu No such user or recipient doesn’t want your spam)",
      "source": "Bounce Rule",
      "type": "non_transactional",
      "created": "2017-05-16T19:01:15+00:00",
      "updated": "2017-05-16T19:01:15+00:00",
      "non_transactional": true
    },
    {
      "recipient": "eric.l.musgrove@navy.mil",
      "description": "550: 550 [internal] [oob] The recipient is invalid.",
      "source": "Bounce Rule",
      "type": "non_transactional",
      "created": "2017-05-16T18:59:48+00:00",
      "updated": "2017-05-16T18:59:48+00:00",
      "non_transactional": true
    },

…..


the most practical thing for me to do with the complete result is to cause a download of a csv file.  this is because i am dealing with a legacy local program written in FoxPro which does not really have good access to the web. 

 
#SparkPost #bouces #newsletters

Comments


nathan, if you output a cvs file with a variable name, like sparkpost_acd0d3788da3e9b0b46a020f1394965ffa2872ee.csv,  it will just add an extra step when i input it into FoxPro newsletter.prg .   Could the name be fixed … maybe a name designated in the script like “supressions.csv”  ?

That was done the first day. The name is “bounces.csv”.
The one you saw was only the original proof of concept. (and I guess you haven’t tried it since)


true i have not … now i am programmikng it into newsletter.prg … it not on the list of buttons so not sure how i would get it again.

woopse … er, there it is on the list … i will click it again null

it worked null …. #kudos → nathan


the date range is critical as the bounces come in over a period of time after the mailing

← i should get about this many from the last live mailing.

omg i love data …

For some reason the google buckets put the bucket name on the front of the file with the / hex encoded as %2F. This is how the buckets seem to work and I can’t find a way around it.

So your going to have to use the full file name in your scripts I guess, which is sparkpost%2Fbounces.csv




null a mystery however is that i only got 497 records … expecting 2,889

maybe it’s this …

they probably don’t put those in the bounces.

Yep. Don’t know. The results is set to a limit of 10,000 … so the rest is sparkpost magic.


yeah i’m almost positive its the timeouts … no reason to take those out of our mailing list … still need to reasearch it a bit

limit should be more like 90,000 … these are only going to increase … and they are cumulative

hmmm … wait … these are thes just current bounces … or cumulative supressions ?








← close enough
for government work null

You can always change any of things things in the script later. This is not hard coded, just javascript.


which brings to mind the possibility of a totally generalized api button where

the following could be variables directly entered in the thought editing (not script editing)

endpoint
authorization key
parameters by name
option of get, put, post
json body

huh?

Well I already generalized the library to utilize one function.

But why have that utility in TD? Postman does all that just fine. Isn’t the point of the TD stuff so that you can imbed buttons in your procedures? Not just duplicate the lower level of Postman?


well yea and no.   the point is can just anyone who knows the data write the TD procedures.  i mean dev guys like you who can write java scripts are expensive. 

Yes. Nearly anyone can write the procedures. They are just simple and very basic javascript and jQuery. Almost anyone who has done any programming for the web can write jQuery. There is nothing special or difficult about these procedures in a TD. Just a few very simple things to know beyond basic jQuery. If anyone has written a jQuery handler for a button on a webpage before they will understand these.

omg that is not true at all.   one needs to learn how to write Javascripts and learn all the words and how they work.  your like saying, “everyone can speak Chinese” … well yeah, if they learn it … but they won’t becacuse they want to be focused elsewhere.

I noticed how the advent of a simpler tool causes more people to do things that they do not ordinarily do back when i used to run an IT department for DataPrint.  We introduced MS Access and hooked it up to the corporate data.  Suddenly several managers, who used to come to me for special reports, started generating them on their own.  The simpler you make the tool, the more people will use it.

Nope. You are mixing concepts. In the first case one can have a simple tool like Postman. Then all you have to learn is JSON. In the second case one can have buttons in pages and very simple jQuery handlers. Then all one has to know is a little TD reference to create the buttons and a little jQuery to handle the button clicks. Those two needs are not the same.

And now the jQuery is so ridiculously simple even a 4 year old could do it.
 
            spDoAction({
                method: ’POST’,
                url: ’/api/v1/transmissions?num_rcpt_errors=3’,
                JSONContent: JSON.stringify(sp.emailCampaignJSON)
            }, function (r) {
                sp.$out.html(’<h3>send campaign results</h3><pre>’ + JSON.stringify(r, null, 4) + ’</pre>’);
            });

As you can see I factored to just the same things you would be using in Postman. #NBD 

If you want the extra functionality of buttons … then you only have to learn a tiny bit of jQuery which is mostly just copy and paste from some other similar button and change the relevant parts anyway.

well at my level of knowledge here is what makes sense in that expression …

method: ’POST’,
url: ’/api/v1/transmissions?num_rcpt_errors=3’,

The rest of that is Chinese. 

And  i am already quite familure with these REST API’s … and with programming syntax in general.
Ask you gf if she can make any sense of it at all.

As I said, you would have to learn a little (← emphasize little) bit of jQuery … if and only if you want to create a new button that is not like one already made.

If you are just adding a new button for a different sparkpost procedure that is not already handled, but is like an existing one, then all you need to do is copy one that exists and change, yes you got it, just those things you recognize.

oh sure … i have all *i* need now to do the scripting i need to do for the mailing procedures.  I will make a different one with different configured buttons for mailing out speak.txt to just our blind customers.  And i will cherry the one for the newsletter in my own thought soon.  if that is what you are saying, then i totally agree. 
#thanks → nathan and #kudos null

#btw … how would one connect that “spDoAction” to a specific button?

Okay good … and you don’t quite have all needed. I am still finishing.

But I don’t think that is what I am saying. From your initiation of this thread (which perhaps you have forgotten because it was yesterday and you have said you reset your brain each day) it was about creating a Postman like generalized interface. My point all along is that there are two kinds of interfaces, the Postman like one, and a button like one that can be imbedded in procedural text. The button like one would be nicer, but necessarily requires more knowledge of scripting buttons (since we are no where near having a point and click interface for scripting buttons at this time).

For the record, the Postman like interface would be trivial at this point, all it’s parts exist already, but why? You got postman for that already and it is well tested and easy to use.

Also for the record, I have been designing the [ref ] additions for buttons and form elements such that they someday could be point-and-click scripted … that was one of the requirements in the syntax design for them. But for now, they are still easily human readable and easy to use in your pages.

Also for the record, I don’t see a way around “new API interface routines” having to be written by someone with some jQuery knowledge no matter how easy I make it. There is no way point and click could ever fully interface with a random API design without translation and specific procedural control structures. Maybe on some ideal semantic web, but if that ever even happens, it is years and years away … the industry is simply not interested in a semantic web.


#sethhmmm re the relationsip between the re [ref] language for buttons and the simple Json data that API calls need.  How does the former refer to the latter?

Huh? There is no direct relationship between [ref ] and JSON.

The JSON we are using is in the top of the script on the page and is only related to the sparkpost API.

The [ref ]’s in pages just create buttons, form input, and areas for output.

The scripts reference the created buttons and elements by html ID’s.

And p.s. … a [ref ] for JSON is not possible because the [ and ] are used in JSON itself. I wish it were otherwise many times, but it is not. Not to mention the unicode character hell created by nbsp; spaces and fancy quotes and → etc. etc. This is why we have the “script” editor for thoughts.

none the less, a button language could be designed such that there was a direct mapping between a simple Json description of the data for an API call, and the button itself.

Well, in a way, it is. The [ref ] language is super flexible and maps named values separated by “and” or “&&” as you prefer. (I prefer && because it shows up and reads better).

So in theory one could specify anything at all in the button reference (as long as it is not nested JSON) … but then, someone would still have to write the backup scripts for all that potential variability, both in the sending, and in what you get back from an API … which is just not always the same for most API’s. It is no more work to just include that variability in the script instead of the button.

its looking like the button reference language not being able to have embedded json is quite a limitation.  but one could refer to the json by a named jason string in another reference in the same thought.

and yes i get that threading output to do something is difficult as it is hard to anticipate all the things that will need to be done … and is simpler to just write a script.

i’m going out shortly to a bbq party so will be out most of the day.

Yes I agree. JSON in thoughts would be really nice. But it is just not practical given all the other things the rich text editor does that interfere.

The best that could be done is a [ref ] that is clickable to pop up a JSON editor that edits JSON objects stored elsewhere, such as in the quad table.


#btw … my needing to reconnect all the connections in the new context of each fresh day … is very similar, imho, to your #multivers jumping.  i come to situations from entirely different aspects and points of view whithout the assumed upon connections of the way they were.   i’m thinking it is the same thingey … just described differently.   then too my mind is quite different than yours (especially as to memory), so that has to be factored into the differences.

Conversation forked to thought 24050


The file does end up being named “fastblogit_files_sparkpost_bounces.csv” and not just “bounces.csv” ...
which is just fine null
just saying … i can program this file just as well as the other one.

Yea, like I said, that is happening inside google buckets. I can’t find any doc that gives me control over that. It’s just how they generate the internal file name passed to the browser when you hit that url.