Skip to main content
Question

Error 500 for api/accounts

  • March 4, 2026
  • 1 reply
  • 6 views

Forum|alt.badge.img

 


  We're building an integration using the Klaviyo API (revision 2024-10-15) and discovered that the GET /api/accounts/ endpoint returns an HTTP
   500 Internal Server Error when the account's contact information does not have a country set.

  Steps to reproduce:
  1. Get an acount with the Country field empty
  2. Call GET https://a.]klaviyo.com/api/accounts/ with a valid private API key and revision: 2024-10-15 header
  3. Response: 500 Internal Server Error

  Expected behavior:

  The endpoint should return 200 with the account data, either with the country field empty/null or with a validation error (4xx) indicating
  the missing field.

  Actual behavior:

  The endpoint returns a 500 server error with no meaningful error message. This is a server-side crash, not a client error.

  Additional observations:

  - This is not transient — the 500 persists on every request until the country is set
  - Affects both OAuth bearer tokens and private API key authentication
  - All other endpoints (/api/lists/, /api/flows/, /api/metrics/, /api/profiles/) work fine on the same account
  - Setting a country in Contact Information immediately fixes the issue
  - We've confirmed this across multiple affected accounts
  - PATCH /api/accounts/ returns 405 Method Not Allowed, so there is no way to fix this programmatically on behalf of the user

  Impact:

  Any integration that calls /api/accounts/ during onboarding (to retrieve account ID, timezone, currency, etc.) will fail silently for users
  who haven't filled in their country. Since the error is a 500 with no descriptive message, it's very difficult to diagnose without knowing
  the root cause. There is no alternative endpoint that provides this account-level metadata.

1 reply

Byrne C
Community Manager
Forum|alt.badge.img+28
  • Community Manager
  • March 5, 2026

Hi ​@ecomflows,

Thanks for finding this and bringing this up. Have you tried calling this with the 2026-01-15 revision? While the 2024-10-15 isn’t deprecated yet, it’ll be considered deprecated in a little over a month, so it might make the most sense moving forward to use our most up-to-date revision. If this isn’t an option, or if this error happens with the newest revision as well, I’m happy to bring this up with the team, so we can determine why this is occurring. Let me know!