Open BankingB2B SuiteERP Integration
GuidesAPI ReferenceChangelog
Menu

Categories

Open BankingB2B SuiteERP Integration

  • GENERAL INFORMATION

    • Documentation guide
    • SingleView Open Banking
    • KSAOB standards
    • Security best practices
  • GETTING STARTED

    • Integration guide
    • Developer console
    • Establish secure connection
    • Generate access token
    • Make test raw data API call
    • Make test data use case API call
  • CONSENT MANAGEMENT

    • Overview
    • Create a consent
    • Retrieve consent details
    • Revoke a consent
  • Raw Data APIs

    • Introduction
    • View accounts
    • View balance
    • View transactions
    • Identify account holders (Parties)
    • Review direct debits
    • Review scheduled payments
    • Review standing orders
  • DATA USE CASE APIS

  • Plug-and-Play Integrations

    • Payly
  • RESOURCES

    • Errors & codes
    • Collections
    • API version management
    • Bank connectivity
  • API Archives


API version management

Learn how API versions are managed for stable and reliable integrations

SingleView Open Banking APIs follow a structured versioning strategy to ensure stability, backward compatibility, and a smooth integration experience for developers. Versioning allows us to introduce improvements, enhancements, and new features while maintaining compatibility with existing integrations.

Important Information
  • The latest version of our API standards is v2. All the product releases for this version will adopt the v2 standard, and their endpoints will be prefixed accordingly.
  • All the information on the previous versions of APIs is available under API Archives.

API Version Format

SingleView uses URI-based versioning to manage API versions.

Each version is included in the API base path and is structured as

https://{{Domain}}/{{Version}}/api/observice/{{Service/Use Case Name}}

This approach ensures that applications can continue using a specific version of the API without being affected by future updates.

Backward Compatibility

Whenever possible, updates are introduced in a way that maintains backward compatibility.

Examples of backward-compatible changes include:

  • Adding new optional fields to responses
  • Adding new API endpoints
  • Improving performance or reliability
  • Updating documentation

These updates do not require changes to existing integrations.

Breaking Changes

When changes affect existing functionality, a new API version is released.

Examples of breaking changes include:

  • Changes to request or response structures
  • Removal of existing fields or endpoints
  • Changes in authentication requirements
  • Changes that affect API behavior

In such cases, the updated functionality will be introduced in a new version, allowing existing integrations to continue operating on the previous version.

Version Lifecycle

Each API version follows a defined lifecycle:

Stage

Description

Active

Fully supported version recommended for integrations

Deprecated

Older version scheduled for retirement

Retired

Version no longer supported

Developers are encouraged to migrate to the latest supported version to benefit from new features and improvements.

Version Updates

All version updates and changes are communicated through the Changelog section of the documentation.

The Changelog provides information on:

  • New features
  • Enhancements
  • Bug fixes
  • Deprecations
  • Version releases

Best Practices

To ensure long-term compatibility:

  • Always reference the API version in your requests
  • Monitor the Changelog for updates and deprecation notices
  • Plan periodic upgrades to newer API versions when available
Need support?

If you have questions regarding API versioning or migration between versions, contact us at info@onesingleview.com

Updated July 2, 2026

PreviousCollectionsNextBank connectivity
Was this helpful?