onelifevibe

Platform API error

consent_required

consent_required is a 403 returned when a tool call passes subject for a person who never approved your client. Omit subject to act as your client.

Updated November 6, 2026

HTTP status
403
Code
consent_required
API
Platform API v1

Returned when

What to do

Example answer

HTTP/1.1 403
content-type: application/json

{
  "error": {
    "code": "consent_required",
    "message": "This client has no permission to act as that person."
  }
}

Related errors

What it means

consent_required is the error code the OneLifeVibe Platform API returns with HTTP status 403 when your client asks to act as a person it has no permission to act as. The request was understood and refused; it was not malformed. The body follows the standard error shape: an error object with code, message and hint.

The code value is consent_required and it is stable. Branch on error.code. The message text can change, so a string comparison against it will break.

Why you are seeing it

You get this code when a tool call passes subject for a person who never approved your client. The subject names the person the call would act as, and without that person's approval the client has no permission to act as them.

The message usually reads: This client has no permission to act as that person. The hint field may add context, but the code is the reliable signal.

Two related codes sit alongside this one: consent_scope and subject_not_supported. Read error.code before you decide what to change.

How to fix it

Omit subject. Without it, the call acts as your client, which is the supported way to call the API. That is the whole fix for this error.

Acting as a person is reserved and not available yet, so removing subject is the fix rather than asking for more access. If your integration builds subject from a user record, a job payload or a stored configuration value, remove it there rather than patching individual requests. Leaving it in place means every call that touches it returns 403 again.

If you were relying on subject to scope a call to a person, read up on the related codes before you restructure the integration. Do not build a retry loop around this response.

Handling it in code

Check error.code in your response handler. When it equals consent_required, stop and fix the request instead of retrying. The same subject produces the same 403.

Because this is a 403 and not a transient failure, keep it out of your backoff logic. Log the code, the message and the hint, drop subject, and send the call again as your client. Then check that the value is gone from whatever builds your request bodies.

A small switch on error.code that handles consent_required, consent_scope and subject_not_supported separately is easier to maintain than one catch-all branch for 403. Each code points at a different change.

Questions

What does HTTP 403 with consent_required mean?

The client has no permission to act as the person named in subject. Acting as a person is reserved and not available yet, so the call is refused rather than queued or partially applied.

How do I fix consent_required?

Omit subject from the tool call so it acts as your client. If subject is generated somewhere in your code, remove it at the source so later calls do not reintroduce it.

Should I retry a call that returns consent_required?

No. Retrying with the same subject returns 403 again, because the client still has no permission to act as that person. Change the request first, then send it once.

Keys, plans and usage live in the console: rotate keys, add webhook endpoints, see the last 30 days.

Open the console Plans

Written from the OneLifeVibe tool registry and platform configuration, and checked automatically before publishing. Something wrong? Tell us.