CATEGORIES

A unique identifier (guid) that is generated for every API request, response, and error. 

  • The RequestTrackingId is sent to the application consuming the APIs and it must log the RequestTrackingId within the application logs.

During troubleshooting, when we have multiple systems in play, the RequestTrackingId helps tie all the system points of contact together and can be leveraged commonly to trace through the different system logs for a particular request, response or error.

All the SEI APIs will return the following standard structure in the event of an error: 

{
"code": "gateway.authentication.failure",
"message": "Gateway Authentication Failed, Please validate Credentials",
"trackingId": "6cfbfd80-60ef-04bb-8b67-95f164846a3d",
"transient": "false",
"errors": [{
"field": "",
"location": "",
"reason": ""
}]
}
 
code

A semantic code which will be used by SEI Technical Operations to troubleshoot the issue. 

message Message accompanies the error explaining the reason behind the failure.
trackingId A unique identifier marrying the request response together across systems. This id should be used for logging purposes by the application. 
transient Indicates if the error is temporary and the original request can be retrieved without any modifications. 
errors.field The name of the field where the error has occurred. 
errors.location The location of the invalid field.
errors.message A message indicating the reason for the failed request. 

 

SEI APIs do not have any custom restriction on the length of the query parameters entered for an API.  Restriction on data length for GET vs POST HTTP methods are the following:

 

GET

POSTS

While retrieving data using the GET method it adds the data to the URL; and the length of a URL is limited (maximum URL length is 2048 characters)

No restrictions

 

     Source: https://www.w3schools.com/tags/ref_httpmethods.asp

     For more information on browser induced character limitations please refer to:

     http://stackoverflow.com/questions/812925/what-is-the-maximum-possible-length-of-a-query-string

SEI APIs perform cursor based pagination. 

Cursors are base64 encoded result of other sequential properties on the entity, typically just the id or row_num.

Example of the paging object returned in the API response:

{
"paging": {
"totalCount": 8301,
"limit": 15,
"first": "before={base64 encoded value}&after={base64 encoded value}",
"last": "before={base64 encoded value}&after={base64 encoded value}",
"previous": "before={base64 encoded value}&after={base64 encoded value}",
"next": "before={base64 encoded value}&after={base64 encoded value}",
"self": "before={base64 encoded value}&after={base64 encoded value}"
}
}

SEI uses the URI to manage different versions of the same API.  e.g., https://api.seic.com/v1/.  API documentation in the Developer Portal will indicate any change in the API versions offered by SEI Developer Portal. SEI will also send out a communication to it's users when a new version is released.  It is recommended for users to also visit the News and Blog section of the Developer Portal periodically to get updates as well.

New API Products will be featured on our Home page and in our Solutions section. 

Keep an eye out for the Blog posts as well which will talk about new API Products available for use.

  • Any URL included in SEI API response under the "data" object is always referenced using the href attribute. 

  • Relationships are modeled as links (array) where each link has two attributes: rel and href

    • The “rel” attribute will reflect the name of the relationship

    • The “href” attribute will be a URL to access the relationship data

More Details on HATEOAS: https://spring.io/understanding/HATEOAS

Automated emails from "noreply@seic.com" will be sent to the concerned email address. One email containing the userId and a second email containing the temporary password are sent. 

Upon initial login, the user will be guided through security questions and password reset steps.

 

For External Users:

Navigate to the SEI Developer Portal login page and click ‘Forgot Password’. Enter answers for the security questions to change your password successfully. 

For Internal Users:

      Please go through your respective user management process.

For External Users:

Users interested in getting provisioned to the SEI Developer Portal please contact either the SEI Relationship Managers or APISolutions@seic.com. 

 

Depending on the application you are building and the API interaction between your application and SEI APIs, the end users may need to be provisioned in SEI's user store.

Please refer to documentation on oAuth and grant_types to understand more. 

If the end users need to be provisioned in the SEI user store please contact the SEI Relationship Manager  or APISolutions@seic.com.

Contact APISolutions@seic.com with below details: 

  • API Environment: < Dev/QA/Pilot/Prod>
  • APP: <Name of the application registered in SEI Developer Portal> 

SEI Developer Portal is used for communication with the SEI Developer Community.  App Developers will use the Developer Portal to register their application to obtain a key/secret and preview available APIs. App Developers will use interactive API documentation to understand the functionality of the SEI APIs related to the Product.  In addition to registering an application, viewing API documentation, viewing analytics for the specific applications, developers can remain updated with SEI news by visiting the News and Blog section.

SEI Developer Portal can be used by an App Developer, Business Analyst or a Product Manager.

An App Developer can use the SEI Developer Portal to register an App and consume SEI APIs.  A Business Analyst can view API Documentation to understand if the APIs will cater to the application requirements or not.  A Product Manager can view Application analytics to analyze the usage of the APIs and build reports. 

Users registered with SEI Developer Portal can consume approved services. If you are a not a registered user, please contact SEI to be granted access.

The API product is a logical grouping of API endpoints bundled and published so that developers can consume them. The Products can be viewed under the Products section on SEI Developer Portal.

Product Documentation is an interactive document located on the SEI Developer Portal that allows App Developers to understand SEI API’s functionality and content.

Please click HERE to obtain contact information for any type of support.  

The Terms and Conditions can be found at the bottom of each page in the lower left corner and detail the terms of use for the SEI Developer Portal.

  • Log into the SEI Developer portal.
  • Navigate to the My Apps menu.
  • Select ADD APP.
  • Enter required information.
  • Choose an API product(s) from the available products and create an App.
    • NOTE: If you do not have access to a particular API, contact APISolutions@seic.com to request access per the terms of your signed contract.

To view the registered application details:

  • On the Home page, navigate to the My Apps menu.
  • This page will display all the apps you have created and their Approval Status.
  • Click on the App Name and the accordion for that App will expand displaying the details specific to that App.
  • On the Home page, navigate to My Apps.
  • This page will display all the apps you have created.
  • Select on the App name and this section will expand, displaying details related to the specific application.
  • Under the display, look for a section called “Keys”.
  • Select “Keys” and the consumer key and secret information is displayed in this tab.
  • By default, the Keys and Secrets are hidden from display.  Click Show to display the values for your application.
  • On the Home page, navigate to My Apps.
  • This page will display all the apps you have created.
  • Select on the App name and this section will expand, displaying details related to the specific application.
  • Under the display look for a section called Delete "App name”
  • Select Delete option and a pop will be displayed. If you are sure that you want to delete the app, select the Delete App option.

Deleting an application in Developer Portal will lead to the deleting of the application, related keys and any metadata. Application Developers will need to add the application again (same name / different name), with the required Products. This will lead to new key / secret generation. The Application Developer will need to configure his applications to use the new key / secret values. 

If the error is while invoking an API, please see below troubleshooting steps:

  1. Make sure you are using a Base64 encoded version of the App Key and Secret value.
  2. Make sure your key/secret wasn’t accidently refreshed by SEI upon your Manager’s request; if so the current values will no longer work to invoke any of the accessible APIs.
  3. Make sure there are no typos anywhere (URL, request parameter , Authorization parameter etc)
  4. Mare sure you are using the correct environment.  Our Test environment base url is: https://test.api.seic.com/ while our Production environment base url is https://api.seic.com/.
  5. Make sure the quota was not exceeded.
  6. Please read through the error returned by the API. We try to keep our errors informative enough to point out an exact solution.

 

If your problem still persists, please click HERE to contact SEI to provide us the Request Tracking ID which is located in the response header.

The only reason why this could happen for the SEI Developer Portal is if you have not been granted access to the specific product.  To obtain access, please contact your SEI Client Relationship Manager or email APISolutions@seic.com.  

API keys are a way to authenticate applications consuming APIs from SEI Developer Portal. 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.

It is also referred to as Consumer Key & Consumer Secret or App Key & App Secret

NO. API Key / Secret pair is unique to every application. Each application must have their own API key / secret.  An App developer can register more than one application to obtain additional API keys / secrets.

Deleting an application in Developer Portal will lead to the deleting of the application, related keys and any metadata. Application Developers will need to add the application again (same name / different name), with the required Products. This will lead to new key / secret generation. The Application Developer will need to configure his applications to use the new key / secret values. 

No, an API key / secret pair doesn’t expire. Upon official requests with valid reasons, an existing pair can be de-activated and a new value can be generated for a registered application.

Unfortunately, no. Any requests to invalidate or regenerate API Key/secret pair needs to be submitted via email to SEI with relevant reasons explained in the email.  Please click HERE to obtain contact information for SEI Developer Portal

Please click HERE to obtain contact information for any type of support.

SEI uses the 5 standard REST API methods.  The API method is the procedure in which the particular API will retrieve information for the App Developer. Based on the API, SEI APIs may support any one or multiple types of API methods mentioned below:

1

GET

The GET method is used to retrieve information from the given server using a given URI. Requests using GET should only retrieve data and should have no other effect on the data.

2

POST

A POST request is used to send data to the server, for example, customer information, file upload, etc. using HTML forms.

3

PUT

Replaces all current representations of the target resource with the uploaded content.

4

DELETE

Removes all current representations of the target resource given by a URI.

5

PATCH

Replaces a particular representation of the target resource with the uploaded content

Users should refer to the signed SEI API Order Form or Contract which includes the agreed upon limits for each application.

Mutual or 2-Way TLS is typically used with SEI partners and clients where user context is not present and a Client/Server application is being registered through the SEI Developer Portal. The SM service account (svcPartnerNameV01) is used to mint the Oauth token using grant_type = client_credentials per SEI’s Information Security requirements and implemented with IP whitelisting. To set up TLS between SEI and the client’s server, the client must obtain an identity certificate from a SSL provider where 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. This document will be used to walk the user through how to extract the identity certificate after the cert is downloaded from the Trustwave Portal. ;

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

  • Come down the TLS URL: (https://mtls.api.seic.com/)
  • Come from a whitelisted IP source
  • Use a service user credentials
  • Present the identity certificate 

Client-Server or Server-Server type of applications are required to establish Two way SSL with SEI API Platform. 

An Application consuming SEI APIs needs to be implement one of  the following standards based on their use case:

Application Type Actor SEI Security Standard
Client-Server/ Server-Server Server

OAuth grant_type= client_credentials

Two way SSL

Must use service accounts

Use port 444

Client-Server End User

OAuth grant_type= Auth Code for SEI clients

OAuth grant_type= Password for SEI Internal Apps

Single Page Web Apps End User OAuth grant_type= Implicit
Native Apps End User OAuth grant_type= Auth Code with PKCE

Legend: Actor in this context means a human or non human user driving the API interaction decisions via the application. 

SEI API Program uses OAuth 2.0. OAuth 2.0 is the industry-standard protocol for authentication and authorization.

The application intending to consume SEI APIs needs to authenticate and obtain an OAuth before invoking any functional APIs to retrieve data.

Refer to the "Step 1" oAuth Token documentation under any API Product for more details.

More Info on OAuth 2.0: https://tools.ietf.org/html/rfc6749

SEI API Program uses OAuth 2.0 authorization framework enhanced to meet SEI Security requirements. 

The specification describes multiple workflows/mechanisms through which the end user or the client application are challenged for their credentials to perform validation before returning data. 

While the specific workflow is governed by many factors the general theme is to impose a more challenging workflow where the risk is deemed higher. 

Below flow describes which grant_type can be used based on the application interacting with the APIs

 

 

 
Two Way TLS is a mandatory requirement for server based application to integrate with SEI APIs. To facilitate Two Way TLS an identity certificate with CN matching the service account username is needed. During the Application registration process if the client selects SEI Cert that would mean that SEI will provision the certificate using trusted parties such as Trustwave or Entrust and provide it to the client. The SEI cert download link and instructions i valid until one download. Once the Cert has been downloaded the download link will not work again. If the cert has not been downloaded and the link expires , please contact SEI and we can issue a new link. The SEI cert will expire after 2 years. The client will be notified ahead of the expiration time about requesting a new cert to avoid production issues.

1. DO NOT USE Google Chrome to download the certificate. Use Internet Explorer if possible. You may encounter challenges with using Chrome to download the cert when it comes to installation.

2. The email address associated with the application in the SEI Developer Portal will receive an email similar to the below, which provides a link to download the certificate. NOTE: The link expires after the first download attempt.

Install OpenSSL (If already on your computer, skip this step) 
1. You will need open ssl installed on the machine you will use to extract the .pfx, .crt, or .key files
2. Go to: https://sourceforge.net/projects/openssl/
3. Complete OpenSSL instructions.
 
Certificate Extraction Instructions – Windows
4. Once the client receives the email from Trustwave, download the client certificate from the Trustwave Portal. 
5. Create an MMC Snap-in for Managing Certificates on the first Windows system where the SSL certificate is installed.
  • Start > run > MMC
  • Go into the Console Tab on the server, then navigate to File > Add/Remove Snap-in

 

  • Click on Add > Click on Certificates and click on Add

 

  • Choose Computer Account > Next

 

  • Choose Local Computer > Finish

  • Close the Add Standalone Snap-in window.
  • Click on OK at the Add/Remove Snap-in window.

6. Export/Backup Certificates to .pfx file

  • In MMC Double click on Certificates (Local Computer) in the center window.
  • Double click on the Personal folder, and then on Certificates.
  • Right click on the Certificate you would like to backup and choose > ALL TASKS > Export
  • Follow the Certificate Export Wizard to back up your certificate to a .pfx file.

  • You will receive a message > “The export was successful.” > Click OK
Certificate Extraction Instructions – Mac
  • Download .p7s file from TrustWave.
  • Open Applications>Utilities>Keychain access

  • Click the “+” sign on the top left corner and import the .p7s file
  • You should now see two line items, one contains a certificate and key pair, and the other contains the intermediate certificate
  • Right click on the certificate and click “Export” (You have the option of providing a password or not, completely at your discretion)
  • Repeat the same export for the key
  • You should now have two .p12 files (one certificate & one key)
  • Run the following commands to convert those .p12 file to the appropriate file:

openssl pkcs12 -in certificate.p12 -clcerts -nokeys -out certificate.crt

openssl pkcs12 -in privatekey.p12 -nodes -out privatekey.key –nocerts

  • Use those files to initiate an SSL connection.

After completing these steps the .pfx file backup is now saved in the location you selected during the aforementioned process and is ready to be moved or stored for your safe keeping.

You can import the PFX file into your application environment based on the OS used. Please see below import methods

  1. Windows/IIS – Import PFX file using Certificate wizard (MMC)
  2. Linux/Java – openssl commands or Keytool to import

Provided you have installed OpenSSL, execute the below commands.

Additionally, check out one of the 2 links for detail instructions:

Commands:

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

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

Links:

https://www.itsupportmiami.com/how-to-convert-a-pfx-to-a-seperate-key-crt-file/

https://support.securecdn.stackpath.com/hc/en-us/articles/230841967-Converting-pfx-to-a-crt-key-files

Make sure you are using .crt and .key files instead of a .pfx file when invoking calls from Google Postman. Check your Postman Settings in the top right hand corner of the console.

Verify that under the certificates tab, the Host, CRT File, KEY file, and Passphrase are all correct.

 

Also check the Proxy tab and confirm both the Global Proxy Configuration and Use System Proxy settings are OFF.