API Access Control

API Access Control lets you customize which groups and users on your platform can reach which parts of the JuliaHub API. JuliaHub ships a default set of access rules; this panel lets you override them for your site without waiting on a product change.

Overrides are recorded with a full change history and generate audit events, so you can show what was changed, by whom, and when.

This feature is only available on platforms with the customer admin role enabled.

Opening the Panel

  1. Open the Admin section in the left sidebar.
  2. Select API Access Control.

How Access Rules Are Organized

Access is expressed as a rule joining three things:

  • API set — a named group of related API endpoints, such as billing.cards or package.syncstatus.
  • Principal — who the rule applies to. A principal is a group (e.g. juliahub.user), an individual user, or anon for unauthenticated callers.
  • Access level — read, write, or read_write.

Every rule comes from one of two places, shown in the Source column:

  • Base — the rule JuliaHub ships. You can't edit these directly.
  • Site — an override you have added for this platform. Site rules take precedence over base rules.

When you override a base rule, the base row stays visible and gains an Overridden badge, so you can always see what the shipped default was.

The Three Views

The buttons above the table switch between:

  • Effective ACLs — the access that is actually in force, base and site rules together. This is the default view.
  • Change History — every site override ever added or removed, including ones no longer active.
  • API Sets Reference — the catalogue of API sets with a description of what each one covers. Useful when you're not sure which set governs a feature.

The filter box narrows the table by principal or API set. In the Effective ACLs view, the Source column header also has a dropdown to show only Base or only Site rules.

Protected Principals

The juliahub.admin group cannot be modified. Its rows are marked with a Protected badge and offer no Edit, Delete, or Add Override controls.

This is deliberate: it prevents an override from locking administrators out of the platform, which would leave the site unmanageable. If you need to change administrator access, contact JuliaHub support.

Changes Take Up to Five Minutes

Access rules are cached by the policy engine. After you save, allow up to five minutes for the change to take effect. The panel reminds you of this each time you save.

If you test an override immediately and it appears not to have applied, wait and test again before changing anything else.

Common Tasks

Add an override

  1. Click Add Override.
  2. Choose the API Set to govern.
  3. Choose the Access Level.
  4. Choose the Principal Type — user, group, or anon. Selecting anon hides the principal picker, since it refers to all unauthenticated callers.
  5. For user or group, pick the Principal.
  6. Optionally record a Reason. This is free text and appears in the change history and audit events, so a short note about why the change was made is worth adding.
  7. Click Save.

The new rule appears in Effective ACLs with a Site badge.

Override a shipped default

  1. Find the base rule you want to change in Effective ACLs.
  2. Click Add Override on that row. The dialog opens pre-filled with the base rule's api set, principal, and access level.
  3. Change the Access Level and click Save.

The base row gains an Overridden badge and the new site rule appears alongside it.

Change an existing override

  1. Find the site rule and click Edit.
  2. Change the Access Level and optionally the Reason. The API set and principal are shown but can't be changed — to move an override to a different api set or principal, delete this one and add a new one.
  3. Click Update.

An edit is recorded as a replacement rather than an in-place change: in Change History the previous entry is marked Replaced by new entry and the new one becomes active. Both rows remain, so the full sequence of changes stays auditable.

Remove an override

  1. Find the site rule and click Delete.
  2. Optionally record a reason.
  3. Confirm.

The shipped base rule takes effect again. If no base rule covers that api set and principal, the row disappears from Effective ACLs entirely — the principal simply has no access to that api set.

Review who changed what

Switch to Change History for the per-override record: who created or deleted each entry, when, and any reason they recorded.

For a platform-wide audit trail, open Admin → Audit Events and look on the unclassified tab. ACL changes are recorded as set_api_acl and delete_api_acl events, each with the api set, principal, access level, the user who made the change, and the event time in UTC. See the Traceability (Audit Events) guide for how to filter and export audit events.

Troubleshooting

The override doesn't seem to be working. Allow five minutes for the policy cache, then retest. If it still isn't applied, check the Effective ACLs view to confirm the rule shows a Site badge and the access level you expect.

I can't edit a juliahub.admin rule. That's by design — see Protected Principals above.

The list is long and hard to scan. Use the filter box to narrow by principal or api set, and the Source dropdown to show only your site's overrides.