Best practices


There are countless things to consider in software development projects, and on this page we will highlight some important things what we find important for successful integration projects, from an Integration Platform perspective.


graph TB r[Sharespine Integration Platform] --> t1[Development] r[Sharespine Integration Platform] --> t2[Staging] r[Sharespine Integration Platform] --> t3[Production]


  • An account for testing during the development of an integration. This account is dedicated to a specific integration.
  • Data can not be deleted from the account.
  • It is possible to request a new empty account, the old account will then be deleted. The partner will have to recreate all settings in the new account.


  • An account for final testing before the release of a new feature. This account can be used by multiple partners that are involved in a project. Each partner is responsible for handling the data according to the specifications within the project.
  • The account should have the exact same settings as the production account.
  • Data can not be deleted from this account.
  • It is possible to request a new empty account, but it requires a new setup and new syncs between systems. Replacing an account is a last option.


  • This account should only be used after functions have been tested and verified on a staging environment.
  • Data can not be deleted from this account. The account can not easily be replaced with a new account.

Account hierarchy

graph TB n1[Environment X] --> n2[Reseller 1] n1[Environment X] --> n3[Reseller 2] n1[Environment X] --> n4[Reseller ...] n2[Reseller 1] --> n6[Tenant 1] n2[Reseller 1] --> n7[Tenant 2] n2[Reseller 1] --> n8[Tenant ...] n6[Tenant 1] --> n9[User 1] n6[Tenant 1] --> n10[User 2] n6[Tenant 1] --> n11[User ...] n7[Tenant 2] --> n12[User ...] n8[Tenant ...] --> n13[User ...]


Tenant accounts are completely separated and data can not be copied between Tenants. For example;

  • Any setting that is created in one Tenant needs to be manually created in another Tenant.
  • All data that has been imported to Sharespine Integration Platform into one Tenant needs to be imported again for another Tenant.
  • Some remote systems only return changes since last request. This is important to know in case multiple tenants are connected to the same remote system. Avoid this setup unless you know exactly how the remote system handles data.


You should always create a dedicated API user for your integration as best practice. Then you can set custom permissions on it, and it is easier to block specific integration if needed. If you use shared accounts it will probably end up in problems further down the road. Don’t do that.

Test routine

  • Each partner is responsible for testing its isolated integration. The tests must verify that the correct data is altered and the requirements are fulfilled. The tests must be done using the developer account.
  • A test with real life scenario and realistic data must be done on the staging account. In some cases this need to be done with multiple integrations. The tests will be the last step before deploying the integration in production.
  • Production test should be done after the deployment to make sure that the correct settings are applied.

Handling of data

  • Each integration must have a defined use case and a defined set of data.
  • A documentation of the integration must exist and contain a definition of the data that is manipulated in the platform.
  • The integration is only allowed to add or change the data that is defined in the specification.
  • An integration is only allowed to modify custom data that was created by the same integration.