API

What is an API?

An API (Application Programming Interface) enables third-party applications to interact with Wisenet through a structured interface. It provides access to specific data fields grouped into entities known as Endpoints. Each Endpoint represents a distinct data set and can be called as needed to send or retrieve information.

Wisenet’s Integrated App Platform now leverages OAuth authentication with scopes, replacing the legacy API key approach. This modern solution enhances security, flexibility, and control, ensuring seamless and secure connections between external applications and Wisenet.

How to use the Wisenet API

The Wisenet API is a RESTful web service designed to streamline integration between your third-party applications and Wisenet. By tapping into Wisenet’s workflow automation, the API reduces the need for developers to build complex integrations. Tasks like generating documents, sending emails, or creating tasks are handled automatically, simplifying the development process and boosting efficiency.

Common Use Cases

The Wisenet API offers numerous benefits and can be used in a variety of scenarios, including:

• Data Integration: Send and retrieve data between Wisenet and third-party applications.
  • Populate a membership application.
  • Sync data with an internal employee tracking application.
  • Integrate with a CRM or custom online applications.
• Web Integration: Connect your website to Wisenet or link another application directly with Wisenet.
• Data Updates: Update existing data in Wisenet, such as unit enrolment details, from an external system.

Best Practices for API Usage

• Testing Environment: We recommend using a test environment when developing integrations to ensure accuracy and prevent disruption to live data.
• Licensing Requirements: The API is available only with specific Wisenet licenses. Please contact us for access if needed.

By leveraging Wisenet’s API and its workflow automation capabilities, your organisation can efficiently integrate systems, automate processes, and achieve seamless data management with minimal development effort.

Why OAuth?

OAuth is an industry-standard protocol for authorisation. By adopting OAuth with scopes, Wisenet ensures your integrations are:

• Granular: Scopes define specific access permissions (e.g., course_read, unit_write).
• Secure: OAuth eliminates the need for long-term API keys, reducing security risks.
• Simplified: Tokens can be renewed or revoked without affecting other integrations.

Key Features

• Authorisation Scopes: Define specific access and actions for apps (e.g., course_read, unit_write).
• Token-Based Access: Temporary tokens provide secure access, with defined expiration times.
• Centralised Control (Coming Soon): Manage, monitor, and revoke tokens via Wisenet Connected Apps.
• Improved Logging: Gain visibility into app activity and access with detailed logs.

Developer Resources

The Developer Documentation includes:

OAuth Docs

Wisenet OAuth Docs

• Sample OAuth requests and responses.
• Step-by-step guides for the authorisation code flow.
• Best practices for managing and securing tokens.

Wisenet API Docs

• API functionality
• API endpoints and schema
• OpenAPI Specification

How to get started with OAuth API

OAuth apps currently need to be configured by Wisenet support.

To get your new integrated app set up, please log a support request and provide us with the following information from you:

1. An Application Name
   1. this will appear in the available connected apps
2. An explicit list of requested OAuth2.1 scopes
   1. See available scopes
3. One or more Redirect URLs to support OAuth2.1 authentication
   1. This url cannot have any included parameters

Important Note:
We do not support blanket requests for all scopes. If you submit a large list of requested scopes, we may ask for clarification on why each is required. Scopes should only be requested if they are absolutely necessary, as over-provisioning increases data security risks.

You can refer to the documentation links above for further guidance.

How to connect to API OAuth?

Once an OAuth app has been configured by Wisenet for your developer account, you will be able to login to Wisenet and see this under Settings > Developer Tools.

From Developer Tools you can obtain the Client ID and Client Secret. This can then be used in the OAuth process.

You will need to use the correct redirect url and other parameters.

Once testing is completed you can advise Wisenet to assign the same Integrated App to your production Wisenet account. This will allow the same Client ID and Client Secret to be used for any of your Wisenet Accounts.

FAQs

What is the difference between the OAuth API and the API Key based API?

All endpoints in the old API are the same and available in the OAuth API. There are however new endpoints available in the OAuth API.

The main difference is in the authentication used for the API calls.

What is involved to migrate to the new OAuth?

Once an Integration App is provision you are able to implement the new OAuth process and connect this to your existing API integration.

1. Register Your App: See How to get started with OAuth API (above)
2. Implement OAuth: Follow the OAuth Authentication Flow in the Developer Documentation.
3. Update Your App: Replace API key logic with token-based requests.

What happens to existing API key integrations?

API key support will be deprecated by early 2026. Existing integrations will continue to function until then but must migrate to OAuth before deprecation.

How do I know which scopes to assign?

Refer to the Scope Reference Guide for a breakdown of permissions for each scope.

What should I put in state, code_challenge, code_challenge_verifier parameters?

The API OAuth docs reference external resources that outline information regarding PKCE RFC.

If you need a working example then we recommend using AI to provide more details and generate appropriate values.

How can I handle OAuth redirect URIs when each of my customers has a different domain?

Use a single, stable redirect like https://auth.yourcompany.com/callback for every tenant. After you complete the OIDC code exchange on that domain, you perform a second, server-side redirect to the customer’s own URL.
How to implement safely:

1. Begin login from https://tenantA.yourapp.com and include a signed state carrying the tenant identifier and intended post-login URL (eg /{tenant}/dashboard).

2. Whitelist only https://auth.yourcompany.com/callback with your IdP.

3. At the callback:

   • Verify state and nonce; exchange the code for tokens.

   • Look up the tenant in your DB, fetch an allow-listed post-login domain for that tenant (eg https://tenantA.yourapp.com).

   • Build the final URL from the allow-listed base + a validated relative path from state, then 302 the user there.

Why this is good:

• Keeps the IdP’s whitelist tiny and stable.

• Avoids wildcard redirect URIs.

• Mirrors guidance from platform docs — if you have “too many redirect URIs,” carry tenant info in state and final-redirect yourself.