Make a Celigo lookup step NOT follow a 3xx redirect

Integrator.io
, ,
1

When I visit this Jira endpoint:

/rest/api/3/attachment/content/{ATTACHMENT_FILE_ID}

it issues a 3xx redirect to the actual file, which is then downloaded. However, what I need is to not follow the redirect but instead read the Location header from the pre-redirect response (in short, because this is the only way to map a Jira comment's inline media file UUID to a "real" Jira file attachment ID).

Is there any way to make a lookup NOT follow a 3xx?

Thanks.

2

Hi Christopher,

Jira Cloud's inline media files use unique UUIDs that can only be mapped to a "real" Jira Attachment ID by catching the initial 302 Found response and extracting its Location header. Because Celigo automatically chases redirects by default, it downloads the file instead of allowing you to read this header. To have a better understanding of your concern, we'd like to confirm a few details from you:

Are you using the prebuilt Jira Cloud connector or a generic HTTP / REST API connector? (Generic HTTP connectors offer far more structural flexibility).

Is this step a standalone Lookup inside the flow, or an Export acting as the data source?

Where are you mapping the extracted ID once you successfully capture it?

Instead of using a GET request, change the HTTP Request Method dropdown in your generic HTTP step to HEAD. This forces Jira to send only the metadata headers without sending the actual file attachment body. Because there is no file body stream to process, Jira returns the 302 metadata directly into the Celigo response pipeline, exposing the Location header.

Route the lookup through a lightweight serverless cloud function. The function calls Jira with redirect chasing strictly turned off (redirect: 'manual'), extracts the clean Location string containing the attachment ID, and hands Celigo a clean, flat JSON object:

{ "originalAttachmentId": "12345", "resolvedLocationHeader": "https://...", "extractedUuid": "abc-123-xyz" }

We hope these methods provide a clear path forward for capturing that Location header.

3

Hi Jan,

Thank you for your thorough response.

Do I understand you correctly that your suggestions is either/or? So, either use a HTTP connector with the HEAD http method to expose the Location header directly inside Celigo, or build a tiny serverless function somewhere (i.e. AWS or CF) which returns the value of the Location header to Celigo?

Because unfortunately it is a no-go in this particular flow to introduce a serverless function outside of Celigo. The HEAD method however could work.

What I did as a workaround for now is looking at the timestamp for the comments + the attachments on the issue, and then pairing them from this. And then handling the edge case where the comment attachment is already an issue attachment from previously - in this case, the issue attachment timestamp does not change, but instead the media UUID of the file is included in both the raw ADF text of the comment and in the attachment filename.

Best,
Christoffer

4

So if this is the location

https://api.media.atlassian.com/file/81748cdb-0790-4912-8c40-45a82ede88dd/binary?token=ABC&client=XYZ&dl=true&name=image-20260302-160721.png

then you need 81748cdb-0790-4912-8c40-45a82ede88dd from it?

5

I wasn't able to figure anything out here and HEAD is not a supported method for any of our exports or imports so I struck out the above text. We'd need an enhancement to give a setting like Postman to not follow redirects.

6

Hi @tylerlamparter Appreciate you checking in on this,

Hi Chris @CJS78

Thanks for explaining your workaround. Pairing timestamps between comments and attachments is a practical approach.

As Tyler noted, we may need an enhancement to provide a setting similar to Postman that prevents following redirects.