Getting Started

Get started with the SEI API Platform!

The Integration Portal displays the collection of SEI’s API products for mobile, web/single-page, and client-server development in addition to rich documentation. We offer expertise in the wealth and asset management markets and design APIs as products fitted to your needs.

Build your use case quickly and securely on a platform that grows with your business. 

Let's Get Started

1. Register for the Developer Portal.

New to the Integration Portal?

Please contact your SEI Partner/Relationship Manager. We request that each organization provides a team email distribution list. For security purposes, this will prevent API security artifacts from being tied to one individual. Once the account is set up, you will receive the login credentials via email.

Already registered?

To create or view an application, please log in and navigate to My Apps. 

2. Create an application for API access.

Browse the API Catalog and discuss your business use case with your SEI Partner/Relationship Manager to determine which API products are applicable. Read our "How to Add an App" guide to learn more.

3. Receive the required security artifacts.

There are five security artifacts necessary for API runtime access. Once your application has been approved, you will receive the first four security artifacts. You will receive the certificate in 1-2 days following approval. Remember to protect these security artifacts.

4. Begin testing. 

Refer to the API documentation in order to understand what is required to run each API. Please refer to our "How to Test" guide to understand how to test with Postman. We publish custom Postman collections for your use, but any platform can be used to test.

5. Go live.

Once your application is prod-ready, we request that you create an application to access the production environment. 

6. Receive continued support.

We are available at APISolutions@seic.com for continued support. 

View the API documentation to learn more about our products.

Looking for more information? View our FAQs 

API Basics

API Keys

API keys, also known as the AppKey and AppSecret, are a way to authenticate applications. Upon registering an application with SEI Developer Portal, a consumer key and secret pair is generated. This serves as an application identifier and is unique to each application registered with the Developer Portal. The key/secret must be encoded base 64 to be utilized to obtain an OAuth Token.

Environments

SEI’s API products have various options for different environments accessible to developers for their stages of integration from building/testing to live environments.  

Methods

Key Definitions

• Tracking ID: Each API request made returns a tracking Id that should be stored by the consuming application and can be used by SEI to trace or troubleshoot at the request level.

• Open API Specification 3.0: An API specification for REST APIs. 

• Token: The authentication key minted after invoking the OAuth API endpoint with valid credentials.

• MTLS: Mutual Transport Layer Security.

• IP Whitelisting: Security mechanism to allow application access to only a certain range of IP addresses.

• cURL: Client URL command. This is the API request sent to the server. 

• Path parameter: Help identify or narrow down the hierarchy of the resource. These parameters are included within the URL path, i.e. PATCH https://mtls.api.seic.com/v1/thirdparties/{externalId} = https://mtls.api.seic.com/v1/thirdparties/zH745A

• Query parameter: Used to filter, sort, or search within an API request. These parameters are included at the end of the URL, i.e. GET https://mtls.api.seic.com/v3/thirdparties/metadata?limit=10&active=true

• Header parameter: Used to define HTTP headers. These parameters are included within the API request/cURL, i.e. curl --location --request GET 'https://mtls.api.seic.com//v3/thirdparties/metadata' \ --header 'Authorization: Bearer xxx' \ --header 'AppKey: yyy'

Authorization Overview Guide

SEI uses OAuth 2.0, the authorization and authentication mechanism preferred in the industry. OAuth 2.0 ensures security by granting deliberate and verified permissions through API Keys. This document provides a general overview of the process using the authorization code grant type and the API calls used to interact with our service.

An application making SEI API Requests from a Client/Server or Server/Server type of infrastructure will leverage the grant_type client_credentials while minting an oAuth token from the Token API. The oAuth token has a 60 minutes active time to live (TTL) and 30 minutes inactive TTL. The oAuth token obtained from client_credentials cannot be refreshed.

Mutual or 2-Way TLS is typically used when user context is not present and a Client/Server application is registered through the SEI Developer Portal. For more information, view Implementing Two-Way TLS.

Before beginning this guide, it may be helpful to familiarize yourself with OAuth2 and how it works.

Using OAuth

Before you can make any OAuth calls, you must obtain an AppKey and AppSecret. These can be found within MyApps. If you have not created an app yet, view our 'How to add an app' guide to walk through the progress.

How To Authorize and Create an OAuth Token: Overview

Please view the detailed pages for more information.

1. Refer to the OAuth documentation. Your application needs to call this API. The appropriate URL depends on the use case and application type. This call will execute an HTTP 302 Redirect from your web application to the SEI OAuth Login Page. See OAuth Authorize for more information.
2. After logging in, the SEI API will redirect back to your application using the redirect_url parameter specified in the /authorize call. The query parameters of the GET call will contain an authorization code that is valid for 20 seconds.
3. Using this authorization code, your application can now call the OAuth API and obtain the two tokens Auth and Refresh. The Auth token expires after 60 minutes while the Refresh token expires after 30 days. See Create OAuth Token for more information.

How To Use an OAuth Token: Overview

Now you can begin to make API calls. The OAuth token is passed to existing API calls in the “AUTHORIZATION” HTTP header as a ‘Bearer’ token. For example:

Authorization: Bearer <access_token>

To re-establish a session with the API, use the /v2/oauth/token API call with the refresh_token grant type and pass the ‘refresh’ token. Doing this means you do not have to re-execute the three legs of the authorize flow.

See  OAuth Token API  for more information.

In addition, pass the token to the /v2/oauth/tokeninfo API call to retrieve details about the token itself, including when it expires and the scope it was issued for.

See  Get Token Info  for more information.

How to Authorize an API

Upon successful client login, the authorize API will redirect with HTTP 302 to the redirect_url provided and set the state and access code in URL parameters.

Request Parameters

How to Create the OAuth and Refresh Token

Request Parameters

Parameters can either be in the query string or x-www-urlencoded-form.

Form Parameters

If you are using the client_credentials grant type, pass the following parameters as x-www-urlencoded-form values.

If you are using the urn:ietf:params:oauth:client-assertion-type:saml2-bearer grant type to log in using SSO, pass one of the following parameters as x-www-urlencoded-form values. SAML assertions can be constructed in one of two ways: a signed SAMLResponse object or a signed SAMLAssertion object. 

Example Response Payload

{

    "access_token": "<access_token>",

    "token_type": "BearerToken",

    "expires_in": 3599,

    "refresh_token": "<refresh_token>",

    "refresh_token_expires_in": 2591999,

    "redirect_url": "https://www.redirect.com",

    "email": "<IL_account_email_address>"

}

Additional Parameters

How to Call an OAuth Token

Request Parameters

NOTE: Token must be passed as - Authorization: Bearer <access_token> header

Response Payload

{
     "access_token": "<access_token>",
     "token_type": "BearerToken",
     "expires_in": 3591,
     "status": "approved",
     "scope": "ilservices",
     "refresh_token": "<refresh_token>",
     "refresh_token_expires_in": 2591991,
     "redirect_url": "http://www.redirect.com",
     "email": "IL_account_email",
     "app_name": "IL-oauth-test"
}

Response Parameters

How to Revoke an OAuth or Refresh Token

Revokes the specified oauth2 access token or refresh token, as well as the associated access/refresh token.

Request Parameters

Response Payload

{

     "message": "the passed token and associated refresh/access token have been revoked",
     "token": "<token>",
     "cascade": "true"

}

Implementing Two-Way TLS

Mutual or 2-Way TLS is typically used when the user context is not present and a Client/Server application is registered through the SEI Integration Portal. Per SEI’s Information Security requirements, the SM service account is used to mint the Oauth token by using grant_type = client_credentials and implemented with IP whitelisting.

To set up Mutual TLS between SEI and the client’s server, the client must obtain an identity certificate from a SSL provider. The Common Name (CN) of the cert is the service account’s username provided by SEI. If the client is unable to obtain an Identity cert from their provider, SEI will distribute a client cert through our SSL provider, Trustwave.

The SEI certificate download link and instructions are valid for one download. Once the certificate has been downloaded, the link will not work again. If the link expires, please contact SEI to receive a new link. The SEI certificate will expire after two years and the client will be notified ahead of time.

To establish a successful Two-way SSL communication with SEI, the client server making API Calls must:

1. Come down the TLS URL: ( https://mtls.api.seic.com/ )

2. Come from a whitelisted IP source

3. Use a service user credentials

4. Present the identity certificate  

Error Handling

Our APIs use a standardized approach to error handling.

When an error is thrown, the API provider typically expresses the error in two parts:  

• HTTP Status Code and Reason

• Error Payload

In general, a 4xx code indicates a client error while a 5xx code indicates a server error. The payload provides more insight into the cause of the error and solution.

HTTP Error Codes

The following section lists the most common HTTP Error Codes and their meanings:

For more information about solutions to these errors, please refer to our FAQs.

For more information about our error handling process, please refer to our API Style Guide.

Getting Started - 1001

For a two-way TLS connection, a certificate must be chosen.

1. SEI Issued Certificate:

1. SEI uses a trusted Certificate Authority to issue identity certificates. Leading to quicker API integration, this can be selected in the AddApp form and will distribute the certificate to the email distribution list provided.

2. Alternate Certificate:

1. Entrust and Trustware are Certificate Authorities approved by SEI. To use a different trusted CA that can provide an identity certificate, please contact APISolutions@seic.com for review and approval. It must meet SEI Common Name (CN) specifications, the Common Name must be the same as the Service Username returned to the client post runtime establishment.

Please refer to our FAQ section 'Security' to learn more about how to download an Identity CERT. To extract .crt and .key files from the pfx CERT, please execute the following commands after installing OpenSSL and refer to the following links for detailed instructions:

Commands

• openssl pkcs12 -in [yourfile.pfx] -clcerts -nokeys -out [certificate.crt]

• openssl rsa -in [keyfile-encrypted.key] -out [keyfile-decrypted.key]

Instructional Links

• "Converting .pfx to a .crt/.key files" - Medium

How to Test

1. Use your preferred tool to test. We use the tool Postman.

2. Download the collection for your registered application.

3. If you have not yet imported the environments,

   1. Click on the settings button in the right hand corner of Postman.

   2. Click on the Import button on the “Manage Environments” page

   3. Open each environment and fill in the respective variables: AppKey, AppSecret, Username, Password

4. Use the API documentation to fill in the required fields and payload for the API.

5. Click send and confirm a 200 OK response.