"On-behalf-of"

Users with Enterprise Access to the Platform API can read or make changes to data on behalf of other users or teams through the Platform API. To use the "on-behalf-of" functionality:

1. Navigate to the endpoint that you wish to trigger on behalf of a user or team.

2. Insert an "on-hehalf-of" header with value "userId" or "teamId" (depending on the endpoint).

For example, if you want to make edits to a certain team, you would want to send a request on behalf of a team.

	--url https://rapidapi26.p.rapidapi.com/v1/users/%7BuserId%7D \
	--header 'accept: application/json' \
	--header 'content-type: application/json' \
	--header 'x-rapidapi-host: rapidapi26.p.rapidapi.com' \
	--header 'on-behalf-of: 123456' \
	--data '{  "email": "",  "name": "",  "username": "",  "password": ""}

For more example of the use of "on-behalf-of", see Example Using the REST Platform API: Listing all APIs.

📘

Important notes on using on-behalf-of

You must have Enterprise Access to the Platform API to use the "on-behalf-of" functionality.

If you are calling an endpoint, such as Get All Teams, on-behalf-of of an org admin, that org admin must have their Personal Context enabled. See Roles and Permissions.

📘

ownerId vs. on-behalf-of

Some REST Platform API endpoints have an ownerId header, which is somewhat similar in functionality to on-behalf-of. For example, when creating an API using an OpenAPI document , you can specify the user or team that will own the API. The API will then be shown in that user or team's context, as if they created the API. This is especially useful for calls to the REST Platform API from continuous delivery pipelines.

"On-behalf-of" supported endpoints

📘

In some cases, the "on-behalf-of" header can be specified in your code even though the header is not shown in the API playground.