Apiable

Access control

Scope grants

How API consumers request Optional and Restricted scopes from the API Portal, and how admins approve or decline them from Consumers, Requests.

Consumers request Optional and Restricted scopes from the portal's Your Access view. You approve or decline those requests from the dashboard under Consumers, Requests. An approved scope is added to the consumer's existing OAuth2 client, so no new credentials are issued.

How does a consumer request an Optional scope?

In the portal's Your Access view, the consumer opens the Available — Request Access section, finds the scope, and clicks Request Access. No justification is required. The request lands in your admin queue with a PENDING status.

  1. The consumer opens the subscription in the API Portal and finds the Your Access view.
  2. Under Available — Request Access, they locate the scope they want.
  3. They click Request Access. While the request is in flight the button reads Requesting….
  4. A confirmation appears: "Request submitted for {scope}".
  5. The scope moves to the Pending Requests section with a PENDING badge and the note "Awaiting approval".

How does a consumer request a Restricted scope?

Restricted scopes sit under Requires Approval and need a written reason. The consumer clicks Request with Reason, answers Why do you need this access?, and clicks Submit. The justification travels with the request to the admin.

  1. In Your Access, the consumer opens the Requires Approval section. Each scope there is marked "Requires business justification".
  2. They click Request with Reason next to the scope.
  3. A form opens with the prompt Why do you need this access? and the placeholder "Briefly describe your use case and any risk mitigations…".
  4. They type a justification. The form recommends a minimum of 20 characters; Submit stays disabled until the field has text.
  5. They click Submit. While saving, the button reads Submitting….
  6. The scope moves to Pending Requests with a PENDING badge, and the consumer's own justification is shown back to them.

Where do admins approve or decline scope requests?

In the dashboard, open Consumers, Requests and select the Access tab. Each row shows the requester, the subscription, the requested scope, the plan, and any justification. Use Approve or Decline on the row.

  1. Go to Consumers, Requests in the dashboard sidebar.
  2. The tabs read All, Registration, Subscription, Access. Open Access to see only scope requests, or use All to see every pending request together.
  3. Each row shows the requester's name, the subscription and email, the action line "Requests {scope} on {plan}", and, for Restricted scopes, the consumer's justification in quotes.
  4. To grant the request, click Approve. The row confirms with Approved.
  5. To turn it down, click Decline, optionally add a reason in Reason (optional), then click Confirm Decline. The row confirms with Declined.

Can admins act on several requests at once?

Yes. Select the request rows and the action bar appears at the top. Click Approve Selected to grant them all, or Decline Selected to add one shared reason and Confirm Decline. Each request is processed on its own and shows its own result.

The action bar reports "{count} selected". During a batch each row moves through Queued, then Approving… or Declining…, then Approved or Declined. If a row fails, it stays selected as Failed with the error, so you can retry it without reselecting the rest.

What happens to a consumer's credentials when you approve a scope?

Nothing changes about their credentials. On approval, Apiable binds the new scope to the subscription's existing OAuth2 client at your authorization server. The consumer keeps the same client ID and secret and receives the scope on their next token.

The decision is written first, then synced to the provider. If the provider call does not complete, the grant is marked APPROVED_PENDING_SYNC: the approval still stands, and Apiable re-attempts the bind. The consumer sees a GRANTED badge with a "Syncing…" note until the bind lands.

POST /api/int/subscriptions/{id}/scopegrants
PATCH /api/int/subscriptions/{id}/scopegrants/{grantId}

What does a consumer see after a decision?

The consumer's Your Access view updates to reflect the outcome, and a notice tells them what happened.

DecisionWhat the consumer sees
ApprovedThe scope moves to Your Access with a GRANTED badge. A notice reads "Your request for {scope} was approved".
Approved, sync in progressA GRANTED badge with a "Syncing…" note until the provider bind completes.
Declined, no reasonA notice reads "Your request for {scope} was declined." The scope returns to the request list, marked "previously declined".
Declined, with reasonA notice reads "Your request for {scope} was declined. Reason: {reason}".
Granted with the planScopes set to Active show an AUTO badge and "Included with your plan". These are never requested.

Troubleshooting

Match the message or state to the fix:

What you seeWhat to do
No Your Access view on the subscriptionThe plan is not scope-based. Your Access only renders for plans on Client Secret Basic or Private Key JWT with an authorization server bound, and at least one scope defined.
"Failed to load your access." in the portalA load error. Click Retry on the same notice. If it persists, check that the authorization server is reachable.
"Could not submit request. Please try again."The request did not save. Retry the submission.
The Restricted form will not submitThe justification is empty. The form shows "Please provide a justification for this restricted scope". Enter a reason, then Submit.
"No pending access requests" and "You're all caught up." in the dashboardThere are no scope requests waiting. New requests appear on the Access tab as consumers submit them.
No Access tab in Consumers, RequestsScope-based access control is not enabled for the account, so there are no scope requests to review.
A grant shows APPROVED_PENDING_SYNCThe approval is recorded but the provider bind has not completed. Apiable re-attempts it; an admin can also retry the sync from the grant.
The consumer cannot re-request after a declineA request with the same scope is still active. Wait for the existing PENDING request to be resolved, then request again.

Where to next