Step 1 - Authentication

API Reference

• POST Create Authentication Token

All requests are sent server-to-server. Your app or website should never be directly communicating with the DriveWealth APIs, as your private connection keys may be exposed in transit. All requests are required to be made via an HTTPS connection; requests made over plain HTTP will fail.

Task O1 - Successful Auth Token Request Response via API

In order to retrieve the Auth token you will need the following 3 data points provided in your Partner Specific credentials in your Partner Project Plan:

• dw-client-app-key
• username
• password

These will be sent in the request, the field "authToken" will be sent in the Response:*

• First, Get the Auth Token (dw-auth-token):

• These 3 values are provided in your DW Sandbox credentials, they are static and will not change

  • dw-client-app-key - header
  • username - request body (Back Office username)
  • password - request body (Back Office password)

• Second, now that you have the auth token include these two headers with each request (1.dw-auth-token 2. dw-client-app-key)

  • If you do not include either token when making an API request, or use an invalid token, you will receive an error response
  • Once retrieved in the API Response Auth tokens have a 12 hour expiry time : Response field "expiresAt":
  • Partners can request additional API username and passwords if using a server-less or micro-services framework.

Task O2 - Store 'dw-request-id'

• Store the response value (in the Header) for the field 'dw-request-id' ; this value is given to DW when helping trouble shoot any connection or other issues

Protecting your API tokens

• Do not store API tokens inside your applications source control: If you store API tokens in property or configuration files, keep these files outside your source control systems. This is especially important if you use a public source code management system such as GitHub. You may want to rely on environment variables or similar runtime injection techniques rather than keeping sensitive keys on disk.

• Do not embed API keys directly in code: Instead of embedding API keys in your application's code, put them in environment variables or include files that are stored separately from the bulk of your code – outside the source repository of your application.

• Limit employee access to production API keys: While keys to access our sandbox environment will likely be shared by many developers, access to production keys (when provided) should be limited to only necessary personnel.

Task O3 - Additional API users de-authentication Check

• Additional API users de-authentication Check
• If implementing Micro-services Architecture to prevent de-authentication (of the auth token); the token must be stored and retrievable by the additional services; when implemented you should not be de-authenticated when accessing multiple services
• Second method; the Partner may use more than one Back-office user to prevent de-authentication of the token in use