Administer access & settings

The Settings group is administrator-only — it holds the credentials and configuration that let other systems talk to Oclavex, plus your environments. (Admin)

Users, roles and seats

People, roles and seats are covered in their own guide — Set up your account & team. In short: Customers → Users, assign one of the four roles, and note the administrator-seat cap.

API credentials

Settings → API credentials is where you register the OAuth/OIDC clients your own code authenticates as. For each client you set a type (public or confidential), its grant types, scopes and redirect URIs.

Depends on your plan

Every plan includes at least one API client, so you can always register a credential to authenticate your own code instead of sharing a password. The number you can register scales with your plan (Oclavex Plans); once you reach the limit, New client returns an upgrade prompt. Free registers machine-to-machine clients only — a public client or the authorization-code flow needs Basic or above (what depends on your plan).

• Create a client, then copy the client ID. For a confidential client the secret is shown once on creation — copy it then; if it’s lost, Rotate Secret to issue a new one.
• Enable/Disable or Delete a client to cut off access.
• Platform-managed clients (the portals and internal callers) are read-only — you can see them but not edit them.

This is the portal side of Authentication for developers — the scopes you grant here are exactly what the API enforces.

License signing keys

Settings → License signing keys manages the RSA keypair(s) that sign license tokens, offline activation responses, and usage receipts. Every deployed application verifies against these keys, so only an administrator sees this page.

• Publish a new key — it doesn’t sign anything until you Promote it, so publishing is always safe to do ahead of a rotation.
• Promote makes a key the one new licenses and envelopes sign with. The key it replaces keeps verifying what it already signed until you retire it.
• Retire stops a key verifying anything, immediately — the page won’t let you retire the currently-active key or a provider’s only remaining key.
• Copy the public key for any listed key from its row — this is the value you embed in a client build; it’s public and safe to distribute.

Full walkthrough, including how this coordinates with an SDK release, is in rotating the license signing key.

Integrations

Settings → Integrations issues OAuth credentials for off-the-shelf tools (e.g. Zapier) rather than your own code. Create a credential, Rotate Secret, and Enable/Disable as needed. It’s the same idea as API credentials, scoped to a named integration.

Depends on your plan

Integration credentials are part of the connector credentials capability, included in Enterprise plans. See what depends on your plan.

Webhooks

Settings → Webhooks is where you subscribe an endpoint to events. Create a subscription with its event types, receiver URL, callback scopes and signing secret; Test it, Rotate Secret, and inspect and requeue failed deliveries. The event catalog and signature-verification details are in the developer reference — Webhook events; building a receiver is covered in Receiving webhooks.

Depends on your plan

Outbound webhooks are included from the Professional plan; on a plan without them, creating a subscription is refused as not included in your plan. See what depends on your plan.

Login providers

Settings → Login providers chooses which external sign-in providers (e.g. Google, GitHub, Microsoft) appear on your environment’s sign-in page. Only people already invited to your environment can use them; providers you don’t change inherit the platform default.

Environments

Settings → Environments lists the environments under your account — production plus any non-production ones — and Add environment provisions a new one once production exists. Pick Sandbox (development and CI) or Staging (pre-release rehearsal); you can have several of either, up to the total your plan includes. Model and rehearse there; move the product catalog across with Catalog transfer.

Adding and removing environments happens in your production environment. Each non-production row carries a delete action there, freeing capacity so you can create a replacement; production itself has none. Deletion asks you to type the environment’s identifier to confirm, and cannot be undone. Signed into a sandbox or staging environment, the list is read-only and points you back to production — and the API enforces the same rule, so no environment can be added or removed from there, including a sibling.

Each non-production row also carries a reset action, which empties the environment without removing it — the address, the subscription and administrator sign-in all survive, so a sandbox can be started over without a re-invite. Reset from production or from the environment itself; production is never resettable. Everything else goes, including registered API clients and machine credentials, so integrations have to be registered again. It asks for the same type-to-confirm and cannot be undone. See start a non-production environment over.

Catalog transfer

Settings → Catalog transfer moves catalog data between environments as JSON. Export covers products, feature definitions, monitored assets, suites, usage plans, add-ons, entitlement offers and rating campaigns, and import applies all of them.

You can export whole sections from this screen, or a single item using Export… on a row in Products, Add-ons, Feature Catalog or Rating Campaigns. A single item brings whatever it needs with it: export an add-on, and its suite — with that suite’s plans, products and features — travels with it, because a file missing those could not be applied anywhere. The dialog lists what is coming along, and says which item pulled each one in, before you download.

Before applying a file, use Compare with this environment. It reports what each item would create or update, field by field for updates, and lists anything already here that the file does not mention. Nothing is written — the comparison runs the import and rolls it back, so what you review is what an apply would do.

An import never deletes. Items and nested members absent from the file are kept, and the result says which were kept, so a file that omits something cannot quietly remove it.

Compliance

Administrators also have the Compliance group — Audit Log, Privacy Requests and Processing Activities. Those are covered under Security & Compliance.