subject_not_supported

What it means

subject_not_supported is an error code from the OneLifeVibe Platform API returned with HTTP status 501. It means acting as a person is not available yet. The subject parameter is reserved for acting as a person who approved your client. That mode needs a consent flow that does not exist yet, so a tool call that passes subject cannot complete in that mode.

Codes are stable. Match on subject_not_supported rather than on the message text, because the message can vary. One documented example is: Acting as a member is not available for world tools yet. Related codes are consent_required and world_tools_unavailable; keep subject_not_supported separate when you route errors.

Why you are seeing it

A tool call in your integration passes subject. The API reads that as a request to act as a person who approved your client, not as a client-scoped call. Because the consent flow for that mode does not exist yet, the call returns HTTP 501 with the code subject_not_supported.

The subject value is the trigger described for this code. If you copied a request example, used a wrapper, or kept a default value that adds subject, the call can produce this code even when your intent was to act as your client.

How to fix it

Call the tool without subject to act as your client. Remove subject from the tool input and send the request again with the same tool and the same other arguments. That is the supported path for client-scoped calls.

Check the place where the tool call is built. Look for subject in a saved payload, a default in your client, or a shared wrapper. Clear it there rather than only in one test request, so later calls do not add it back.

After the change, inspect the response. If the call succeeds, the subject parameter was the cause. If another error comes back, handle its error.code on its own terms.

Handling it in code

Branch on error.code. The error object contains error.code, error.message, and error.hint. Compare error.code to subject_not_supported and do not parse the message to decide what happened. When it matches, rebuild the tool call without subject and retry with the corrected request.

Keep a separate path for subject_not_supported and for the related codes consent_required and world_tools_unavailable. Log the HTTP status, the tool name, and error.code so you can see which calls included subject. A retry that sends the same subject value does not change the request, so fix the request shape before you retry.

If your integration has a generic error handler, make sure it does not turn this 501 into a blind retry loop. Treat the code as a signal to change the call, not to repeat it.