internal_error

What it means

internal_error is the code the OneLifeVibe Platform API returns with HTTP status 500 when something failed on the platform side. Your request reached the API and was routed; the failure happened after that, inside the platform. It is not a verdict on your credentials, your payload or your path.

Treat the call as unresolved rather than rejected. The platform did not complete the work, and the 500 tells you nothing about how far it got.

Every error response uses one shape: an error object with code, message and hint fields. Here code is internal_error and message is a short line such as "Something went wrong on our side." The hint field may carry extra context. Codes are stable and messages are not, so match on the code and keep the message for your logs.

Why you are seeing it

The documented trigger is an unexpected error inside the platform. That is deliberately broad: by definition, nothing in your request identifies which internal step failed, and the message will not name it either.

You might see it once on a single call and get a normal response from an identical retry. You might also see it on every attempt against the same endpoint with the same kind of payload. The second pattern is the one worth reporting, because a repeatable failure is easier to trace than a transient one.

Do not confuse it with the related code unavailable. If the code in the response is internal_error, the platform reported its own failure, and rewriting your request is not the first thing to try.

How to fix it

Retry with backoff. Send the same request again after a delay, and increase the delay between attempts instead of retrying in a tight loop. That handles the transient case without adding load while the platform is already failing.

If it repeats, write to support@onelifevibe.com with the time and endpoint. Include the time of the failures with the time zone, the endpoint you called, and the code you received. Copy the message and hint from a failing response as well; they give support something concrete to search for.

Handling it in code

Read the error object, compare code to internal_error exactly, and branch on that comparison. Do not test the message text, and do not parse it to decide whether to retry, since messages are not stable.

Wrap calls in a retry with backoff: a bounded number of attempts, a growing delay, and a clear failure once the attempts run out. Log the code, the endpoint, the timestamp and the hint if one is present. If the call creates or changes something, check the current state before you repeat it, because a 500 does not tell you whether the platform applied part of the work.

Because this is a 500, watch the rate across requests rather than alerting on each one. A steady trickle and a sudden burst call for different responses from your team.