To access State Street API, you will need to request a Access Token using your OAuth 2.0 Client Credentials. This process follows RFC 6749, Section 4.4.2.

As an example, an Access Token may be obtained and used to invoke Sample Transactions with cURL:

• Client Identifier: example_id
• Client Secret: example_secret

$ curl \
    --request "POST" \
    --header  "Accept: application/json" \
    --user    "example_id:example_secret" \
    --data    "grant_type=client_credentials" \
    --url     "https://api.statestreet.com/oauth/accesstoken"
{
    "access_token":"obAPdUGVlb8RCIQT7c7WR6P9zzzz",
    "scope":"read",
    "application_name": "65c652fe-2c5b-41d7-95ef-67fde1cd0000",
    "expires_in":"1799",
    "refresh_count" :"0",
    "status":"approved",
    "token_type":"Bearer"
}

$ curl \
    --request       "GET" \
    --header        "Accept: application/json" \
    --oauth2-bearer "obAPdUGVlb8RCIQT7c7WR6P9zzzz" \
    --url           "https://api.statestreet.com/sampleTransactions/v1/transactions"

You may view application usage metrics for your Application registrations in the State Street Developer Portal. You may filter this view by time period to identify trends and instrument usage of State Street API services.

1. Navigate to My Apps
   • Click "View Details" for the Application you wish to view
2. On the top banner of the application, select the "Analytics" tab
3. Under "Filter" choose which metric to be displayed. Data available include:
   • Average Response Time
   • Max Response Time
   • Min Response Time
   • Message Count
   • Errors
4. Select a time period to viewf
5. Click "Apply"

You may specify specific HTTP headers to facilitate reporting and debugging/tracing in all environments.

User-Agent
Identify you client application with a custom name and version, based on semantics established in RFC 9110, section 3.5.

Use this to measure actual usage of specific versions of the client application over time and facilitate upgrades.

X-Authenticated-User
Uniquely identify the user of your Application. Use this header to instrument user counts. If provided, this value is made available to the underlying State Street API Service and will be returned in the response if it is specified in the request.

This value is not used for authentication purposes.

X-Correlation-ID
Provide your own ID value in your request to facilitate full-stack debugging/tracing.

This value will be returned in the response, including in error responses, if it is specified in the request.

X-Authenticated-User
Uniquely identify the user of your Application. Use this header to instrument user counts.

Response returns value specified in request, if supplied.

X-Correlation-Id
Provide your own ID value in your request to facilitate full-stack debugging/tracing.

Response returns value specified in request, if supplied.

X-Eam-Trace-Id
A unique string identifying each request, assigned by State Street API. This value is used to coordinate full-stack tracing and precisely identify requests in support inquiries.

Users are advised to log this value and include it when making support requests. For support, email api-support@statestreet.com, call a Helpdesk, or engage your Client Service Manager.

State Street API returns standard HTTP response status codes based on RFC 9110. The following responses are typically supported:

Successful 2xx
RFC 9110, section 15.3

• 200 OK
• 201 Created
• 202 Accepted
• 204 No Content

Client Error 4xx
RFC 9110, section 15.5

• 400 Bad Request
• 401 Unauthorized
• 404 Resource not found
• 405 Method Not Allowed
• 409 Conflict
• 410 Gone
• 413 Payload Too Large
• 429 Too Many Requests

Server Error 5xx
RFC 9110, section 15.6

• 500 Internal Server Error
• 502 Bad Gateway
• 503 Service Unavailable
• 504 Gateway Timeout

State Street API services that accept or return PII do so only within the content body.

Your Application SHOULD NOT send personally identifiable information (PII) data in the URL (as part of path or query string) or HTTP headers.

Transmission of PII must comply with the negotiated terms, local requirements, and Terms & Conditions.

To ensure your Application is compatible with future enhancements to State Street API, your Application must safely ignore unknown fields in any returned object.

State Street API services may add fields to responses through minor enhancements (e.g. a v1.0.0 service may add a field when publishing v1.1.0). Backwards-incompatible (breaking) changes are always assigned a new major version number (e.g. v1.0.0 might be refactored as v2.0.0).

Do not rely on the order in which data appears in responses returned as JSON. The order of fields is precisely defined in XML responses, but keys in JSON objects are unsorted.

When supported by the service, clients may request that data be returned in a specific order. For example, a service may support the use of the orderBy query string parameter to specify the order of fields and expect the response to be formatted as requested.

Responses may sometimes be returned as a series partial sets. You may influence the behavior of State Street API services that offer following parameters to control the size of paginated responses:

• limit the number of records to return per page. If this value is zero, negative or unspecified, then a default page size will be used.
• offset indicates the number of records to skip.
• pageToken contains an opaque string supplied in the nextPageToken of the most recent response, which indicates the next page of data to return (a null nextPageToken value in a response indicates no additional results are available).

Please note that results, including record counts, may change across calls as underlying data changes.

Filtering behavior is documented in the specification for each State Street API service.

You are encouraged to use service specifications (OpenAPI) directly.

Developers are free to generate bindings and libraries to suit their own development toolsets and practices.

Clients may request support for scheduled testing in UAT.

For support, email api-support@statestreet.com, call a Helpdesk, or engage your Client Service Manager.

State Street API services are labelled using a Major.Minor.Patch versioning scheme:

• Major version will increment in response to any breaking API change. When the major version number increments, this signals that support for previous major versions will be deprecated in the future.
• Minor version will increment when a service gains functionality without breaking existing functionality. The most recent Minor version for each Major version is always used.
• Patch version will increment when only documentation is enhanced, but no change is made to the underlying service.

Examples of a breaking change that would require publication of a new Major version:

1. Removal or renaming paths or request parameters
2. Change in behavior for an existing path
3. Change in response codes
4. Refactored response data format

There are three different stages in an the lifecycle of a State Street API service:

• Active: An active version is fully supported for usage by new and exisiting solutions. Developers should use only active APIs when building new apps.
• Deprecated: A deprecated version has been superseded by a newer version. New Application registrations may be denied access to deprecated APIs.
• Retired: A retired version is no longer supported. Any application using a retired version must migrate to an active version. State Street will reach out to users of deprecated versions to plan their migration to an active version ahead of version retirement.

These limits can be recognized by a 429 response code, which indicates that the caller has made too many calls. An example response is shown below.

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 5
{
    "error":  {
        "code": "EAM-2003",
        "message": "The app has made too many requests in the time period.",
        "traceId": "0123456789abcdef"
    }
}

Should these error appear, it is important to wait for the amount of time specified in a response with a Retry-After header before retrying the request.

For RESTful services, OpenAPI specifications corresponding to each published version are available on the State Street Developer Portal in the API Catalog.

Developers may download and use these specifications to develop and maintain their solutions over time. Developers may use specifications to generate interfaces, manage versions and compatibility across releases, etc.

For support, email api-support@statestreet.com, call a Helpdesk, or engage your Client Service Manager.