OroPocket
Get set up

Choose what your API keys can do

Capabilities are the allow-list on your keys. If an endpoint returns 403 API_NOT_ALLOWED, this is the page that fixes it — and the page to visit first if you would rather your keys could not do things you never use.

4 min read · 3 screenshots

Open Capabilities in the Account section of the sidebar. The page does two things: it asks what you are building, and it lets you tune the individual permissions underneath that answer.

The Capabilities page of the OroPocket developer dashboard, showing four selectable use-case cards for Hosted integration, Raw API, Gifting and sending, and Whitelabel, each listing the capability chips it grants.
Four paths. Selecting one enables exactly the APIs it needs and disables the rest.

  1. Pick the paths you are building

    Each card lists the capabilities it grants. You can select more than one — a partner running a hosted checkout and a server-to-server integration ticks both, and gets the union.

    A close-up of the Hosted integration use-case card on the Capabilities page, showing its description and the mono capability chips it grants.
    Selecting Whitelabel here is what makes the Whitelabel page appear in the sidebar.

  2. Adjust individual capabilities if you need to

    Below the cards, Individual capabilities lets you toggle anything directly. Items already granted by a selected path are greyed out — untick the path to release them. Two capabilities are marked sensitive because of what they move: withdraw takes money out to a bank account, and delivery ships physical metal.

    The Individual capabilities section of the OroPocket Capabilities page, showing a grid of capability chips with some greyed out because a selected use case already grants them.
    Greyed chips are implied by a path you have selected.

  3. Read the footer before you save

    A bar pins itself to the bottom of the page showing exactly what your keys will allow after saving, and — in red — anything you are about to turn off. Removing a capability takes effect immediately, so anything live that depends on it starts returning 403 as soon as you confirm.

What each path grants

Every path includes pricing, transactions and balance. On top of that:

PathAdds
Hosted integrationembed, users — enough to issue a user code and hand the session to our hosted checkout.
Raw APIusers, buy, sell, kyc, bank, withdraw — you build the interface, so you need the whole lifecycle.
Gifting & sendingusers, buy, send, receiver, gift.
WhitelabelEverything in Raw API plus send, receiver and gift. Notably not embed — a white-label site is not an embed, it is our app on your domain.
Fixing a 403. The error message names the capability it wanted: “Your partner profile is not allowed to call the ‘sell’ API.” Tick that capability here, save, and retry — there is nothing to redeploy and no new key to issue. Existing keys pick the change up on their next request.

Test and Live are not the same list

Changes here apply to your sandbox keys freely. On the live side an administrator can impose a narrower list, and when they have, your live keys get the intersection of the two. That can only ever narrow what a live key does — so a capability you enable here may still be refused in Live. If that happens and you need it, get in touch.

Next, depending on what you picked: test a hosted embed or make your first API call.
← Generate an API keyTest a hosted embed →