Register an OAuth app

What this achieves

An OAuth app is a registered client that authenticates against Humavera using the OAuth2 standard, rather than a single static key. Register one where an external application acts on behalf of a user, or where you want a credential you can rotate without changing the client identity.

Required role: Administrator.

Steps

Go to Integrations → OAuth Apps.
Select Register App.
Enter the App Name and a Description.
Enter the Redirect URIs, one URL per line.
Choose the Grant Types.
Choose the Scopes.
Select Register.
On the App Registered dialog, copy the Client ID and Client Secret, tick the acknowledgement, and select Done.

Grant types

Option	Description
Authorization Code	The application acts on behalf of a signed-in person, who authorises it. Requires a real redirect URI.
Client Credentials	The application acts as itself, with no user involved. For service-to-service integrations.
Refresh Token	The application can renew its access without sending the person back through sign-in.

Choose the fewest that the integration actually uses. An application configured for authorization code that only ever runs unattended has been given a capability it does not need.

Example: HC Corp’s finance reconciliation job runs overnight with nobody signed in. That is client credentials. A mobile app people log into is authorization code, usually with refresh token alongside it.

Redirect URIs

One URL per line. These must match what the application sends, exactly — a trailing slash or a differing scheme fails authorisation.

The form’s own help notes that a pure client-credentials application still needs at least one redirect URI, and suggests using a placeholder URL because nothing will ever be redirected there.

Scopes

Scopes are the same catalogue used by API keys, grouped by area, each a read or write grant on one kind of record. Grant the narrowest set that works. The * scope grants everything and should be the exception you can justify, not the default that saved five minutes.

The client secret is shown once

The registration dialog shows both credentials with a warning to save them now, because the client secret will not be shown again.

The Client ID stays visible and copyable in the list afterwards. The secret does not. If it is lost, the route is to regenerate it, not to retrieve it.

Rotating the secret

Select Regenerate Secret on the app.

The interface states what this does: the current secret stops working immediately, and any integration using it breaks. The new secret is shown once, with a reminder to update every integration that used the old one.

There is no overlap period in which both secrets work. Plan a rotation as a short outage on that integration rather than as a background task — regenerate, update the consumer, confirm it reconnected.

Example: rotating the secret on HC Corp’s reconciliation app at 09:00 on a Tuesday breaks the overnight job until somebody updates it. Rotating it immediately before the next scheduled run, with the new value ready to paste, costs nothing.

Revoking an app

Select Revoke and confirm. The interface states that revoking immediately invalidates the app’s credentials and breaks any integration using it, and that it cannot be undone.

Revoke an application you no longer trust, or one whose integration has been retired. A registered app nobody uses is a live credential nobody is watching.

Apps versus keys

Option	Description
API key	One static secret, scoped and rate-limited. Simplest for a job you control. Replacing it means creating a new key.
OAuth app	A client identity with a rotatable secret, and the option to act on behalf of a signed-in person. More setup, and the right choice where a third-party application needs user consent.

What happens next

The application can authenticate against Humavera within its grant types and scopes. Its client ID stays visible in the list alongside its grant types, scopes, and status. Where the integration also drives request volume worth watching, the API usage page reports on keys — check what your application authenticates as before relying on it appearing there.