HTTP response code from connector

Is there any way to get the HTTP response code (e.g. 200, 403, etc.) from a connector call?

Hey @wz2b -

Unless the error is passed in the response body, I don’t know if a way to access this status in a connector.

I will write a feature request for this, because it feels like a gap right now and see what I can do to get it prioritized, because I can’t think of a scalable workaround.


Yeah. I support the idea of adding this because error handling is one of my concerns with connectors. Generally speaking, if a connector fails you get a pop-up at the bottom of the screen that tells you that it failed. It is transient (you get about 3 seconds to notice it, or it’s gone). And of course the request doesn’t get queued in any way.

What I envision (from the perspective of a software developer) is that if I knew I got a non-2XX response back I might take this request and stash it in a table - a “dead letter queue” of sorts - to deal with it later. I haven’t totally worked out how I want to do this yet. But, without a status, what I’m doing temporarily is resetting the output variable before the request, make the request, and if the output variable is still empty then I know the request for some reason didn’t work.

So in terms of priority, I agree with you this seems important … but I do have a work-around for now, I just don’t particularly love it.

Totally makes sense. In my opinion just throwing an error message is inadequate when it comes to error catching in a process critical application.

There has been some discussion in the past to enable on-error triggers that run if a specific trigger fails. We have avoided going down that road, and have instead focused on the changes to make it easier to see if something will fail, why, and how to resolve those potential failure modes (development mode was the first stab at this).

Keep the great ideas coming. Impressed almost daily with the different blindspots you point out.


A trigger on failure is something I hadn’t thought about. That trigger would be on the Step, or the App, or the Connector? I think it would have to be a trigger specifically associated with that specific invocation.

I’m having trouble visualizing how that would work. Without knowing exactly how connectors are called (under the hood, the fetch() is probably asynchronous) I guess a trigger makes more logical sense, but I think it’s a little trickier to deal with. I’m thinking maybe it makes more sense to use a variable. Connectors already let you have outputs based on

  • Response Body
  • Response Header
  • Cookie

so I think my inclination here is forget triggers and just add a 4th and 5th one for

  • HTTP Response Code (definitely need this)
  • HTTP Response Status Text (maybe need this)

That last part isn’t well thought-out but what I’m getting at is it’s perfectly normal in REST land to return application/json on 200 or 201 but return text/plain with a text message on some of the other response codes … the HTTP spec actually says which response codes are allowed to return content and which aren’t.

I don’t know. Let’s keep noodling this.

I would like to talk about the end game, though. I’m working with customers who want external systems to be their system of record, so they’re using connectors to store pretty much everything. I generally advise against this - my preference is to have everything recorded to a tulip table, then synchronize it offboard. In most cases I sync on a timer (polling) but use connectors to signal “There’s something new, sync now.”

The structure of the outputs is also different depending on the response code. Different outputs structure by response code will be helpful

I just looped in our product manager for connectivity @Sagar. This is incredibly useful feedback for the work his team is doing around connectors.

Keep this amazing feedback coming!

I don’t want to beat this to death but I looked to see if there’s some standard way of dealing with this in the HTTP spec:

and it is described in section “6.1.1 Status Code and Reason Phrase”. So thinking through that, where you can now select if you want to extract data from a header, a body, or cookies, I think the thing to do here is to add a fourth choice that gives you the status code and maybe a separate way to get the ‘reason’ which is usually more human-readable. For me the numeric code is really what’s important.

There is one other thing though and it’s the main reason I’m commenting further: keep in mind that an “OK” status can be anything from 200 to 299 … so a “good” response might be a 200, might be a 201, might be anything else in that 200-299 range (in theory at least). So it MIGHT not be a bad idea for you to also return a ‘bool’ indicating success i.e. the response code is between 200 and 299 inclusive. That would make it so you don’t have to do a numeric range comparison in tulip.