SOAP API Authentication Changes

Why is it changing?

To facilitate better security and tracking for billing purposes, we are implementing some additional infrastructure in front of our APIs.

What is not changing?

The payload for these SOAP services, including the Username / Password that has historically been passed, is not changing.

What is changing?

URLs

Environment	Old Url	New Url
UAT	`https://seadmin-uat.stoneeagle.com/ARCH/ARCHService/menuintegration.svc`	`http://api.stable02-uat.sefiprod.com/soap/menuintegration`
Production	`https://arch.stoneeagle.com/ARCH/ARCHService/menuintegration.svc`	`https://api.stoneeagle.com/soap/menuintegration`

Authentication

Username / Password
Previously both the SCS and SEA SOAP services required a username and password to access them. To keep the structures the same, you will presently need to continue passing that, though we may in the future make backwards compatible changes to make those no longer required.

JWT Token
In addition, the Username / Password passed in the SOAP body, a JWT token will be required. This will require an additional Client Id and Secret that currently must be provisioned by StoneEagle. Once you have the Client Id and Client Secret, the following documentation explains how to use it to acquire a JWT token: API Access | Common API Docs | StoneEagleCONNECT
There will be a single Client Id / Secret pair for each application, however as outlined in the documentation, the “scopes” you ask for will differ depending on which tenant and APIs you are trying to access. Tenant Identifiers will be provided once a provider engages in the onboarding process.

API Key
In addition to the Username / Password and JWT token, an API key will be provided and must be passed in the header x-API-key
This API key will not change based on the tenant being accessed.
If the consumer has distinct applications that have distinct business purposes, secondary API keys may be provisioned at the request or requirement of StoneEagle.