Table of Contents

Application Types

Application types describe how an application connects to an ERP.net instance, not what business problem it solves.

They help you decide:

  • whether users are involved at all
  • whether API access happens on behalf of a user, on behalf of the application, or via a reference token
  • which identity authority is involved
  • which authentication guide applies
Important

ERP.net instance APIs are always accessed using tokens issued by the instance identity service
(https://<instance>.my.erp.net/id).

The global ERP.net Identity (id.erp.net) is used only for user authentication (SSO) and does not issue access tokens for instance APIs.

Summary

Application type Typical scenario Who signs in How API access is performed Auth guide Typical API
SPA Applications Browser-only app, no backend Internal users On behalf of the signed-in user Instance ID for SPA Applications Domain API
Web (Confidential) Applications Web app with backend Internal users On behalf of the signed-in user Instance ID for Web Applications Domain API
Web Portals Customer / partner portals Internal and/or external users On behalf of the application (service identity) Instance ID for Web Portals Domain API
Service Applications Background integrations, sync, daemons None On behalf of the application (service identity) Service Applications Domain API
Automation Scripts, scheduled jobs, ops tooling None On behalf of a reference token Automations Domain or Table API
Note

Business Intelligence, reporting, and backup are usage patterns, not standalone application types. They are implemented using Service Applications or Automation, depending on operational needs.

Application Type Details

SPA Applications

Use this type when your application:

  • runs entirely in the browser
  • has no backend component
  • cannot keep a client secret

Characteristics:

  • users sign in interactively
  • access tokens represent the signed-in user
  • Authorization Code flow with PKCE is mandatory

See:
Instance ID for SPA Applications


Web (Confidential) Applications

Use this type when your application:

  • has a backend capable of storing secrets
  • serves internal users
  • performs API calls as the signed-in user

Characteristics:

  • users sign in interactively
  • access tokens are issued on behalf of the user
  • Authorization Code flow is used

See:
Instance ID for Web Applications


Web Portals

Use this type when your application:

  • allows users to sign in for identification or session context
  • supports internal and/or external users
  • performs all API access from the backend

Characteristics:

  • users authenticate for identity only
  • external users never receive API access
  • API calls are performed on behalf of the application
  • combines Authorization Code (for users) and Client Credentials (for APIs)

See:
Instance ID for Web Portals


Service Applications

Use this type when your integration:

  • runs without user interaction
  • performs background processing or system integration
  • needs controlled, scoped API access

Characteristics:

  • no user sign-in
  • Client Credentials flow
  • access tokens represent a service identity

See:
Service Applications


Automation

Use this type when your integration:

  • is script-based or operational
  • does not implement OAuth flows
  • requires long-lived access

Characteristics:

  • no user interaction
  • uses manually issued reference access tokens
  • suited for jobs, tooling, and controlled automation

See:
Automations


BI, Reporting, and Backup Scenarios

Reporting, analytics, and backup workloads are implemented using:

  • Service Applications for OAuth-based access, or
  • Automation for long-running or scheduled tasks

In these cases:

  • prefer the Table API for high-volume, read-only access
  • restrict scopes to read only

See: