Skip to main content
Solved

Unexpected 404 when using Create or Update Profiles endpoint


Forum|alt.badge.img

When using the “Create or Update Profiles” endpoint (/api/profile-import/) , I found a certain scenario that produces an expected result. 

Consider this payload:

{
  "data":{
    "type":"profile",
    "id":"[redacted]",
    "attributes":{"email":"[redacted]"}
  }
}

When a profile already exists for that id, and the email differs, it updates the profile with the new email as I would hope. 

However, if another profile exists with this new email address, I expected it to return a 409 with the id of the duplicate profile as described in this question , but it actually returns a 404:

{
  "errors":[
    {
      "id":"6e03e204-aa9d-48f8-b516-ab52ecf03958",
      "status":404,
      "code":"not_found",
      "title":"Not found.",
      "detail":"A profile with id {redacted} does not exist.",
      "source":{"pointer":"/data/"}
    }
  ]
}

But if I do a `GET /api/profiles/{redacted}` with that same id which “does not exist”, I get a successful response. (And can view the profile via klaviyo’s site.)

Is this a bug? Or is there something I can do differently when using this endpoint to be able to distinguish between “Not found” and “Conflict”?  I know that email is considered to be unique identifier, but in the first scenario I mentioned, this endpoint doesn’t say “profile not found” because the email differs -- it seems to be unique to the case where another profile has that email. 

Thanks!

Best answer by eezydev

Thanks for asking, @Brian Turcotte -- I tried again today and I correctly get the expected 409 in the above scenario instead of 404. Maybe I was doing something wrong, but it seems to be working correctly. 

View original
Did this topic or the replies in the thread help you find an answer to your question?

2 replies

Brian Turcotte
Forum|alt.badge.img+37

Hi @eezydev!

My apologies for the delay here - is this issue still occurring for you?

- Brian


Forum|alt.badge.img
  • Author
  • Contributor I
  • 1 reply
  • Answer
  • June 6, 2024

Thanks for asking, @Brian Turcotte -- I tried again today and I correctly get the expected 409 in the above scenario instead of 404. Maybe I was doing something wrong, but it seems to be working correctly.