Skip to main content
Every project has an enabled-yields list. A yield only shows up in the Yield API’s discovery and action endpoints for that project’s API keys once it is on that list; everything else is filtered out before the response is built. “Yield blocking” therefore means choosing the set of yields your keys can serve.

​
What’s on the list

The enabled-yields table on a project page shows every yield currently enabled for it, alongside the full catalog you can add from. When OAVs are enabled for the team, the project’s OAVs appear in the same list: an OAV counts as an enabled yield the same way a standard integration does, and both are filtered together.

​
Effect on the API

Enabling or disabling a yield changes what the project’s API keys can see and act on:
  • Discovery endpoints (for example GET /v1/yields) only return enabled yields for the calling key.
  • Action endpoints reject a request for a yield that isn’t enabled on the project, with a bad-request error naming the yield.
Nothing about the yield itself changes: it is available to every other project that has it enabled. Enabling or disabling only changes what one project’s keys can reach.

​
Who can manage it

Enabling and disabling yields (and OAVs, where available) requires the manage enabled yields permission, held by the owner, admin, and operator roles; members can view the list but not change it. See Roles & permissions. You can also manage the enabled-yields list programmatically, which is the practical way to apply the same bundle across many projects. See Programmatic access.

​
Next steps

Discretionary fees

Add fees to the yields you’ve enabled.

Geo-blocking

Restrict where enabled yields can be used.