Nasdaq, Inc.

Contributor API (CAPI)

Powered by GIDS

Version 1.4
July 23, 2020
Contents
1 Introduction .................................................................................................................................... 3
2 Contributor API (CAPI) Level of Service ............................................................................................ 4
3 Connecting with the Service............................................................................................................. 4
4 Client Onboarding Process ............................................................................................................... 5
4.1 Signed Contract........................................................................................................................ 5
4.2 Setup and Testing .................................................................................................................... 5
4.3 Client Account Registration ...................................................................................................... 6
4.4 Financial Product Registration (FPR) ......................................................................................... 6
5 Daily Messages ................................................................................................................................ 6
5.1.1 Lite Service ....................................................................................................................... 6
5.1.2 Lite Plus Service ................................................................................................................ 6
5.1.3 Full Service ...................................................................................................................... 7
5.1.4 Daily Messages Timing...................................................................................................... 7
6 Contributor API Client Website ........................................................................................................ 8
6.1 Client Website – Reports .......................................................................................................... 9
7 Contributor API - Web ..................................................................................................................... 9
7.1 Connectivity (Authentication) ................................................................................................ 10
7.2 Failover/Recovery .................................................................................................................. 10
7.3 Field Format Convention ........................................................................................................ 11
7.4 Directory Message ................................................................................................................. 12
7.5 Tick Message.......................................................................................................................... 14
7.6 SOD/EOD Summary Message ................................................................................................. 16
7.7 Security Directory Message .................................................................................................... 19
7.8 SOD/EOD Weight Message ..................................................................................................... 21
8 Support ......................................................................................................................................... 23
9 Revision History ............................................................................................................................. 23

2
 1 Introduction
Contributor API powered by GIDS is a Third Party API service connecting firms with Nasdaq’s Global
distribution service. Firms will be able to send their Index and ETF data directly to Nasdaq Global Index
Dissemination Service (GIDS). The GIDS dissemination vehicle has a global reach within 37 countries
targeting millions of daily users across Television, Financial Web Portals, all major Market Data Vendors,
Sell-Side Banks, Buy-side firms and Retail Online Brokers. GIDS is a premier feed and today boasts over
40,000 Index and ETP valuation data points from Nasdaq and third party partners.

Reduce Cost and Bandwidth GIDS provides direct data recipients the opportunity to reduce network,
administrative and data center costs by taking one data feed, rather than many. It provides greater
dissemination frequency for select indexes, allowing for better trading performance and portfolio
valuations. GIDS also standardizes the message formats for index and ETF values to facilitate the
processing of cross-market data.
Benefits of GIDS include:
 Supports real-time ticks for global-listed index and derivative products
 Carries real-time ticks for select third party-provided index products
 Enables investors and traders to gauge the market’s performance and make buy and sell decisions
 Encourages widespread distribution of index and ETF data to the public via the Internet and other
electronic media throughout the world
 Enables investors and traders to identify the real-time value of an Index and ETF and to easily track
performance of investments
 Develops portfolio screens and other trading tools for index traders and ETF investors

Consolidated Data Messages

 Indexes:
o Price, Total and Net return values
o Equity, Fixed Income and Commodities
o Settlement values
o Currency Spot values for select instruments
o Daily security components data
o Start and End-of-day Summary data
 ETFs
o Intraday portfolio values (IPVs)
o Daily valuation information
o Start and end of day summary messages

GIDS operates 23 hours a day, six days a week (23/6), giving you access to real time index and ETP data
across the globe. The GIDS feed is live from 7:30 pm ET to the following day until 6:30 pm ET. During the
weekends, GIDS stops sending data on Fridays at 6:30 pm ET and resumes on Sunday at 7:30 pm ET.

3
2 Contributor API (CAPI) Level of Service
A. Lite Service (Index or ETF Intraday ticks)
 Registration
 Daily Directory Message
 Intraday Ticks

B. Lite Plus (Index or ETF Intraday ticks and Summary messages)

 Registration
 Daily Directory Messages
 Start of Day Summary
 Intraday Ticks
 End of Day Summary

C. Full Service (Index or ETF Intraday ticks, Summary messages, daily constituent and weightings)
 Registration
 Daily Directory Messages
 Constituents
 Start of Day Summary
 Intraday Ticks
 End of Day Summary
 *Full Service is limited to Index IP partners only

Dissemination Frequency
Contributor API provides a variety of dissemination frequencies some examples below:
 Once a day
 Every 15 minutes
 Once a minute
 Every 15 seconds
 Once a second

Dissemination Channels
 Global Index Dissemination Service – GIDS (Real Time and end of day Levels)
o Vendors, Buy Side and Sell Side firms

 Global Index FlexFile Delivery - GIFFD (Constituent and weights service)

o Custom Index entitlements and subscriptions
o *Only available for Index IP partners

3 Connecting with the Service

Contributor API Client Website

4
Interface for clients to manage their account, set up and maintain financial products, approve changes
and review any error messages, and get access to self-help functionality. The system will provide users
with a web page to help them diagnose any issues that they may run into while submitting financial
product data. All messages sent to the system via the Web API or Direct Connection will be displayed to
the user. All messages shown will be for the current business day.

Contributor API - Web

Contributor API is a web service that can be accessed programmatically. It is an interface that will use
the request-response pattern. The payload can be either XML or preferably JSON as it will keep the size
of the payload to a minimum. Contributor API will use the HTTP protocol to transmit the financial
product messages. Each message will be validated. If the validation is successful, then the message will
be submitted to the Third Party API Gateway. This option works best for low Bandwidth solution to send
daily messages and intraday ticks over the internet.

Contributor API gateway (peer to peer)

The Nasdaq Third Party Gateway is the portal for external customers and the Nasdaq Web API Interface
to send Financial Product messages into the Nasdaq environment for dissemination on Nasdaq feeds. It
provides external clients a dedicated port and application for the processing of their messages as
opposed to the shared interface within the Web API. This option is designed as a high bandwidth
solution.

4 Client Onboarding Process

4.1 Signed Contract

 New Firm/Users to fill in the CAPI Order Form and Application Form, including the following:
o Level of Service
o Dissemination Frequency
o Number of instruments
o Connection
o Commercials
o Agreed terms and conditions

4.2 Setup and Testing

 A test account will be set up for all firms
 Clients to register their Financial Product on the test environment

5
  Client to test their application against the test environment. Verify that all communication
(submitting daily product messages Directory, Security, Summary, Weights and Ticks) with
Contributor API is valid.
 Nasdaq administrator to verify and approve all test messages

4.3 Client Account Registration

 Nasdaq Administrators to set up new firm with production login credentials
 Multiple User accounts can be created under a given firm
 All firms will be set up with one API account and requested user accounts
o The application account will be used to submit data to the Contributor API and gateway
o The user accounts will be used to log into the website to manage products
 User accounts require two-factor authentication for added security

4.4 Financial Product Registration (FPR)

 Client to register financial products via the Application Form
 Nasdaq Administrators to review and approve the FPR
 Once approved client will not be able to make changes to the FPR
 When the FPR is marked live the user can begin to send daily messages (Directory, Security,
Summary, Weight and Ticks)
 Clients to set up and assign a holiday calendar to each product

5 Daily Messages
Clients must send the daily messages in the correct order to ensure these messages are disseminated via
GIDS or GIFFD. Anticipated message flow will be based on the client’s subscription of level of service
(Lite, Lite Plus, and Full Service)

5.1.1 Lite Service

Directory Tick
Message Message

The Lite Service message flow allows for a Directory Message followed by tick messages. The Directory
Message must precede any Tick message. Tick messages preceding a directory message will generate an
error response message and will be dropped/not processed. Dropped Tick Message(s) will require re-
sending after a successful directory message.

5.1.2 Lite Plus Service

Directory SOD Summary Tick EOD Summary

Message Message Message Message

6
The Lite Plus Service message flow allows for a Directory Message followed by an SOD Summary
Message, followed by Tick messages, followed by an EOD Summary Message.

The Directory Message must precede all other messages. Any other message types preceding a directory
message will generate an error response message and will be dropped/not processed. Dropped
SOD/EOD Summaries/ Tick Message(s) will require re-sending after a successful directory message.

5.1.3 Full Service

Security
Directory SOD Summary SOD Weight
Directory
Message Message Message
Message

EOD Weight EOD Summary Tick

Message Message Message

The Full Service message flow follows the same rules as the Lite Plus with some modifications:

1. Security Directory messages must precede SOD/EOD Weight messages. They can occur before
or after the Directory messages.
2. SOD/EOD Weight Messages must occur after the Directory message and the corresponding
SOD/EOD Summary Messages.
3. The number of SOD/EOD Weight messages must correspond to the Basket Count in the
SOD/EOD Summary Message. (Note 1)

Note 1: There are two basket count fields.

1. Directory Message Basket Count – this value is used on all reports and is the disseminated
number of constituents in the index
2. SOD/EOD Weight Message Basket Count – this value is used to identify the number of SOD/EOD
Weight messages which will be disseminated. This value will be used to determine that a
“complete” set of weighting messages have been received and will trigger GIFFD SOD/EOD
Weight file generation.

Please note all messages will be logged for only two days and Nasdaq will only log the first and last ticks.
*Full Service is restricted to Nasdaq IP Index partners.

5.1.4 Daily Messages Timing

 Time frame: All messages should be sent Sunday to Thursday between 7:30 pm ET and 6:28 pm
ET the following day (Monday through Friday). In other words, the only times that users should
not be sending messages is between 6:28 pm to 7:30 pm ET Monday through Friday, or anytime

7
 on Saturday, or on Sunday before 7:30 pm ET. During these times, the system is closed and
messages will be rejected.
 Order: Messages should follow the order in section 5. A Directory message is needed to receive
other messages. For example, for Lite Plus indexes, a SOD Summary Message is required to
receive the next message type, and so on.

Users can send messages at any time as long as these are received within the allowed time frame
and in the right order.

6 Contributor API Client Website

The registration form will need to be filled in by each firm requesting to send their index or ETP data to
Nasdaq via the follow link: [Link] This ensures the correct setup of the
service level. The fields prefixed with an asterisk * should be populated and represents a mandatory
field to be filled in. Once completed, the form will be verified and then set up.

Test link (mandatory for new clients): [Link]

Production link: [Link]

Financial Product Registration Table

Field Name Format Comment
*Trading Symbol Varchar(18) Output symbol (AAA)
The symbol the street recognizes for the product
*Client Input Symbol Varchar(18) Client Input symbol (AAA, I:AAA)
The symbol that is used internally by the customer and
will be sent on the feed. Preferred to be the same as
trading symbol but allows for flexibility for client on
feed.
*Name Varchar(50) Output Name (e.g. Nasdaq 100 Index)
*Type Varchar(2) Instrument Type
I - Index
E - ETF
*Dissemination Frequency Varchar(10) 1S - Every 1 second
15S - Every 15 seconds
60S - Every 60 seconds
ODOP - Once a day open
ODCL - Once a day close
ODID - Once a day intraday
*Base Currency Varchar(3) Currency of Index or instrument
Base Value Numeric(18,11) [Link]
Base Date Char(8) [Link]
Format: YYYYMMDD
*Tick Start Time Instrument Start Time. The time the first tick will be
sent. Select from the User Interface.
*Tick Stop time Instrument Stop Time. The time the last tick will be sent.
Select from the User Interface.
Market Cap Size Varchar(1) Instrument consider Large Cap, Mid Cap, or Small Cap
Calculation Method Varchar(3) Calculation Method

8
 Settlement Type Varchar(1) ‘O’, ‘C’, ‘M’, or Null
Asset Type Varchar(2) e.g. “EQ” = Equity
[see IIC spec for values **]
*Holiday Calendar ID The holiday schedule this product will follow. Select
from the User Interface
ETP Section
*IPV Symbol Varchar(18) Applicable to only ETF/ETP
Logic to say if it’s an ETF: [Link]
Industry MIC Varchar(4) Applicable to all products

*Net Asset Value Symbol Varchar(18) Applicable to only ETF/ETP

*Estimated Cash Per Creation Varchar(18) Applicable to only ETF/ETP

Unit Symbol
*Total Cash Per Creation Unit Varchar(18) Applicable to only ETF/ETP
Symbol
*Net Asset Dividend symbol Varchar(18) Applicable to only ETF/ETP
*Total Shares Outstanding Varchar(18) Applicable to only ETF/ETP
(TSO) Symbol

6.1 Client Website – Reports

Users will have access to the Contributor API Client Website. This website will provide access to reports,
which will provide a view to all messages sent, both invalid and successful. This will be a useful tool in
troubleshooting and viewing message traffic sent to Nasdaq.

7 Contributor API - Web

Contributor API Web is a web service that can be accessed programmatically. It is an interface that will
use the request-response pattern. The payload can be either XML or preferably JSON as it will keep the
size of the payload to a minimum. Clients must send their daily messages in the specific order set out in
section 5 to match the level of service. The web API will use the HTTPS protocol to transmit the daily
financial product messages.

To communicate in XML set the HTTP Accept Header to application/xml. To communicate in JSON set
the HTTP Accept Header to application/json. Default is JSON. The response will be in format that was
requested by the client (XML or JSON).

The clients will authenticate themselves against the Token endpoint. If the client’s username and
password is valid they will be returned a valid token that will be valid for the next 30 minutes. To obtain
the access token, a user will submit their username and password to the token endpoint and if valid
receive a token along with the expiration time. The expiration time will be defaulted to 30 minutes. The
response will be in format specified if successful.

The URL to connect to Web API is:

Test link (mandatory for new clients): [Link]

9
Production link: [Link]

7.1 Connectivity (Authentication)

[Link]

Request
HTTP Header
POST /token
Host: [Link]
Accept: application/x-www-form-urlencoded
HTTP Body
grant_type=password&username=myname&password=mypass
Response
If successful then the response will look like this:
HTTP Header
{"access_token": "h7YWiUDpYbTzHpjsmGcy9HLEO-6g-
ZtNQYPNMX3wXPvpFS4clAcVLrCytBLfKPrPYpVHYDtizHQ7lD0gk61ZX2qU1d9DGUrl61FSIxx-
9jboppRcfLxuIObt-MPV0C8hpl3rZHrj0UZWEGuXMq8PEdQtlwcvuQx1BrVIuMJ1vXRu-
EQxZv6LXfnuE04ToOnk",
"token_type": "bearer",
"expires_in": 1799 }
If the username or password is invalid you will get this response:
HTTP Header
HTTP/1.1 401 Unauthorized
Server: Microsoft-IIS/8.0
Date: Mon, 27 Jan 2014 02:13:26 GMT
{
"error": "invalid_grant",
"error_description": "The user name or password is incorrect
}

7.2 Failover/Recovery

Inbound messages are sent from the participant's application to the Contributor API host. They are not
sequenced. All inbound messages may be repeated benignly. This gives the client the ability to re-send
any inbound message if it is uncertain whether Nasdaq received it in the case of a connection loss or an
application error.

The idea of benign inbound message retransmission with end-to-end acknowledgement is fundamental
to Nasdaq's fail-over redundancy. If your connection ever fails, there is no way for you to know if
pending messages successfully made it over the link before the failure. A robust Contributor API client
can safely re-send any pending messages over a mirrored link without worrying about generating
duplicates. This applies to Nasdaq's disaster fail over capability as well; if Nasdaq ever needs to fail over
to the backup site, some messages sent at the moment of the failure may be lost. A robust application
can simply re-send the pending messages, making the fail over seamless to the end user.

All messages will be ASCII, Pipe Delimited, Tag Value Pairs. The specification for each of the messages
accepted by Contributor API will follow.

10
All inbound messages on a Contributor API port are processed sequentially. This guarantees that if two
messages are entered consecutively on the same connection, the first message entered will always be
accepted first.

7.3 Field Format Convention

Where used, the following data convention applies:

Format Description
Alpha(X) Indicates an Alpha of max size X
AlphaNum(X) Indicates an Alpha-Numeric of max size X
Numeric(X) Indicates an integer of max size X
Numeric(X, Y) Indicates a numeric values which are max of X characters long with Y
characters to the right of the decimal. The decimal point character is
NOT counted in X.
UTCDateTime YYYY-MM-DDTHH:MM:[Link].
All time values must be submitted in UTC time.
ISO 8601 format.

11
7.4 Directory Message
[Link]

A client will submit a directory message prior to any of the associated financial product related
messages (e.g. SOD/EOD Summary messages, SOD/EOD Weighting messages, Tick messages) at the start
of the business day.

The content of the directory message will be made up of the following fields (please note that the first
column indicates where the field should be filled in):

Field Key Format Comment

* = Mandatory
*Msg Type MsgType Alpha (20) FPODIR
*Product As Of Date OAODt Char(8) YYYYMMDD
*Client Input Symbol CFSYM AlphaNum(18) Must be the registered symbol what is ticking
Input symbol (e.g AAA)
*Holiday Flag OHF Alpha(1) Derived / Filled in by the Index Manager using the
calendar associated with the output. ‘Y’ if this is a
holiday, ‘N’ if it not. There will not be ticks on a
holiday.
Basket Count IBC Numeric(20) Basket Count - Active Constituents in the Index
NAV NAV Numeric(18,2) The ETF’s Net Asset [Link] for ETF/ETP
ECU ECU Numeric(18,2) Estimated cash per creation unit. Required for
ETF/ETP
Total Cash Amount TCA Numeric(18,2) Required for ETF/ETP
NAD NAD Numeric(18,2) Net Asset Dividend. Required for ETF/ETP
TSO TSO Numeric(18,2) Total Shares Outstanding. Required for ETF/ETP
Shares Per Creation SPCU Numeric(18,2) Shares Per Creation Unit applicable to only
Unit ETF/ETP

Example for Index:

MsgType=I|OAODt=20151109|CFSYM=TESTIDX|OHF=N|
Example for ETF:
MsgType=E|OAODt=20151109|CFSYM=TESTETF|OHF=N|NAV=27.34|TSO=123456789|SPCU=100

The client will submit one directory message at a time per financial product. The format of the message
can either be in XML or JSON format.

Request
HTTP Header
POST /directory
Host: [Link]
Accept: application/json
Authorization: Bearer h7YWiUDpYbTzHpjsmGcy9HLEO-6g-
ZtNQYPNMX3wXPvpFS4clAcVLrCytBLfKPrPYpVHYDtizHQ7lD0gk61ZX2qU1d9DGUrl61FSIxx-
9jboppRcfLxuIObt-MPV0C8hpl3rZHrj0UZWEGuXMq8PEdQtlwcvuQx1BrVIuMJ1vXRu-
EQxZv6LXfnuE04ToOnk
HTTP Body

12
 { "MSGTYPE":"FPODIR", "OAODT":"20150814", "ISYM":"SVAP", "OHF":"N", "IBC":"100" }
OR

{ "MSGTYPE":"FPODIR", "OAODT":"20150814", "ISYM":"SVAP", "OHF":"N", "IBC":"100", "NAV":"100.12",

"ECU":"1000.45", "TCA":"10.12", "NAD":"11.11", "TSO":"100000.00", "SPCU":"50.00" }

Response
If successful, then the response will be a status of 200.

HTTP Header
HTTP/1.1 200 OK
Server: Microsoft-IIS/8.0
Date: Mon, 8 Aug 2015 02:13:26 GMT
If there is one or more error, a HTTP status of 400 will be returned along with a list of keys and the error messages
to be returned.

HTTP Header
HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/8.0
Date: Mon, 27 Jan 2014 02:13:26 GMT
HTTP Body
[{“OAODT” : “Invalid date format”}, {“OHF” : “Invalid value”}]
OR
[{“OAODT” : “Invalid date format”}, {“OHF” : “Invalid value”}, {“NAV” : “Not a number”}]
OR

HTTP Header
HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/8.0
Date: Mon, 8 Aug 2015 02:13:26 GMT
HTTP Body
{“50” : “Missing product registration.”}

Validation

This message will be validated and either and ACK or NACK with Error message will be returned. Specific
validations will include;

1. Any required field not present

2. Any field not following the expected format
3. Symbol (CFSYM) not recognized for FIRM
4. Date (OAODt) not current business date
5. Holiday Flag (OHF) not presented

13
7.5 Tick Message
[Link]

Daily, the client will submit one or more tick messages per day based on the frequency specified during
the financial product registration.

The content of the tick message will be made up of the following fields:

Field Key Format Comment

* = Mandatory
*Msg Type MsgType Alpha(50) ‘TICK’
*Client Input Symbol CFSYM AlphaNum(18) Client input symbol used by their internal
system.
*Tick Num OTkNum Numeric(19) # ticks calculated
This number starts at 1 for every product at
the beginning of the session. The final
number represents the total number of
ticks sent to the Contributor API sytem.
*Tick Value OTkV Numeric(18,11)
*Tick Tm OTkTm UTCDateTime YYYY-MM-DDTHH:MM:[Link]. All time
values must be submitted in UTC time. ISO
8601 format.
Net Change OTkNCh Numeric(18,11)
Net Change Dir OTKNcd AlphaNum (1) + or – to indicate a change, or an ASCII
space to indicate no change
Market Value OTkMV Numeric(38,16) Market Value associated with this tick
Divisor OTkDiv Numeric(38,16) Divisor associated with this tick
High Tick Value OTkHV Numeric(18,11) The highest value during the day.
Low Tick Value OTkLV Numeric(18,11) The lowest value during the day.
Net Change Percent OTkNChP Numeric(19,8) Percent Change from SOD position

The client will submit a tick message at a specified interval. This interval is defined at the product
registration level. The format of the message can either be in XML or JSON format.

Request
HTTP Header
POST /tick
Host: [Link]
Accept: application/json
Authorization: Bearer h7YWiUDpYbTzHpjsmGcy9HLEO-6g-
ZtNQYPNMX3wXPvpFS4clAcVLrCytBLfKPrPYpVHYDtizHQ7lD0gk61ZX2qU1d9DGUrl61FSIxx-
9jboppRcfLxuIObt-MPV0C8hpl3rZHrj0UZWEGuXMq8PEdQtlwcvuQx1BrVIuMJ1vXRu-
EQxZv6LXfnuE04ToOnk
HTTP Body
{ "MSGTYPE":"TICK", "ISYM":"SVAP", "OTKNUM":"", "OTKV":"", "OTKTM":"", "OTKNCH":"", "OTKNCD":"",
"OTKMV":"", "OTKDIV":"", "OTKHV":"", "OTKLV":"", "OTKNCHP":"" }

Response
If successful, then the response will be a status of 200.
HTTP Header

14
 HTTP/1.1 200 OK
Server: Microsoft-IIS/8.0
Date: Mon, 8 Aug 2015 02:13:26 GMT

If there is one or more error, a HTTP status of 400 will be returned along with a list of keys and the error messages
to be returned.
HTTP Header
HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/8.0
Date: Mon, 8 Aug 2015 02:13:26 GMT
HTTP Body
[{“MSGTYPE” : “Invalid value”}]
OR

HTTP Header
HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/8.0
Date: Mon, 8 Aug 2015 02:13:26 GMT
HTTP Body

{“100” : “Directory message not sent.”}

or
{“101” : “Security directory message not sent.”}
or
[{“102” : “Missing security directory for AAPL”}, {“102” : “Missing security directory for NDAQ”}]

Validations

This message will be validated and either and ACK or NACK with Error message will be returned. Specific
Validations will include;

1. Any required field not present

2. Any field not following the expected format
3. Symbol (CFSYM) not recognized for FIRM
4. Date (OAODt) not current business date
5. Tick message for CFSYM precedes a Directory message for CFSYM
6. Tick messages exceed the allowable count for the Firm/Product

15
7.6 SOD/EOD Summary Message
[Link]

The client will submit Summary messages twice a day, once at the start of business day (SOD) and once
at the end of the business day (EOD). The SOD message can be sent during intraday if changes occur. If
the firm intends to send SOD/EOD Weighting Messages it is important that the ‘IBC’ field in this message
is filled with the number of weighting messages to be sent. The system will not default to the ‘IBC’ value
provided in the Directory Message.

The content of the summary message will be made up of the following fields:

Field Key Format Comment

* = Mandatory

*Msg Type MsgType Varchar(50) Must be FPOSUM

*Client Input Symbol CFSYM Varchar(18) Client input symbol used by their internal system.

*As Of Date IAODt Char(8) Business date

Format: YYYYMMDD

*SOD EOD Indicator ISODEOD Varchar(10) ‘SOD’ or ‘EOD’

Previous Close IPC Numeric(18,11) IF SOD then [Link] else NULL

Previous Divisor IPD Numeric(38,16) IF SOD then [Link] else NULL

Previous Market Value IPMV Numeric(38,16) IF SOD then [Link] else NULL

First Index Value IFirTV Numeric(18,11) First Index tick

If SOD then NULL else [Link]

Note: Only populated on EOD

First Index Value Time IFirTTm DateTime If SOD then NULL else [Link]; UTC

*Last Index Value IFinTV Numeric(18,11) If SOD then [Link] else [Link]

*Last Index Value Time IFinTTm DateTime If SOD then NULL else [Link]

High Index Value IHTV Numeric(18,11) If SOD then NULL else [Link]

High Index Value Time IHTTm DateTime If SOD then NULL else [Link]

LowIndex Value ILTV Numeric(18,11) If SOD then NULL else [Link]

16
 Field Key Format Comment

* = Mandatory

Low Index Value Time ILTTm DateTime If SOD then NULL else [Link]

Net Change INC Numeric(18,11) If SOD then NULL else [Link]

Net Change Direction INCD Varchar(1) If SOD then NULL else [Link]

Divisor IDiv Numeric(38,16) [Link]

Index Dividend Points IDP Numeric(18,11) Round([Link] /[Link], 11)

Basket Count IBC INT # of Weighting Messages sent in association with this
Index Summary message.

Total Shares ITS Numeric(38,16) TotalShares

Market Value IMV Numeric(38,16) If SOD then [Link] else

[Link]

Cash Dividend Market IDivMV Numeric(38,16) [Link]

Value

Net Change Percent INCP Numeric(19,8) If SOD then NULL else

NetChangePercent

Rolling 12 Month Net IR12NCP Numeric(19,8) Rolling12MonthChange /12MonthRollingIndexSODValue

Change Percent

Start of Year Net SOYNCP Numeric(19,8) Start of Year Change /[Link]

Change Percent

EOD Divisor EODDiv Numeric(38,16) EOD Divisor calculated by the calculator.

Request
HTTP Header
POST /summary
Host: [Link]
Accept: application/json
Authorization: Bearer h7YWiUDpYbTzHpjsmGcy9HLEO-6g-
ZtNQYPNMX3wXPvpFS4clAcVLrCytBLfKPrPYpVHYDtizHQ7lD0gk61ZX2qU1d9DGUrl61FSIxx-
9jboppRcfLxuIObt-MPV0C8hpl3rZHrj0UZWEGuXMq8PEdQtlwcvuQx1BrVIuMJ1vXRu-
EQxZv6LXfnuE04ToOnk
HTTP Body
{ "MSGTYPE":"FPOSUM", "IAODT":"20150814", "ISODEOD":"SOD", "IPC":"", "IPD":"", "IPMV":"",
"IFIRTV":"", "IFIRTTM":"", "IFINTV":"", "IFINTTM":"", "IHTV":"", "IHTTM":"", "ILTV":"", "ILTTM":"", "INC":"",

17
 "INCD":"", "IDIV":"", "IDP":"", "IBC":"", "ITS":"", "IMV":"", "IDIVMV":"", "INCP":"", "IR12NCP":"",
"SOYNCP":"", "EODDIV":"" }

Response
If successful, then the response will be a status of 200.
HTTP Header
HTTP/1.1 200 OK
Server: Microsoft-IIS/8.0
Date: Mon, 8 Aug 2015 02:13:26 GMT
Date: Mon, 8 Aug 2015 02:13:26 GMT

If there is one or more error, a HTTP status of 400 will be returned along with a list of keys and the error messages
to be returned.

HTTP Header
HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/8.0
Date: Mon, 8 Aug 2015 02:13:26 GMT
HTTP Body
[{“IAODT” : “Invalid date format”}, {“ ISODEOD” : “Invalid value”}]
OR
HTTP Header
HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/8.0
Date: Mon, 8 Aug 2015 02:13:26 GMT
HTTP Body
{“100” : “Directory message not sent.”}

Validations
This message will be validated and either and ACK or NACK with Error message will be returned. Specific
Validations will include;
1. Any required field not present
2. Any field not following the expected format
3. Symbol (CFSYM) not recognized for FIRM
4. Date (OAODt) not current business date
5. SOD/EOD Summary message for CFSYM precedes a Directory message for CFSYM

18
7.7 Security Directory Message
[Link]

The client will submit security message(s) at the start of the business day. Requires one message per
security expected to be included in corresponding SOD/EOD Weight messages.

The content of the security message will be made up of the following fields:
Field Key Format Comment
* = Mandatory
*Msg Type MsgType Alpha (50) ‘SECDIR’

*Security ID SID Numeric(20,0) Must have a unique identifier

*SecurityAsOfDate SAODt Char(8) YYYYMMDD

*Security Symbol SSym AlphaNum(18) Unique identifier of the index security assigned by
its Exchange or other marketplace.

*Security Name SNm AlphaNum(50) Name of Security

Currency Code SCurCD Alpha(3) ISO 4217 Alphabetic Code

ISIN SISIN AlphaNum(12) ISO 6166 ISIN Code

Bloomberg ID SBbgID AlphaNum(12)

SEDOL SSedol AlphaNum(7)

MIC SMIC Alpha(4) ISO 10383 MIC Code

The client will submit a list of security messages where each security message will represent a security
that belongs to the universe of indexes. The format of the message can either be in XML or JSON format.

Request
HTTP Header
POST /security
Host: [Link]
Accept: application/json
Authorization: Bearer h7YWiUDpYbTzHpjsmGcy9HLEO-6g-
ZtNQYPNMX3wXPvpFS4clAcVLrCytBLfKPrPYpVHYDtizHQ7lD0gk61ZX2qU1d9DGUrl61FSIxx-
9jboppRcfLxuIObt-MPV0C8hpl3rZHrj0UZWEGuXMq8PEdQtlwcvuQx1BrVIuMJ1vXRu-
EQxZv6LXfnuE04ToOnk
HTTP Body
{ "MSGTYPE":"SECDIR", "SID":"12345", "SAODT":"20150814", "SSYM":"NDAQ", "SNM":"Nasdaq, Inc.",
"SCURCD":"USD", "SISIN":"US12345", "SBBGID":"", "SSEDOL":"12345", "SMIC":"XNAS" }

Response
If successful, then the response will be a status of 200.

19
 HTTP Header
HTTP/1.1 200 OK
Server: Microsoft-IIS/8.0
Date: Mon, 8 Aug 2015 02:13:26 GMT

If there is one or more error, a HTTP status of 400 will be returned along with a list of keys and the error messages
to be returned.

HTTP Header
HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/8.0
Date: Mon, 8 Aug 2015 02:13:26 GMT
HTTP Body
[{“SAODT” : “Invalid date format”}, {“SCURCD” : “Invalid value”}]
OR

HTTP Header
HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/8.0
Date: Mon, 8 Aug 2015 02:13:26 GMT
HTTP Body
{“100” : “Directory message not sent.”}

Validations

This message will be validated and either and ACK or NACK with Error message will be returned. Specific
Validations will include;

1. Any required field not present

2. Any field not following the expected format
3. Symbol (CFSYM) not recognized for FIRM
4. Date (OAODt) not current business date
5. Tick message for CFSYM precedes a Directory message for CFSYM
6. Tick messages exceed the allowable count for the Firm/Product

20
7.8 SOD/EOD Weight Message
[Link]

The client will submit a set of weighting messages for every financial product. The set will be made up of
each security in the basket of that financial product. The SOD message can be sent during intraday if
changes occur. These messages will also be used for restatements for previous days.

The content of the weight message will be made up of the following fields:

Field Key Format Comment

* = Mandatory
*Msg Type MsgType Varchar(50) ‘FPOWGT’
*Client Input Symbol CFSYM Varchar(18) Index Symbol
*Basket Of Date BAODt Char(8) The business date
YYYYMMDD
*SOD EOD Indicator BSODEOD Varchar(10) ‘SOD’ or ‘EOD’
*Security ID BSID Numeric(20,0) Must tie to a SID from the Security Spin
*Basket State BSTATE Varchar(1) Status of the Constituent (‘A’, ‘I’ or ‘D’) (active,
inactive or deleted) (I and D state items are
included for one day when the state is
changed)
*Constituent Price BPrc Numeric(19,8)

Market Value BMV Numeric(38,16)

Number Of Shares BShrs Numeric(38,16)
Weight BWght Numeric(38,16) If SOD then
[Link]/[Link] * 100
Else [Link]/[Link] *
100
( rounded at 11)
Spot Rate BSr Numeric(19,8)
Free Float Factor BFFF Numeric(19,8)
TSO BTSO Numeric(38,16)
Cash Dividend Market BDivMV Numeric(38,16)
Value
Cash Dividend Price BDivPrc Numeric(19,8)

The client will submit a list of weight messages where each weight message will represent a security that
belongs to a financial product. The format of the message can either be in XML or JSON format.

Request
HTTP Header
POST /weight
Host: [Link]
Accept: application/json
Authorization: Bearer h7YWiUDpYbTzHpjsmGcy9HLEO-6g-
ZtNQYPNMX3wXPvpFS4clAcVLrCytBLfKPrPYpVHYDtizHQ7lD0gk61ZX2qU1d9DGUrl61FSIxx-
9jboppRcfLxuIObt-MPV0C8hpl3rZHrj0UZWEGuXMq8PEdQtlwcvuQx1BrVIuMJ1vXRu-
EQxZv6LXfnuE04ToOnk

21
 HTTP Body
{ "MSGTYPE":"FPOWGT", "BAODT":"20150814", "BSODEOD":"SOD", "OID":"", "BSID":"", "BSTATE":"",
"BPRC":"", "BMV":"", "BSHRS":"", "BWGHT":"", "BSR":"", "BFFF":"", "BTSO":"", "BDIVMV":"",
"BDIVPRC":"", "SEID":"" }

Response
If successful, then the response will be a status of 200.
HTTP Header
HTTP/1.1 200 OK
Server: Microsoft-IIS/8.0
Date: Mon, 8 Aug 2015 02:13:26 GMT
If there is one or more error, a HTTP status of 400 will be returned along with a list of keys and the error messages
to be returned.

HTTP Header
HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/8.0
Date: Mon, 8 Aug 2015 02:13:26 GMT
HTTP Body
[{“BAODT” : “Invalid date format”}, {“ ISODEOD” : “Invalid value”}]
OR
HTTP Header
HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/8.0
Date: Mon, 8 Aug 2015 02:13:26 GMT
HTTP Body
{“100” : “Directory message not sent.”}
or
{“101” : “Security directory message not sent.”}
Or
[{“102” : “Missing security directory for AAPL”}, {“102” : “Missing security directory for NDAQ”}]

Validations

This message will be validated and either and ACK or NACK with Error message will be returned. Specific
Validations will include:
1. Any required field not present
2. Any field not following the expected format
3. Symbol (CFSYM) not recognized for FIRM
4. Date (OAODt) not current business date
5. SOD/EOD Weighting message for CFSYM precedes a Directory message for CFSYM
6. SOD/EOD Weighting message for CFSYM precedes a SOD/EOD Summary message for CFSYM
7. SOD/EOD Summary message Basket Count for CFSYM is 0 or is lower than the current count of SOD/EOD
Weighting message (e.g. do not send more weighting messages than indicated by the Basket Count in the
Summary message for this CFSYM).

22
 8 Support
If you have any questions about this specification, please email the CAPI Operations team. We also
welcome suggestions for new features or improvements.

9 Revision History

Version Date Change

1.0 November 30, 2015 First Release
1.1 December 08, 2017 Updated the HTTP headers from Authentication to Authorization
1.2 January 26, 2018 Added root URLs for the Web API services and added additional
information for supporting JSON and XML
1.3 June 22, 2018 Added additional comment to OTKNUM field on the Tick message
1.4 June 19, 2020  Minor document clean up and updated support contact
information
 Field lengths were updated to match the GIDS specification.

© Copyright 2020, Nasdaq Inc. All rights reserved.

23