Skip to main content
Solved

Unexpected 404 when using Create or Update Profiles endpoint

  • May 23, 2024
  • 2 replies
  • 197 views

Forum|alt.badge.img+1

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. 

2 replies

Brian Turcotte
Forum|alt.badge.img+37
  • Klaviyo Alum
  • 1393 replies
  • May 30, 2024

Hi @eezydev!

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

- Brian


Forum|alt.badge.img+1
  • 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.