Proofpoint API suddenly failing 404

Suddenly an API call to proofpoint essentials API is failing with a 404 not found, it has been working fine for months. This only started after I updated my n8n docker. Support is telling me the API is fine, which I believe as others I’ve asked that use it are not having an issue. So I have to believe it’s something with n8n possibly?

404 - "{\"errors\":[{\"status\":404,\"error_message\":\"Not Found\"}]}"

Share the output returned by the last node

Information on your n8n setup

n8n 1.38.1
defalt db

Docker
Ubuntu 22.04 lts

It looks like your topic is missing some important information. Could you provide the following if applicable.

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:

This is DEFINITELY an issue with n8n.

I can use curl from my workstation and it works just fine.

My docker setup is using caddy for reverse proxy, which was also updated a while ago. My n8n says there is an update but running a pull command for docker doesn’t update it to 1.38.2? says it’s up to date?

I included most of this??? what’s missing that helps answer the question?

Ubuntu 22.04 lts, caddy is running for reverse proxy and n8n is in docker with default DB (sqlite)…

Suddenly gettinga 404 not found using an api through n8n but if i use curl from laptop it works just fine. So the issue is n8n? and it started after running updates.

When you run your workflow, does $json.emailDomain in the URL expression contain the right value?

https://us1.proofpointessentials.com/api/v1/orgs/{{ $json.emailDomain }}/products

Try first to call URL without $json.emailDomain and test it.

When i hover over the expression, the preview shows correctly. I can copy this to a curl statement on my laptop and it works just fine.

Is there a way to enable more verbose logging about what is actually being sent to the API?

just took a closer look at the error.

This is what n8n is trying to send… the email domain is missing?

"https://us1.proofpointessentials.com/api/v1/reporting//daily"

But it shows correctly and i can see the domain in the results from the previous node?

Can you take 1 step back and try hardcoding the email domain in the URL to confirm that that works?

After that, can you double-check to make sure the {{ $json.emailDomain }} does not contain any special characters, additional spaces etc that might invalidate the URL?

changed to fixed and typed in the email domain, it works. For whatever reason the email domain when coming from json isn’t actually being inserted into the url for the api. It’s essentially blank. It is returning and hovering over the expression shows the correct api url end point… so i’m not sure what happened or why this suddenly started.

1 Like

I changed it to fixed and typed in the email domain, it works when i do that. I’m checking the email domain for special characters but this did work fine. That field in the database isn’t updated by anything, so i doubt there are special hidden characters in it.

Are you processing multiple items by any chance? If so, did you verify the emailDomain for all of them?

The current result set from mysql just has 1 result.
here’s what happens when I hover over the expression, it shows the correct url:
image

Here’s what the error is showing (notice that the email domain is just missing?)…

{ "headers": { "x-user": "user@email", "x-password": "xxxxxxxxxxxxx", "accept": "application/json,text/html,application/xhtml+xml,application/xml,text/*;q=0.9, image/*;q=0.8, */*;q=0.7" }, "method": "GET", "uri": "https://us1.proofpointessentials.com/api/v1/reporting//daily", "gzip": true, "rejectUnauthorized": true, "followRedirect": true, "resolveWithFullResponse": true, "followAllRedirects": true, "timeout": 300000, "encoding": null, "json": false, "useStream": true }

So somewhere between what is showing in the parameters and what is actually sent to the api, the domain isn’t being sent? If i hard code the email domain as a fixed, it works just fine?

Did something change with http requests?

Is this part of the problem, the node version? It’s in the error details “Other Info”
Node type

n8n-nodes-base.httpRequest

Node version

4.1 (Latest version: 4.2)

n8n version

1.38.2 (Self Hosted)

Time

4/30/2024, 10:31:59 AM

Stack trace

NodeApiError: The resource you are requesting could not be found
    at Object.execute (/usr/local/lib/node_modules/n8n/node_modules/n8n-nodes-base/dist/nodes/HttpRequest/V3/HttpRequestV3.node.js:1571:35)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at Workflow.runNode (/usr/local/lib/node_modules/n8n/node_modules/n8n-workflow/dist/Workflow.js:728:19)
    at /usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/WorkflowExecute.js:660:53
    at /usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/WorkflowExecute.js:1062:20

This is fixed… the issue was another developer had copied code to create new records, but didn’t realize an id was hard coded causing the mysql dataset to pull erroneous records where there would be no email domain in the result set. Odd though in the interface it looked like it was failing on the only record it should have pulled. it was in fact not. … :rage: :rage: :rage: :rage:

2 Likes

Ah, great! And yes, that’s what I meant - if you process > 1 item, the node dialog will only show information for one at a time. The error might occur on another record. I agree that this is not always obvious and I’ll pass along your feedback!

Hi @tkintenn
thanks for reporting the problem!

I have a question to understand how to improve your experience in a situation like this.
Did you check the “item index” value in “Other info”?
Do you remember what that value was?

I’d like to understand if that information was shown properly and if it could have helped here.

Thanks in advance for yr feedback

I don’t remember what this part said.

Ok thanks @tkintenn
we should bring that information up and make it more visible in this case (that would have probably helped)

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.