Web Services API 2.0

GlobalView Software, Inc -
MarketView Web Services API 2.0
© GVSI 2005-2009, Proprietary and Confidential

1 INTRODUCTION....................................................................................... 1
1.1 Scope ............................................................................................. 1
1.2 Intended Audience.......................................................................... 1
2 SYSTEM OVERVIEW ............................................................................... 2
2.1 API Architecture ............................................................................. 3
2.2 API Architecture Message Structure............................................... 4
2.3 Messaging Detail ............................................................................ 4
2.4 The Request String......................................................................... 5
2.5 Specifying Filters in the Request String (Conditions)...................... 6
2.6 The Response String ...................................................................... 7
2.7 Values in the Request and Response String .................................. 8
2.8 The “Raw” XML .............................................................................. 8
2.9 The Data Stores ........................................................................... 11
2.10 Correction Data Stores ................................................................. 11
2.11 MarketView Web Services URL.................................................... 11
2.12 Symbols, Aliases & Continuous.................................................... 11
2.13 Authentication Issues ................................................................... 13
2.14 Addressing Error Conditions/Error Codes .................................... 13
3 MARKETVIEW WEB SERVICES API ..................................................... 15
3.1 MetaData Retrieval ....................................................................... 15
3.1.1 getInstrumentList ............................................................... 15
3.1.2 getInstrumentRootList ........................................................ 18
3.1.3 getInstrumentMetaData ..................................................... 20
3.1.4 getCurrencyList.................................................................. 23
3.1.5 getExchangeList ................................................................ 25
3.1.6 getUserDefinedInstrumentList ........................................... 27
3.1.7 getOptionRootInstruments ................................................. 29
3.1.8 getVersion.......................................................................... 31
3.1.9 getSymbolTree .................................................................. 32
3.2 Realtime and Historical Price API Methods .................................. 36
3.2.1 getDailyPrices .................................................................... 36
3.2.2 getTradePrices .................................................................. 39
3.2.3 getLiveQuotePrices ........................................................... 42
i
TABLE OF CONTENTS
(continued)
Page
3.2.4 getIntradayPrices ............................................................... 45

3.2.5 getNews ............................................................................. 48
3.2.6 getPriceCorrections ........................................................... 51
3.2.7 getForwardCurve ............................................................... 54
3.3 Data Quality API Methods ............................................................ 56
3.3.1 Are{dataSet}PricesAvailable .............................................. 56
3.3.2 are{dataSet}PricesInAbsoluteThreshold ............................ 59
3.3.3 are{dataSet}PricesInPercentileThreshold .......................... 63
3.4 Data Import Methods .................................................................... 66
3.4.1 importInstrumentPrice ........................................................ 67
3.4.2 importInstrumentMetaData ................................................ 69
Frequently Asked Questions ........................................................ 71
ii
1 Introduction
MarketView provides customers with access to many data sets, including detailed
historical price data. The system makes available an Application Program Interface (API)
as detailed in this document.
1.1 Scope
This document provides methods definition, sample code, and all technical details
necessary for customers to develop applications that interface with the MarketView ASP
system.
1.2 Intended Audience
This document is intended for IT developers working for or on behalf of MarketView

customers.
© GVSI 2005-9, Proprietary and Confidential Page 1

2 System Overview
MarketView Web Services provides easy access to GlobalView’s Spot, Intraday, and
Historical Prices data sources, as well as Price Corrections and News, all delivered
through Web Services factoring. This gives you access to GlobalView’s realtime and
historical data from your custom applications.
Data Query Facilities
• Easy access to spot, intraday, and historical price datasets, through an easy-to-
use web-centric API.
• Conditional filters permit easy filtering for the desired data.
• Instrument metadata.
• Corrections from the exchange/data provider.
• News.
Data Quality Facilities
• Programmatically determine availability of price quotes

• Determine quality of price quotes by checking them against thresholds (which
may be expressed as either fixed amounts or percentages)
Data Import Facilities
• Set up intra-company data feeds for prices and news; the same data is available
for use by your MarketView clients.
• Monitor data imports for number of quotes poked; insertion errors.
Based on Industry Standards
• Uses industry-standard SOAP/XML API (Apache Axis.)

• Uses XML in both request and response, allowing for an easy-to-use and
expressive message payload.

2.1 API Architecture
Because all calls are expressed in standard Web Services Definition Language
(WSDL),you do not need proprietary software (neither DLLs nor JARs,) to access
MarketView data.
API User
XML
http://mvwebapi.gvsi.com/services/mt
Internet
External
GlobalView Network
MarketView Web Services
Permissions Data Data Data
Data Data Data

2.2 API Architecture Message Structure
The API is a set of SOAP/XML-based web services, exposed externally via a (HTTP) web
page. API users can request data by making SOAP requests.
API Message Format
SSL Encryption (HTTP secure transmission)
HTTP Envelope (text):
POST /services/mt
Host: mvwebapi.gvsi.com
Content-Type: application/soap+XML; charset="utf-8"
Content-Length: ....
SOAP Envelope (XML):
<env:Envelope XMLns:env="http://
www.w3.org/2003/05/soap-envelope" >
<env:Header>...
Data (XML):
<daily-
price><date>2005-04-
01...</daily-price>
2.3 Messaging Detail
All of the API methods are wrapped in a web services protocol within which a separate
policy handles exceptions relating to:
• User authentication,
• SOAP/XML message validation,
• Method “signature” validation,
• System availability,
• User (data entitlements) permissioning.
The response XML includes price data, a code and description to provide feedback to the
caller. Responses are as detailed as possible, providing feedback on an instrument-by-
instrument basis whenever possible. When a global error occurs, such as credential failure
or server error, a global response is returned. It should be noted also, a permission error
may be sent for one instrument if the user is a valid API user but not entitled to the
instrument requested.

MarketView software prevents concurrent use of software by the same user credentials.
MarketView Web Services preserves this limitation – it will “log off” users using the same
user account, from either MarketView or MarketView Web Services. It is to your
advantage therefore to procure separate accounts between your MarketView and
MarketView Web Services clients.
2.4 The Request String
The Request String is a parameter that is present in the majority of MarketView Web
Service’s API function calls. The contents of the string follow XML conventions, according
to the schema described in API_REQUEST.xsd. This allows you great flexibility in terms of
specifying which field(s) you want to query, for which instrument(s), given which
condition(s). Here is a breakdown the component sections of a sample Request String,
<API_REQUEST>
<INSTRUMENTS>
<INSTRUMENT INSTRUMENT_ID=”/CLV6” /> 1
<INSTRUMENT INSTRUMENT_ID=”/CLQ6” />
...
</INSTRUMENTS>
<INSTRUMENT_SEARCHES>
<INSTRUMENT_SEARCH INSTRUMENT_ID=”/CL*” />
2
...
</INSTRUMENT_SEARCHES>
<CONDITIONS
START_DATE=”2006-06-01T12:00:00Z” 3
END_DATE=”2006-07-01T12:00:00Z”
AGGREGATE_TYPE=”F”
/>
<TAGS>
<TAG TAG_NAME=”INSTRUMENT_ID” />
<TAG TAG_NAME=”CLOSE” />
<TAG TAG_NAME=”HIGH” /> 4
<TAG TAG_NAME=”TRADE_DATETIME” />
</TAGS>
</API_REQUEST>
Notes:
1. A data request comprises of a list of instruments, enclosed in-between two

<INSTRUMENTS> tags. You can request quotes for one-to-many instruments at
one time.
2. You can also search for instruments by passing wildcards in-between two
<INSTRUMENT_SEARCHES> tags. In a price quote request, one or the other
pair of tags must appear. Or, as in the sample above, both sets of tags may
appear in the same request.
3. The <CONDITIONS> tags allows you to set up filters on the returned data, to
narrow the range of returned data.
4. The <TAGS> tags allows you to specify the fields you want returned in response
to your query. In this example, MarketView Web Services will return the fields,
INSTRUMENT_ID, CLOSE, HIGH, and TRADE_DATETIME. If <TAGS> is not
specified, MarketView Web Services will return values for a default set of fields.

2.5 Specifying Filters in the Request String (Conditions)
<API_REQUEST>
<INSTRUMENTS>
<INSTRUMENT INSTRUMENT_ID=”/CLV6” />
<INSTRUMENT INSTRUMENT_ID=”/CLQ6” />
...
</INSTRUMENTS>
<INSTRUMENT_SEARCHES>
<INSTRUMENT_SEARCH INSTRUMENT_ID=”/CL*” />
...
</INSTRUMENT_SEARCHES>
<CONDITIONS
START_DATE=”2006-06-01T12:00:00Z”
END_DATE=”2006-07-01T12:00:00Z”
AGGREGATE_TYPE=”F”
/>
... Looking at the above request, you’ll see that we allow you specify a list of instruments by
their specific INSTRUMENT_IDs, but also allow you to simultaneously specify instruments
by wildcard masks. That collection of instruments are filtered through the CONDITIONS,
each of whom must be met.
Describing this through the metaphor of a SQL-language database, you can specify
queries like,
SELECT tag(s)
FROM GVSI_INFRASTRUCTURE
WHERE
(
( INSTRUMENT_ID = ‘id0’
OR INSTRUMENT_ID = ‘id1’
OR ...
OR INSTRUMENT_ID = ‘idx’)
OR
( INSTRUMENT_ID LIKE ‘pattern0’
OR INSTRUMENT_ID LIKE ‘pattern1’
OR ...
OR INSTRUMENT_ID LIKE ‘patternx’)
)
AND tag1 = ‘condition1’
AND tag2 = ‘condition2’
AND ...
AND tagx = ‘conditionx’;

Although describable in terms of a SQL database, keep in mind that our infrastructure is
tuned to be a ticker plant, not a general-purpose database. Specifically,
• Conditions can only be tested for equality.
• All conditions specified must be met for a record to match.
• We do however offer facilities for date range queries, using START_DATE and
END_DATE tags.
While you can use MarketView Web Services for data-mining queries, its underlying
infrastructure runs most efficiently when given specific queries.
2.6 The Response String
MarketView Web Services API functions universally return a string value. That string is
formatted in XML, according to the schema laid out in API_RESPONSE.xsd. Again, there
are several sections of the response string; here is a breakdown of them,
<?xml version="1.0" encoding="UTF-8"?> 1

<API_RESPONSE CODE="0" DETAILS="" >
<INSTRUMENTS>
<INSTRUMENT MID_POINT="58.450" MONEY_FLOW="N/A" 2
LAST="N/A" CONTRIBUTOR="N/A" LOW="57.40"
HIGH="59.50" AGGREGATE_TYPE="N/A"
EXCHANGE_IDENTIFIER="N/A" USAGE_HOUR="N/A" 3
TICK_TYPE="43" OPEN_INTEREST="114136"
EXCHANGE_CODE="N/A" VOLUME="130289"
INSTRUMENT_ID="/CLX6" OPEN="58.80"
TRADE_DATETIME="2006-10-18T12:00:00-0500"
CLOSE="57.65" TICK_COUNT="N/A"
TRADE_VOLUME="N/A" />
<INSTRUMENT MID_POINT="58.250" MONEY_FLOW="N/A"
LAST="N/A" CONTRIBUTOR="N/A" LOW="57.55"
HIGH="58.95" AGGREGATE_TYPE="N/A"
EXCHANGE_IDENTIFIER="N/A" USAGE_HOUR="N/A"
TICK_TYPE="0" OPEN_INTEREST="69162"
EXCHANGE_CODE="N/A" VOLUME="567"
INSTRUMENT_ID="/CLX6" OPEN="58.35"
TRADE_DATETIME="2006-10-19T12:00:00-0500"
CLOSE="58.50" TICK_COUNT="N/A"
TRADE_VOLUME="N/A" />
</INSTRUMENTS>
</API_RESPONSE>
Notes:
1. All responses begin with the line, “API_RESPONSE”. If there is an error in

servicing the request, that is enumerated as the attribute CODE; DETAILS in turn
provides a textual description of the error.
2. As this function returns one-to-many instrument quotes, it is embedded within the
tags, <INSTRUMENTS>. All MarketView Web Services methods follow this
pattern: a plural form of the tag, followed by one-to-many singular-form tags
(INSTRUMENTS versus INSTRUMENT.)

3. Each individual quote in turm is embedded within the tag, <INSTRUMENT>. The
individual fields are treated as attributes of the INSTRUMENT tag.
2.7 Values in the Request and Response String
Within both the Request and Response strings, all attributes are expressed as string
values – e.g., they are wrapped in double-quotation marks (“”.)
1. Note that all arguments embedded in the Request String are handled as strings –
e.g., they are wrapped in double-quotation marks (“). A numeric value, therefore,
is expressed as VALUE=”5”, not VALUE=5.
2. All datetime fields are shown in ISO 8601 format. This means, expressed with the
format yyyy-mm-dd, followed by the letter ‘T’, then hh:mm:ss for the time
portion. The timezone immediately follows; expressed as an hour and minute
offset from UTC, with the format, ±hhmm . The abbreviation ‘Z’ may replace the
hour and minute offset, and denotes ‘+0000’.
• For example, Americas/Chicago (a.k.a., Central Standard Time, or CST)
would be denoted as “-0600”, as there are 6 hours difference between it
and the UTC. (Although, note that Daylight Savings Time affects the
offset from UTC.)
• Asia/Singapore (SGT) is expressed as “+0800”.
2.8 The “Raw” XML
MarketView Web Services is implemented in SOAP/XML using Apache Axis 1

Framework, running on a J2EE application server. We’ve discovered through previous
support requests that developers who are not familiar with this stack become confused
about how method arguments and the requestXML String are encoded and transmitted.
We’ve found that the best way to illustrate the conversation is to use a proxy that captures
and logs the packets. An example of such a proxy is tcpmon, which is part of the Apache
Foundation’s Axis 1 source distribution. Proxies such as tcpmon are very helpful for when
the dynamics of a conversation between the client are server are not understood.
Following is a sample incoming request, captured by tcpmon,

POST /services/mt HTTP/1.0

Content-Type: text/xml; charset=utf-8 1
Accept: application/soap+xml, application/dime, multipart/related,
text/*
User-Agent: Axis/1.2.1
Host: service.gvsi.com
Cache-Control: no-cache
Pragma: no-cache
SOAPAction: ""
Content-Length: 616
<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope

xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body><getInstrumentList 2
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<user xsi:type="xsd:string">test_user</user>
<password xsi:type="xsd:string">test_password</password> 3
<requestXML xsi:type="xsd:string"><API_REQUEST>
Notes: EXCHANGE_CODE="PLG" /></API_REQUEST>
<CONDITIONS
</requestXML></getInstrumentList></soapenv:Body></soapenv:Envelope>
1. Given that SOAP/XML is a protocol implemented on top of the HTTP stack, there 4
naturally is a HTTP header.
2. The method being invoked is “getInstrumentList”. This particular method
(documented in Section 3) requires that the user provide three parameters.
3. These parameters are “user”, ”password” and “requestXML”. The values for the
first two, “user” and “password”, establishes your authentication on MarketView
Web Services. HTTP protocol’s authentication, used to gain authorization to a
specific URI/URL, is not used.
4. The third parameter, “requestXML,” contains the body of the request, encoded in
XML. To facilitate this, the <, >, ’, “ and & characters in the string must be
escaped to their legal XML equivalents.

The response from MarketView Web Services, in turn, looks like,
HTTP/1.1 200 OK
X-Powered-By: Servlet 2.4; Tomcat-5.0.28/JBoss-3.2.7 (build: ←
CVSTag=JBoss_3_2_7 date=200501280217)
Content-Type: text/xml;charset=utf-8 1
Date: Wed, 01 Nov 2006 20:59:20 GMT
Server: Apache-Coyote/1.1
Connection: close
<?xml version="1.0" encoding="UTF-8"?>

<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<getInstrumentListResponse>
<getInstrumentListResponse xsi:type="xsd:string"><?xml
version="1.0" encoding="UTF-8"?> 2
<INSTRUMENTS>
<INSTRUMENT INSTRUMENT_ID="#AAAXS00"
CURRENCY_CODE="USD"
... etc ...

Notes:
1. Again, given as how SOAP/XML is implemented over HTTP/HTTPS, there is a
HTTP header at the beginning of the response.
2. The user invoked a service called “getInstrumentList”. It’s response is called
“getInstrumentListResponse”, which is encoded as an XML String. That is what
we refer to as the Response String – every method returns a Response String
(whose name follows the pattern ‘methodNameResponse’.) Note the requisite
escape-XML sequences <, ", et al, are present as well.
While understanding what the “raw” XML looks like is helpful, by no means do we
recommend that your application creates or parses messages at this low level. Use a Web
Services library that supports the SOAP/XML protocol. The Apache Foundation’s
(http://www.apache.org) Axis 1 can be used for your client applications. Microsoft’s Visual
Studio (2003 and above) also comes with the .Net Web Services API. Other toolkits exist,
targeting different development languages and environments.
While we don’t advocate any toolkit over the other, we’re most familiar with The Apache
Foundation’s Axis 1, in terms of being able to offer suggestions/support.

2.9 The Data Stores
GlobalView keeps several data stores for our pricing data.

• The Trade data store holds Historical tick data
• LiveQuote keeps the lastmost pricing data for a given symbol.
• Daily is different from Intraday how?
• As there are major differences between ISO (electricity-related) instruments and
other energy instruments, we keep those price quotes in a separate datastore,
with Daily and Hourly striping.
2.10 Correction Data Stores
From time to time, the exchange or data vendor may issue corrections to symbol quotes.
Often, the price is corrected, although other fields in the price quote could be corrected.
We handle corrections by,
• Updating the primary data stores, so you’ll receive the corrected field(s) if you
execute a query.
• Updating a correction data store, that keeps the trade date corrected, as well as
the date the correction was issued.
• As ISO symbols are different from other symbols, we keep their corrections in a
different data store than other symbols’ corrections.
2.11 MarketView Web Services URL
MarketView Web Services is hosted from URL,
2.12 Symbols, Aliases & Continuous
When dealing with future contracts, you have to be aware that contracts (frequently)
expire on a monthly basis. This necessitates that you know the exchanges’ symbology,
expiration dates, and be prepared to change your queries several times during the month.
To address this inconvenience, MarketView Web Services supports rolling symbol aliases.
To illustrate, let’s look at NYMEX Crude Light Future contracts, whose root symbol is
“/CL”. You could reference a specific contract by specifying its single-letter month
code/single-digit year code (as in /CLF07 for the January 2007 daily session contract,) but
specifying (and editing) the specific contracts you need is onerous and prone to mistakes.
Chances are your business analysts did not specifically want the January ’07 contract,
they wanted the front month’s contract. It just so happens that at a given time of the year,
the front month contract is the January ’07 contract. (But, later in the year, it will be the
February ’07 contract.)

We address this problem for you by providing rolling symbol aliases. These are
INSTRUMENT_IDs that contains the sequence “[num]” (squared brackets with a single-
digit.) The digit refers to how many months out from the current month’s Future Contract
you want to select. For example, assume it is January, and you want the contract that is
two months out. That would be the March contract. So, you should query for /CL[2]. If you
want the front month’s contract, that would be /CL[0]. The symbols are the concatenated
by using the root symbol (i.e, /CL) and square brackets with the month offset between.
For NYMEX, a “G” is added before the root symbol to avoid symbol conflicts.
The flipside, given that you ask for a symbol by its rolling symbol alias, how do you know
that /CL[0] refers to /CLF07? The “Actual” contract’s symbol has been mapped to the
UNDERLIER tag, which MarketView Web Services can return for you in your requests.
NYMEX Alias Examples

Day Session Globex (ACCESS) Session
Front Month /CL[0] Front Month /GCL[0]
One Month Out /CL[1] One Month Out /GCL[1]
Two Months Out /CL[2] Two Months Out /GCL[2]
Three Months Out /CL[3] Three Months Out /GCL[3]
Four Months Out /CL[4] Four Months Out /GCL[4]
Five Months Out /CL[5] Five Months Out /GCL[5]
Six Months Out /CL[6] Six Months Out /GCL[6]
Seven Months Out /CL[7] Seven Months Out /GCL[7]
Eigh Months Out /CL[8] Eigh Months Out /GCL[8]
Nine Months Out /CL[9] Nine Months Out /GCL[9]
ICE Alias Examples

Day Session
Front Month 1tBRN[0]
One Month Out 1tBRN [1]
Two Months Out 1tBRN [2]
Three Months Out 1tBRN [3]
Four Months Out 1tBRN [4]
Five Months Out 1tBRN [5]
Six Months Out 1tBRN [6]
Seven Months Out 1tBRN [7]
Eigh Months Out 1tBRN [8]
Nine Months Out 1tBRN [9]
Continuous Symbology

A continuous symbol is one that is perpetual and builds a time-series based entirely on the front-month,
or any offset month, using the expiration dates of individual futures contracts to determine which data to
use for a given date in the time-series. These symbols use angle brackets (i.e., <>) with the month offset
in between to reference the month. For instance, front-month continuous for NYMEX Pit Session
Natural Gas is referenced by using the symbol “/NG<0>”, second-month is “/NG<1>” and so on. As with
alias symbols, to reference the Globex Session, put a “G” in front of the commodity code, “/GNG<0>”,
“/GNG<1>”, etc.
Continuous Symbology Examples

Day Session
Front Month ICE Brent Crude Oil 1tBRN<0>
One Month Out ICE Brent Crude Oil 1tBRN <1>
Front Month NYMEX Crude Oil /CL<0>
Three Months Out NYMEX Crude Oil Globex /CL<3>
2.13 Authentication Issues
Authentication in MarketView Web Services is established through the published methods

requiring user and password parameters. Based on those values, we establish what data
you can query (broken down at the exchange- and news data source-level.) We don’t use
HTTP’s authentication mechanisms (requiring username and password to access URLs.)
Which isn’t to say, you won’t be required to provide some sort of authentication to pass a
request.
Your company might have proxies set up, to enable HTTP access through your firewall.
Some proxies may require user name and password to “leave the building.” Being able to
access the MarketView Web Services’ web site through your web browser is not absolute
proof that your proxy does not require authentication; the browser may already be set up
by your IT staff.
Such issues are generally between your IT staff and yourself; we’re not in a position where
we can provide much help. Although we’ll note that the underlying HTTP protocol layer in
your SOAP/XML toolkit should have support for setting up authentication for any proxies
your firm may have, see it’s documentation for details. Axis’ tcpmon is an excellent tool to
determine how your corporate proxy works: it is “too simple”(or unencumbered) to have
your authentication pre-configured, such as your web browser would be. Place it in-
between your client and the corporate proxy.
2.14 Addressing Error Conditions/Error Codes
In Section 2.6, you saw that we return as the first line of the Response String a line that
looks like,
This is one place in the Response String where an error condition may be expressed to
you. The CODE attribute having any non-zero value is indicative of an error; the DETAILS

attempts to describe the error.If an error is reported here, then the request itself could not
be processed – e.g., you may have passed incorrect credentials.
The other sort of error that can be reported are errors at the per sub-request level. For
example, you queried for a number of symbols, but one of the symbols does not exist. You
would then see a response like,

<INSTRUMENTS>
<INSTRUMENT ERROR_CODE="120" ERROR_DESCRIPTION="Cannot permission request because no
exchange was found for '#JMD33497127'" INSTRUMENT_ID="#JMD33497127" … />
<INSTRUMENT INSTRUMENT_ID="#JMD33497125" … />
</INSTRUMENTS>
</API_RESPONSE>
Notice the INSTRUMENT with ERROR_CODE and ERROR_DESCRIPTION attributes.

These only appear on lines where an error occurred in the request. The next line’s
instrument had no errors, so the attributes you asked for are displayed.
(The error in the above example frequently happens because the symbol you are querying
for does not exist. A convenient way to check the validity of the
The API_REPONSE line will display values for CODE and DETAILS even if there is no
errors; the intra-response lines will display ERROR_CODE and ERROR_DESCRIPTION
only if there is an error. Regardless of where the error appears in the response, it follows
this error code mapping,
Code Description
0 Success
-10 General Error
-20 Authentication Error (invalid user name/password)
-30 Invalid Parameters in the web server request
-31 Invalid Instrument Attributes in the web server request
-32 Invalid Conditions Attributes in the web server request
-40 Instrument missing from response
7 Price and correction requests are limited to 10,000 instruments. Reduce
the number of instruments requested or narrow the instrument search
wildcard parameters.
8 Requested more than 50,000 price or correction price data elements.
Reduce the calendar range, the number of instruments requested, or
narrow the instrument search wildcard parameters.
120 You are not permissioned for the requested instrument(s). This can be
because a) you truly are not permissioned, or b) because the symbol is
misspelt, and there is no exchange associated with the symbol you asked
for.
130 A database error occurred.
136 The server is unable to retrieve the desired data because there it is unable
to locate a database for the requested data.
138 No instruments matched the query search pattern. Modify the search
parameter.
9001 Corrections are not available for the requested instrument.

3 MarketView Web Services API
MarketView Web Services API can be broken down into five categories of method calls.
These are,
• MetaData Retrieval
• Real & Historical Price Retrieval
• Data Quality
• Data Import/Upload
• “Utility” methods
This section provides a reference of those methods.
3.1 MetaData Retrieval
MetaData may be thought of as data concerning an instrument or instruments that are not
germaine to the realtime price or historical price data. Examples include, exchange where
traded, company name, currency, underlier security, etc. As this data is very static, we
often employ different infrastructure to store it than for historical or realtime prices. While
you generally can also receive metadata information from the price API methods,
understand that there’s an overhead of “joining” the query between two data stores.
3.1.1 getInstrumentList
Returns a list of instruments for the given exchange code, for which the user has query
permissions. The user can only specify one exchange code per invocation. The user can
get a list of “permissioned” exchange codes by issuing the “getExchangeList” method.
Arguments:
Type Name Description
String User API user identifier
String userPassword API user password (case-sensitive)
String requestXML Request String, formatted as per the schema at
API_REQUEST.xsd. This request must contain a
<CONDITIONS> clause specifying one (and only one)
EXCHANGE_CODE.
Condition Tags:
Name Description Required
EXCHANGE_CODE Must be specified. This is due to Yes
the high number of instruments that
may be returned (both in terms of
response time, and the length of the
returned string)
SECURITY_TYPE “F” for Futures; “FO” for Futures No
Options
UNDERLIER The underlying symbol. Either this or Yes, conditionally, refer to
OPTION_ROOT must appear. Description.

Note: When requesting “Options”, it

is best to use this condition with a
underlying futures contract and
make multiple queries to insure the
receipt of all option instruments.
This is because the is a maximum of
5000 records that can be returned in
a response from this method and
some option queries based on only
the commodity root can far exceed
this maximum number.
OPTION_ROOT The root symbol for options or Yes, conditionally, refer to
futures contracts. Either this or the Description.
UNDERLIER must appear. Note:
This is best used for requesting
“Futures” contracts by a commodity
root. If requesting “Options” use the
“UNDERLIER” condition for reasons
explained above.
SESSION Session the instrument trades on No
(“1”=Globex “2”=Day). Note: This
condition is used with future & option
type instruments.
INSTRUMENT_ID An exact instrument id or a pattern. No
Default Tags:
Name
INSTRUMENT_ID, SYMBOL_DESCRIPTION, CURRENCY, SECURITY_TYPE,
LOT_UNITS, EXPIRATION_DATE, EXCHANGE_CODE, CONVERSION_FACTOR,
SESSION, PUT_CALL, UNDERLIER
User-Specifiable Tags:
Name Description
N/A N/A
Response:
Type Description
String XML structured to contain a response for the request. It will identify each
available instrument. If a global error occurs, such as authentication, the
API_RESPONSE will only contain an error code and error description.

Example Request XML:
<API_REQUEST>
<CONDITIONS EXCHANGE_CODE="PLG" />
</API_REQUEST>
Example Response XML:
<?xml version="1.0" encoding="UTF-8" ?>

<API_RESPONSE CODE="0" DETAILS="">
<INSTRUMENTS>
<INSTRUMENT INSTRUMENT_ID="#AAAXS00" CURRENCY_CODE="USD" CONTRACT_EXPIRATION_DATE="N/A"
INSTRUMENT_TYPE="SP" EXCHANGE_CODE="PLG" LOT_UNITS="THM" />
<INSTRUMENT INSTRUMENT_ID="#AAAXU00" CURRENCY_CODE="USD" CONTRACT_EXPIRATION_DATE="N/A"
<INSTRUMENT INSTRUMENT_ID="#AAAXW00" CURRENCY_CODE="USD" CONTRACT_EXPIRATION_DATE="N/A"
<INSTRUMENT INSTRUMENT_ID="#AADNX00" CURRENCY_CODE="USD" CONTRACT_EXPIRATION_DATE="N/A"
INSTRUMENT_TYPE="SP" EXCHANGE_CODE="PLG" LOT_UNITS="GJ" />
… etc …
</INSTRUMENTS>
</API_RESPONSE>

Retrieves NYMEX Crude Light Pit Futures Symbols
<API_REQUEST>
<CONDITIONS EXCHANGE_CODE="NYM" OPTION_ROOT=”/CL” SESSION=”2” SECURITY_TYPE=”F” />
</API_REQUEST>

<INSTRUMENTS>
<INSTRUMENT INSTRUMENT_ID="/CLJ00" SYMBOL_DESCRIPTION="Apr 00 Light Crude Oil"
CURRENCY_CODE="USD" CONTRACT_EXPIRATION_DATE="2000-03-21" INSTRUMENT_TYPE="F" LOT_UNITS="BBL" />
… etc …
</INSTRUMENTS>
</API_RESPONSE>

3.1.2 getInstrumentRootList
Returns a list of root instruments and associated metadata for which the user has
permissions to query/view data. There is no RequestXML parameter.
Arguments:
Condition Tags:
Name Description
N/A There is no RequestXML parameter
Default Tags:
Name
INSTRUMENT_ROOT_NAME, INSTRUMENT_DESCRIPTION, CURRENCY,
SECURITY_TYPE, LOT_UNITS, EXPIRATION_DATE, EXCHANGE_CODE,
CONVERSION_FACTOR, SESSION, OPTION_ROOT
Name Description
N/A
Response:
Type Description

N/A

<INSTRUMENT_ROOTS>
<INSTRUMENT_ROOT INSTRUMENT_ROOT_NAME="/WS" EXCHANGE_CODE="NYM" CURRENCY_CODE="USD"
INSTRUMENT_DESCRIPTION="WTI Financial" LOT_UNITS="BBL" INSTRUMENT_TYPE="F"
CONVERSION_FACTOR="7.803" />
<INSTRUMENT_ROOT INSTRUMENT_ROOT_NAME="/PN" EXCHANGE_CODE="NYM" CURRENCY_CODE="USD"
INSTRUMENT_DESCRIPTION="Propane Gas" LOT_UNITS="GAL" INSTRUMENT_TYPE="F"
<INSTRUMENT_ROOT INSTRUMENT_ROOT_NAME="/PL" EXCHANGE_CODE="NYM" CURRENCY_CODE="USD"
INSTRUMENT_DESCRIPTION="NYMEX Futures" LOT_UNITS="TOZ" INSTRUMENT_TYPE="F"
<INSTRUMENT_ROOT INSTRUMENT_ROOT_NAME="1tBPM" EXCHANGE_CODE="IPE" CURRENCY_CODE="GBP"
INSTRUMENT_DESCRIPTION="ICE UK Baseload Electricity" LOT_UNITS="MWH" INSTRUMENT_TYPE="F"
<INSTRUMENT_ROOT INSTRUMENT_ROOT_NAME="1tGWM" EXCHANGE_CODE="IPE" CURRENCY_CODE="GBC"
INSTRUMENT_DESCRIPTION="ICE NBP Natrual Gas" LOT_UNITS="THM" INSTRUMENT_TYPE="F"
<INSTRUMENT_ROOT INSTRUMENT_ROOT_NAME="1tGAS" EXCHANGE_CODE="IPE" CURRENCY_CODE="USD"
INSTRUMENT_DESCRIPTION="IPE Futures" LOT_UNITS="MT" INSTRUMENT_TYPE="F"
… etc …
</INSTRUMENT_ROOTS>
</API_RESPONSE>

3.1.3 getInstrumentMetaData
Returns metadata associated with a given symbol. NOTE: due to infrastructure limitations,
this method services only one Instrument per invocation.
Arguments:
String requestXML Request String, formatted as per the schema at
API_REQUEST.xsd. The request must contain a
<INSTRUMENTS> clause, containing one (and only one)
INSTRUMENT_ID.
Condition Tags:
Name Description
N/A N/A
Default Tags:
Name
INSTRUMENT_ID, SYMBOL_DESCRIPTION, CURRENCY, SECURITY_TYPE,
LOT_UNITS, EXPIRATION_DATE, EXCHANGE_CODE, CONVERSION_FACTOR,
SESSION, PUT_CALL, UNDERLIER
INSTRUMENT_ID The security’s instrument Yes
identifier. If <TAGS> are
specified, this field must
appear in the request.
SYMBOL_DESCRIPTION The description of the tree Yes
node or individual symbol.
EXCHANGE_CODE The code that is used to Yes
group the symbol or tree
node for data access rights
per user.
EXCHANGE_CODE The code that is used to No
per user.
CURRENCY Code to represent quoted No
currency, if applicable.
Most symbol records will
have this field, node
records will not.
LOT_UNITS Code to represent quoted No
units of measure, if
applicable. Most symbol
records will have this field,
node records will not.
CONVERSION_FACTOR Value to represent a No


multiple for converting unit
of measure, if applicable.
Some symbol records will
records will not.
EXPIRATION_DATE Date representing last day No
of trading for instrument.
Exchange traded futures &
options records will have a
date, most other instrument
records will not and node
records will not.
SECURITY_TYPE Code representing the type No
of instrument in a record.
“F” represents Futures,
“FO” represents Options,
“IS” represents ISO and
“SP” represents spot or
end-of-day postings.
Response:
Type Description

<API_REQUEST>

<INSTRUMENTS>
<INSTRUMENT INSTRUMENT_ID="/NGZ06" />
</INSTRUMENTS>
</API_REQUEST>

<INSTRUMENTS>
<INSTRUMENT CONV_FACTOR="0.0" EXCHANGE_CURRENCY="USD" EXPIRATION_DATE="2006-11-28"
UNDERLIER="/NGZ06" INSTRUMENT_ID="/NGZ06" CURRENCY="USD" SYMBOL_DESCRIPTION="Dec 06
Natural Gas" OPTION_ROOT="/NG" PUT_CALL="U" LOT_UNITS="MMB" EXCHANGE_CODE="NYM"
SECURITY_TYPE="F" SESSION="1"/>
</INSTRUMENTS>
</API_RESPONSE>

3.1.4 getCurrencyList
Returns a list of currencies and associated metadata.
Arguments:
Condition Tags:
Name Description
N/A N/A
Name Description
N/A N/A
Response:
Type Description
available currency. If a global error occurs, such as authentication, the

N/A

<CURRENCIES>
<CURRENCY CURRENCY_CODE="USD" CURRENCY_DESCRIPTION="U.S. Dollar" />
<CURRENCY CURRENCY_CODE="CAD" CURRENCY_DESCRIPTION="Canadian Dollar" />
<CURRENCY CURRENCY_CODE="CHF" CURRENCY_DESCRIPTION="Swiss Franc" />
<CURRENCY CURRENCY_CODE="GBP" CURRENCY_DESCRIPTION="British Pound" />
<CURRENCY CURRENCY_CODE="EUR" CURRENCY_DESCRIPTION="Euro" />
<CURRENCY CURRENCY_CODE="JPY" CURRENCY_DESCRIPTION="Japanese Yen" />
<CURRENCY CURRENCY_CODE="SGD" CURRENCY_DESCRIPTION="Singapore Dollar" />
<CURRENCY CURRENCY_CODE="AUD" CURRENCY_DESCRIPTION="Australian Dollar" />
<CURRENCY CURRENCY_CODE="NZD" CURRENCY_DESCRIPTION="New Zealand Dollar" />
<CURRENCY CURRENCY_CODE="HKD" CURRENCY_DESCRIPTION="Hong Kong Dollar" />
<CURRENCY CURRENCY_CODE="DKK" CURRENCY_DESCRIPTION="Danish Krone" />
</CURRENCIES>
</API_RESPONSE>

3.1.5 getExchangeList
Returns a list of exchanges available in the infrastructure, and their associated metadata.
Arguments:
Condition Tags:
Name Description
N/A N/A
Name Description
N/A N/A
Response:
Type Description
available exchange. If a global error occurs, such as authentication, the

N/A

<EXCHANGES>
<EXCHANGES>
<EXCHANGE EXCHANGE_CODE="06A" EXCHANGE_DESCRIPTION="Platts Coal International"
EXCHANGE_EXPIRATION_DATETIME="2010-12-31T12:00:00Z" />
<EXCHANGE EXCHANGE_CODE="06B" EXCHANGE_DESCRIPTION="Platts Coal US"
<EXCHANGE EXCHANGE_CODE="06C" EXCHANGE_DESCRIPTION="Platts Natural Gas"
… etc …
</EXCHANGES>
</API_RESPONSE>

3.1.6 getUserDefinedInstrumentList
Returns a list of user-defined instruments. These are known as “User Defined Formulas” in
the MarketView client, and allow the user to map a formula to an instrument symbol. The
“instruments” returned by this call in turn can be used in subsequent methods in
MarketView Web Services. The process of defining these instruments are outside the
scope of Web Services; use the MarketView GUI application to create/edit your user
defined instruments.
Arguments:
Condition Tags:
Name Description
N/A N/A
Name Description
N/A N/A
Response:
Type Description

N/A

<USER_DEFINED_INSTRUMENTS>
<USER_DEFINED_INSTRUMENT USER_DEFINED_INSTRUMENT_NAME="@321SF"
USER_DEFINED_INSTRUMENT_DEFINITION="(((($SV(#PGADG00)*0.42)-
($SV(#PCAAD00)))*2)+(($SV(#POAEY00)*0.42)-$SV(#PCAAD00)))/3"
USER_DEFINED_INSTRUMENT_FOLDER="UserFolder" CURRENCY_SOURCE="" INSTRUMENT_DESCRIPTION="SF
321 Crack" LOT_UNITS="" SECURITY_TYPE="UDF" CONVERSION_FACTOR="1.0" PRECISION="13.0"
EXPIRATION_DATETIME="N/A" />
<USER_DEFINED_INSTRUMENT USER_DEFINED_INSTRUMENT_NAME="@FPL"
USER_DEFINED_INSTRUMENT_DEFINITION="$SV(#MPPEPJM05N05Q)+$SV(/NG[0])"
USER_DEFINED_INSTRUMENT_FOLDER="UserFolder" CURRENCY_SOURCE="USF"
INSTRUMENT_DESCRIPTION="Amerex with NG" LOT_UNITS="" SECURITY_TYPE="UDF"
CONVERSION_FACTOR="1.0" PRECISION="13.0" EXPIRATION_DATETIME="N/A" />
<USER_DEFINED_INSTRUMENT USER_DEFINED_INSTRUMENT_NAME="@PNWUNLCR"
USER_DEFINED_INSTRUMENT_DEFINITION="($SV(#PGADF00)*.42)-$SV(#PCAAD00)"
USER_DEFINED_INSTRUMENT_FOLDER=" UserFolder " CURRENCY_SOURCE=""
INSTRUMENT_DESCRIPTION="PNW UNL Crack" LOT_UNITS="" SECURITY_TYPE="UDF"
<USER_DEFINED_INSTRUMENT USER_DEFINED_INSTRUMENT_NAME="@SFLSDCR"
USER_DEFINED_INSTRUMENT_DEFINITION="($SV(#POAEY00)*.42)-$SV(#PCAAD00)"
USER_DEFINED_INSTRUMENT_FOLDER=" UserFolder " CURRENCY_SOURCE="IMF"
INSTRUMENT_DESCRIPTION="SF Low Sulphur Diesel Crack" LOT_UNITS="" SECURITY_TYPE="UDF"
<USER_DEFINED_INSTRUMENT USER_DEFINED_INSTRUMENT_NAME="@STRIPAMIGO"
USER_DEFINED_INSTRUMENT_DEFINITION="($SV(/NGU04)+$SV(/NGX04)+$SV(/NGZ04))/3"
USER_DEFINED_INSTRUMENT_FOLDER=" UserFolder" CURRENCY_SOURCE="" INSTRUMENT_DESCRIPTION="3
month strip" LOT_UNITS="" SECURITY_TYPE="UDF" CONVERSION_FACTOR="1.0" PRECISION="14.0"
EXPIRATION_DATETIME="N/A" />
</USER_DEFINED_INSTRUMENTS>
</API_RESPONSE>

3.1.7 getOptionRootInstruments
Returns a list of instruments associated with a root or an underlier symbol. This is useful if
you would like a list of current future contracts associated with Natural Gas, or options of
an underlying instrument. The CONDITIONS clause must appear in the request. Note: to
ensure responses with complete symbol lists, when requesting options, use the
“UNDERLIER” condition with a specific futures contract due to the 5000 symbol limit in a
singe request. For futures, you can use the “OPTION_ROOT” condition because the
returned list is hundreds of symbols (contracts) at the most. A user can use the response
from a futures chain request using “OPTION_ROOT” to get a list of non-expired
“UNDERLIER” symbols to issue option requests with.
Arguments:
String requestXML Request XML, with a requisite CONDITIONS clause.
Condition Tags:
Name Description
OPTION_ROOT The root symbol for option or futures contracts Either this or
UNDERLIER must appear.
UNDERLIER The underlying symbol. Either this or OPTION_ROOT must
appear.
SECURITY_TYPE “F” for Futures; “FO” for Options
SESSION Session the instrument trades on (“1”=Globex “2”=Day)
Name Description
N/A N/A
Default Tags:
Name
INSTRUMENT_ID, DISPLAY_CONTRACT_EXPIRATION_DATE,
SYMBOL_DESCRIPTION, EXCHANGE_CODE, CURRENCY, SECURITY_TYPE,
PUT_CALL, LOT_UNITS, CONVERSION_FACTOR, EXPIRATION_DATE,
UNDERLIER
Response:
Type Description

<API_REQUEST>
<CONDITIONS
OPTION_ROOT="/CL"
SECURITY_TYPE="F"
SESSION="2" />
</API_REQUEST>

<INSTRUMENTS>
<INSTRUMENT INSTRUMENT_ID="/CLF09" DISPLAY_CONTRACT_EXPIRATION_DATE="Dec-2010"
SYMBOL_DESCRIPTION="Dec 10 Light Crude Oil" CURRENCY="USD" SECURITY_TYPE="F" PUT_CALL="U"
SESSION=”2”CONVERSION_FACTOR=”7.803” LOT_UNITS=”BBL” EXCHANGE_CODE=”NYM”
EXPIRATION_DATE=”2008-12-19” UNDERLIER=”/CLF09”/>
EXPIRATION_DATE=”2009-12-21” UNDERLIER=”/CLF10” />
EXPIRATION_DATE=”2010-12-20” UNDERLIER=”/CLF11” /></INSTRUMENTS>
</API_RESPONSE>

3.1.8 getVersion
Returns the version of MarketView Web Services. This method exists to facilitate customer
support issues. It is the exception to the rule, as it returns ithe version identifier in the
DETAILS attribute of the API_RESPONSE.
Arguments:
N/A
Condition Tags:
Name Description
N/A
Name Description
N/A N/A
Default Tags:
Name
N/A
Response:
Type Description
String XML structured to contain a response for the request. The
API_RESPONSE’s error description field contains the version identifier.

Request XML
N/A
Response XML

<API_RESPONSE CODE="0" DETAILS="MarketView Web Services: 2.0.228-0 buildDate: Mon Dec 04
12:35:00 CST 2006 javacVersion: 1.4.2_10 javaClass.Ver: 48.0 buildHost: wchpbwh1 vcBuild-Label:
MarketView Web Services Version 2.0.228-0 vcRequest-Label: ProductionBuild" />
3.1.9 getSymbolTree
Returns Symbol Explorer Tree navigation records. This method is used to build a user
application symbol explorer where symbols available in the GlobalView Software system
are grouped into logical categories.
Arguments:
String requestXML Request XML. The request must contain a single
condition SYMBOL_TREE_PARENT_ID:
Condition Tags:
SYMBOL_TREE_PARENT_ID A integer that is associated with Yes
a branch in the symbol tree. For
the “root” level of the tree use
“1”, for subsequent requests,
use the desired symbol tree id
from result set of a
getSymbolTree method request.
PERMISSIONED_ONLY “1” to retrieve only items from No
the symbol tree which the
requesting User has access
rights for.; “0” for all items in the
symbol tree regardless if the
User has access rights to a
specific data set. If condition
isn’t specified, it will default to
“1”.
SYMBOL_TREE_ID The symbol tree integer that Yes
represents a level of the
navigation. This integer
can subsequently be used
by another getSymbolTree
method call to navigate the
tree down the desired node.
SYMBOL_DESCRIPTION The description of the tree Yes


node or individual symbol.
INSTRUMENT_ID The value for this field will Yes
be “0” if the record
represents a tree node, or a
varchar if the record
represents a symbol.
EXCHANGE_CODE The code that is used to No
per user.
CURRENCY Code to represent quoted No
currency, if applicable.
Most symbol records will
records will not.
LOT_UNITS Code to represent quoted No
units of measure, if
applicable. Most symbol
records will have this field,
node records will not.
CONVERSION_FACTOR Value to represent a No
multiple for converting unit
of measure, if applicable.
Some symbol records will
records will not.
EXPIRATION_DATE Date representing last day No
of trading for instrument.
Exchange traded futures &
options records will have a
date, most other instrument
records will not and node
records will not.
SECURITY_TYPE Code representing the type No
of instrument in a record.
“F” represents Futures,
“FO” represents Options,
“IS” represents ISO and
“SP” represents spot or
end-of-day postings.
Default Tags:
Name
SYMBOL_TREE_ID, SYMBOL_DESCRIPTION, INSTRUMENT_ID,
EXCHANGE_CODE, CURRENCY, LOT_UNITS, CONVERSION_FACTOR,
EXPIRATION_DATE, SECURITY_TYPE
Response:
Type Description
available instrument which has price corrections for the period specified. If
a global error occurs, such as authentication, the API_RESPONSE will

only contain an error code and error description.

Example Request XML: To Retrieve Root Level of Tree
<API_REQUEST>
<CONDITIONS SYMBOL_TREE_PARENT_ID="1" />
</API_REQUEST>

<SYMBOL_TREE>
<SYMBOL_TREE_NODE SYMBOL_TREE_ID="2" SYMBOL_DESCRIPTION="Amerex" INSTRUMENT_ID="N/A"
EXCHANGE_CODE="N/A" CURRENCY="N/A" LOT_UNITS="N/A" CONVERSION_FACTOR="N/A"
EXPIRATION_DATE="N/A" SECURITY_TYPE="N/A” />
<SYMBOL_TREE_NODE SYMBOL_TREE_ID="15953" SYMBOL_DESCRIPTION="Argus" INSTRUMENT_ID="N/A"
EXCHANGE_CODE="N/A" CURRENCY="N/A" LOT_UNITS="N/A" CONVERSION_FACTOR="N/A"
</ SYMBOL_TREE >
</API_RESPONSE>
Example Request XML: To Navigate the Tree Nodes
<API_REQUEST>
<CONDITIONS PERMISSIONED_ONLY="1" />
</API_REQUEST>

<SYMBOL_TREE>
<SYMBOL_TREE_NODE SYMBOL_TREE_ID="27098" SYMBOL_DESCRIPTION="Crude" INSTRUMENT_ID="N/A"
EXCHANGE_CODE="AEUC" CURRENCY="N/A" LOT_UNITS="N/A" CONVERSION_FACTOR="N/A"
<SYMBOL_TREE_NODE SYMBOL_TREE_ID="31122" SYMBOL_DESCRIPTION="Freight" INSTRUMENT_ID="N/A"
EXCHANGE_CODE="AEUC" CURRENCY="N/A" LOT_UNITS="N/A" CONVERSION_FACTOR="N/A"
</ SYMBOL_TREE >
</API_RESPONSE>
Example Request XML: Symbol Records returned from Symbol Tree Node
<API_REQUEST>
<CONDITIONS PERMISSIONED_ONLY="1" />
</API_REQUEST>

<SYMBOL_TREE>
<SYMBOL_TREE_NODE SYMBOL_TREE_ID="13782" SYMBOL_DESCRIPTION="CSX <1% SO2 12500 OTC month 1
- Washington close" INSTRUMENT_ID="#PA0002884LMM01" EXCHANGE_CODE="AUC" CURRENCY="USD"
LOT_UNITS="ST" CONVERSION_FACTOR="N/A" EXPIRATION_DATE="N/A" SECURITY_TYPE="SP” />
<SYMBOL_TREE_NODE SYMBOL_TREE_ID="13783" SYMBOL_DESCRIPTION="CSX <1% SO2 12500 OTC month 1
- Washington close" INSTRUMENT_ID="#PA0002884LMM01" EXCHANGE_CODE="AUC" CURRENCY="USD"
LOT_UNITS="ST" CONVERSION_FACTOR="N/A" EXPIRATION_DATE="N/A" SECURITY_TYPE="SP” />
</ SYMBOL_TREE >
</API_RESPONSE>

3.2 Realtime and Historical Price API Methods
MarketView Web Services provides realtime pricing data in Intraday and Daily strips. We
also keep LiveQuote (latest) data, and Historical Trades (ticks) data stores. In addition, we
also keep corrections issued by the exchange.
ISO data is fairly different from other securities, keeping disparate information such as
usage hour and date, voltage et al. As such, we keep them in separate datastores, in daily
and hourly ISO strips. We also keep ISO corrections.
Rounding out our offerings is News. As in MarketView, you can receive a collection of
news headlines, headlines with the story body, or headlines with a URL that a HTML
browser can load & display.
3.2.1 getDailyPrices
Returns daily strip prices from the intraday datastore, for a user-defined set of instruments,
covering a user-defined period of time. The user may specify which Tags (a.k.a., fields)
they want to have returned, or rely on the default set of Tags.
Arguments:
String UserPassword API user password (case-sensitive)
String requestXML Request XML. Any number of instruments can be
requested as shown below.
Condition Tags:
Name Description
INSTRUMENT_ID Does not appear in the <CONDITIONS> clause; instead appears
in <INSTRUMENTS> (specific instrument_id’s) or
<INSTRUMENT_SEARCHES> (wildcards)
START_DATE A date in the format, ‘YYYY-MM-DD’. If specified, then
END_DATE must be specified as well. Between the two fields,
creates a date-within-range query.
END_DATE A date in the format, ‘YYYY-MM-DD’. If specified, then
START_DATE must be specified as well, Between the two fields,
DAYS_BACK Expressed as an integer. Synonymous with the START_DATE/
END_DATE pair, with the proviso that END_DATE is the current
date.
RECORDS_BACK Expressed as an integer. System returns requested amount of
records provided a valid instrument has been requested and that
instrument has enough records to meet the full amount
requested.
AGGREGATE_TYPE Used for ISO data. 1 for PEAK, 2 for OFFPEAK, 0 (default) for
On-peak & Off-Peak combined.

Name Description
INSTRUMENT_ID The security’s instrument identifier. If
<TAGS> are specified, this field must
HIGH This session’s highest transaction
value
LOW This session’s lowest transaction
value
TRADE_DATETIME Date and Time of the last reported
Trade, in ISO format
OPEN This session's opening price
VOLUME Today's total trading volume
OPEN_INTEREST Open interest
CLOSE Settlement price. The official closing
price of a commodity
MID_POINT Midpoint
SYMBOL_DESCRIPTION Symbol description
Default Tags:
Name
INSTRUMENT_ID, TRADE_DATETIME, OPEN, HIGH, LOW, CLOSE,
OPEN_INTEREST, VOLUME, UNDERLIER
Response:
Type Description

<API_REQUEST>
<INSTRUMENTS>
<INSTRUMENT INSTRUMENT_ID="/CLZ06"/>
</INSTRUMENTS>
<CONDITIONS RECORDS_BACK=”5” />
</API_REQUEST>

<?xml version="1.0" encoding="UTF-8" standalone="no" ?><API_RESPONSE CODE="0" DETAILS="">
<INSTRUMENTS>
<INSTRUMENT CLOSE="58.58" HIGH="59.92" INSTRUMENT_ID="/CLZ06" LOW="58.25" OPEN="59.60"
TRADE_DATETIME="2006-11-13T12:00:00Z">
</INSTRUMENT>
</INSTRUMENT>
</INSTRUMENT>
</INSTRUMENT>
</INSTRUMENT>
</INSTRUMENTS>
</API_RESPONSE>

3.2.2 getTradePrices
Returns the Trade (a.k.a., Tick or Historical) prices for a user-defined set of
instruments, covering a user-defined period of time. The user may specify which Tags
(a.k.a., fields) they want to have returned, or rely on the default set of Tags. There is a
limit on tick data. Some instruments can trade hundreds of thousands of times per day
each creating a new record. Transferring this much data in a single request can be
stressful on the server application as well as the client side application. There is a limit
of 500,000 records max for any trade data request. An important note is the minute
referenced in the END_DATE is inclusive. This means ifor the example above, trades
will be returned through “2013-08-14 00:00:59”.
Arguments:
String requestXML Request XML. The request may contain a single
conditions clause identifying either a number of calendar
days back or a Date/time range.
Condition Tags:
Name Description
INSTRUMENT_ID Does not appear in the <CONDITIONS> clause; instead
appears in <INSTRUMENTS> (specific instrument_id’s) or
START_DATE A date in the format, ‘YYYY-MM-DD HH:MM:SS’. If specified,
then END_DATE must be specified as well. Between the two
fields, creates a date-within-range query.
END_DATE A date in the format, ‘YYYY-MM-DD HH:MM:SS’. If specified,
then START_DATE must be specified as well, Between the two
date.
Name Description
LAST Trade price or value
trade
TRADE_VOLUME Transactional volume of the last trade
price reported in TRDPRC_1
Default Tags:
Name
INSTRUMENT_ID, LAST, TRADE_DATETIME, TRADE_VOLUME, UNDERLIER

Response:
Type Description

<API_REQUEST>
<INSTRUMENTS>
<INSTRUMENT INSTRUMENT_ID="/GCL<0>" />
</INSTRUMENTS>
<CONDITIONS START_DATE="2013-08-13 23:45:00" END_DATE="2013-08-14 00:00:00" />
</API_REQUEST>
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>

<INSTRUMENTS>
<INSTRUMENT INSTRUMENT_ID="/GCL<0>" LAST="106.52" TRADE_DATETIME="2013-08-13T23:46:06Z"
TRADE_VOLUME="1" UNDERLIER="/CL"></INSTRUMENT>
…
</INSTRUMENTS>
</API_RESPONSE>

3.2.3 getLiveQuotePrices
Returns Livequote prices for a set of instruments, covering a user-defined period of time.
The user may specify which Tags (a.k.a., fields) they want to have returned, or rely on the
default set of Tags.
Arguments:
String requestXML Request XML. The request most contain a single
days back or a START_DATE and END_DATE:
Condition Tags:
Name Description
OPTION_ROOT Root for a Future or Forward type instrument. Used for Future
Chain requests
SECURITY_TYPE “F” for Futures, “FO” for Futures Options, “SP” for Spot, “S” for
Stock.
SESSION Trading Session used for Futures Chain requests, as follows:
NYMEX Pit = “2”
NYMEX Globex = “1”
All ICE = “2”
CBOT Pit = “2”
CBOT Globex = “1”
Others = “2”
UNDERLIER Used for futures options. A fully qualified futures contract (i.e.,
“/CLF14”.
Name Description
LAST Last trade price or value (most
recent)
NET_CHANGE Net change from previous close
HIGH This session's highest transaction
value
LOW This session's lowest transaction
value
trade
TRADE_DATE Date portion of TRADE_DATETIME
OPEN This session's opening price
BID Latest bid price
ASK Latest ask price

Name Description
BID_SIZE The quantity bid at the latest bid price
ASK_SIZE The quantity offered at the latest ask
price
TOTAL_VOLUME Today's total trading volume
OPEN_INTEREST Open interest

STRIKE Strike price (the price at which the
option is exercisable)
VOLUME Today's total trading volume
PUT_CALL P = put C = call U = underlier
TRADE_VOLUME Transactional volume of the last trade
price reported
BID_DATETIME Date of bid
ASK_DATETIME Date of ask
MID_POINT Midpoint
DAILY_AGGREGATE Daily Aggregate
PEAK_DAILY_AGGREGATE Daily Peak Aggregate
OFFPEAK_DAILY_AGGREGAGE Daily Off Peak Aggregate
CONVERSION_FACTOR Conversion Factor Value
LOT_UNITS Units Value
DISPLAY_CONTRACT_EXPIRATION_DATE Contract Delivery Month/Year
UNDERLIER Underlying security
CURRENCY Quoted Currency
SECURITY_TYPE Instrument Security Type
PREV_SETTLE_DATE Previous Settle Date
PREV_SETTLE Previous Settle Price
SETTLE_DATE Current Settle Date
SETTLE Current Settle Price
Default Tags:
Name
INSTRUMENT_ID, LAST, NET_CHANGE, HIGH, LOW, TRADE_DATETIME,
OPEN, BID, ASK, BID_SIZE, ASK_SIZE, COMPANY_NAME,
CONVERSION_FACTOR, LOT_UNITS,
DISPLAY_CONTRACT_EXPIRATION_DATE, EXCHANGE_CODE,
OPTION_ROOT, PUT_CALL, EXPIRATION_DATE, UNDERLIER, CURRENCY,
SECURITY_TYPE, PREV_SETTLE_DATE, PREV_SETTLE, SETTLE_DATE,
SETTLE
Response:
Type Description

Example: Instrument Request
<API_REQUEST>
<INSTRUMENTS>
<INSTRUMENT INSTRUMENT_ID="/CLZ09" />
<INSTRUMENT INSTRUMENT_ID="/NGZ09"/>
</INSTRUMENTS>
</API_REQUEST>

<INSTRUMENTS>
<INSTRUMENT LOW="5.750" PREV_SETTLE_DATE="2009-08-04" INSTRUMENT_ID="/NGZ09"
SYMBOL_DESCRIPTION="Dec 09 Natural Gas Futures" BID="N/A" SESSION="0" PREV_SETTLE="5.693"
HIGH="5.750" SETTLE_DATE="N/A" CONVERSION_FACTOR="3.55" LOT_UNITS="MMB" OPEN="5.750"
DISPLAY_CONTRACT_EXPIRATION_DATE="Dec-2009" LAST="5.750" SETTLE="N/A" ASK="N/A"
EXCHANGE_CODE="NYM" EXCHANGE_CURRENCY="USD" TRADE_DATETIME="2009-08-05T15:25:31Z"
OPTION_ROOT="/NG" PUT_CALL="U" EXPIRATION_DATE="2009-11-24" UNDERLIER="/NGZ09"
NET_CHANGE="0.057" CURRENCY="USD" SECURITY_TYPE="F" />
<INSTRUMENT LOW="74.85" PREV_SETTLE_DATE="2009-08-04" INSTRUMENT_ID="/CLZ09"
SYMBOL_DESCRIPTION="Dec 09 Light Crude Oil Futures" BID="N/A" SESSION="0"
PREV_SETTLE="75.62" HIGH="75.10" SETTLE_DATE="N/A" CONVERSION_FACTOR="7.803"
LOT_UNITS="BBL" OPEN="75.80" DISPLAY_CONTRACT_EXPIRATION_DATE="Dec-2009" LAST="75.10"
SETTLE="N/A" ASK="N/A" EXCHANGE_CODE="NYM" EXCHANGE_CURRENCY="USD" TRADE_DATETIME="2009-08-
05T15:02:38Z" OPTION_ROOT="/CL" PUT_CALL="U" EXPIRATION_DATE="2009-11-20"
UNDERLIER="/CLZ09" NET_CHANGE="-0.52" CURRENCY="USD" SECURITY_TYPE="F" />
</INSTRUMENTS>
</API_RESPONSE>
Example: Futures Chain Request
<API_REQUEST>
<CONDITIONS OPTION_ROOT="/CL" SECURITY_TYPE="F" SESSION="2" />
</API_REQUEST>
Returns a list of Pit traded, (SESSION=”2”), non-expired, Crude Futures.

3.2.4 getIntradayPrices
Returns intraday prices for a set of instruments, covering a user-defined period of time. The
user may specify which Tags (a.k.a., fields) they want to have returned, or rely on the
default set of Tags.
Arguments:
days back or a START_DATE and END_DATE. Any
number of instruments can be requested as shown below:
Condition Tags:
Name Description
AGGREGATE_TYPE 1 for peak; 2 for off-peak; 0 for all
BAR_INTERVAL Desired stripping, in minutes. Available are 1, 2, 3, 4, 5, 6, 7, 8,
9, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55, 60, 90, 120, 150, 180,
210, 240.
START_DATE must be specified as well, Between the two
date.
AGGREGATE_TYPE Used for ISO data. 1 for PEAK, 2 for OFFPEAK, 0 (default) for
On-peak & Off-Peak combined.
Name Description
LAST Last trade price or value
HIGH This session’s highest transaction
value
LOW This session’s lowest transaction
value
trade
TRADE_DATE Date portion of TRADE_DATETIME

Name Description
OPEN This session’s opening price
Default Tags:
Name
INSTRUMENT_ID, TRADE_DATETIME, OPEN, HIGH, LOW, LAST
Response:
Type Description
available instrument which has price corrections for the period specified. If a
global error occurs, such as authentication, the API_RESPONSE will only
contain an error code and error description.

Example XML Request:
<API_REQUEST>
<INSTRUMENTS>
<INSTRUMENT INSTRUMENT_ID="/CLT06" />
</INSTRUMENTS>
<CONDITIONS DAYS_BACK="2" BAR_INTERVAL=”5” />
</API_REQUEST>
Example Xml Response:

<INSTRUMENTS>
<INSTRUMENT LAST="N/A" LOW="56.30" HIGH="56.34" INSTRUMENT_ID="/CLT06" OPEN="56.30"
TRADE_DATETIME="2006-11-17T07:20:00-0600" />
TRADE_DATETIME="2006-11-17T07:25:00-0600" />
TRADE_DATETIME="2006-11-17T07:30:00-0600" />
TRADE_DATETIME="2006-11-17T07:35:00-0600" />
TRADE_DATETIME="2006-11-17T07:40:00-0600" />
TRADE_DATETIME="2006-11-17T07:45:00-0600" />
</INSTRUMENTS>
</API_RESPONSE>

3.2.5 getNews
Returns News articles. Articles either have their own body (e.g., the story,) or have a
reference to a web URL, to be used by a web browser. The user may specify which Tags
(a.k.a., fields) they want to have returned, or rely on the default set of Tags.
Arguments:
days back or a START_DATE and END_DATE.
Condition Tags:
Name Description
NEWS_SOURCE ID Code for News Source. Must appear
NEWS_DEPTH Not a condition per se, but controls the number of headlines
returned by query. Defaults to 300.
START_DATE must be specified as well, Between the two
date.
RECORDS_BACK Synomyn for DAYS_BACK
Other Tags Any of the User-Specifiable tags may appear as a CONDITION
tag, with the exception of NEWS_DATE and NEWS_TIME (Use
NEWS_DATETIME instead.)
Name Description
NEWS_DATETIME News Story DateTime
NEWS_DATE Date portion of NEWS_DATETIME
NEWS_TIME Time portion of NEWS_DATETIME
NEWS_HEADLINE Headline Text
NEWS_BODY Story Text
NEWS_STORY_NUMBER News Story ID Number
NEWS_SOURCE ID Code for News Source
NEWS_PAGE The News Page Number
NEWS_CATEGORIES News Category
NEWS_SYMBOL Instrument/Symbol associated with
Story
NEWS_KEYWORDS Keywords in the headlines
NEWS_SERVER_DATE Server News Story Date
NEWS_SERVER_TIME Server News Story Time
NEWS_HREF URL/URI pointing to the story on the
Web (used in conjunction with web

browser component.)
Default Tags:
Name
NEWS_DATETIME, NEWS_HEADLINE, NEWS_BODY,
NEWS_STORY_NUMBER, NEWS_SOURCE, NEWS_PAGE,
NEWS_CATEGORIES, NEWS_SYMBOL, NEWS_KEYWORDS,
NEWS_SERVER_DATE, NEWS_SERVER_TIME, NEWS_HREF
Response:
Type Description

<API_REQUEST>
<CONDITIONS NEWS_SOURCE="PGA" NEWS_PAGE="5" NEWS_DEPTH="5" />
<TAGS>
<TAG TAG_NAME="NEWS_HEADLINE" />
<TAG TAG_NAME="NEWS_BODY" />
<TAG TAG_NAME="NEWS_CATEGORIES" />
<TAG TAG_NAME="NEWS_SOURCE" />
<TAG TAG_NAME="NEWS_DATETIME" />
<TAG TAG_NAME="NEWS_PAGE" />
</TAGS>
</API_REQUEST>
Example XML Response:

<NEWS_ARTICLES>
<NEWS_ARTICLE NEWS_HEADLINE="5--European Products 352: HSFO TRADE: TOTSA BP 1 kt b/e 267"
NEWS_BODY="08Nov06/1145 am EST/1645 GMT
--1645 GMT: HSFO TRADE: TOTSA BP 1 kt b/e 267
--1644 GMT: HSFO TRADE: TOTSA-BP 1kt $267 FE
--1640 GMT: HSFO TRADE: CORRECTION Totsa to Statoil 1kt 267
b/e...SHOULD READ AS F/E DATES
--1634 GMT: ULSD TRADE: Litasco - Gunvor Intl French Winter
50ppm ULSD 20kts +/-10% sellers option, CIF Le Havre during
26-30 Nov, disch options Hamburg-Bordeaux + N Spain, otherwise
std flexi terms, BP GT+Cs, Dec IPE + 27
--1633 GMT: HSFO TRADE: (NON MOC) koch chemoil 5 kt 267 be
--1633 GMT: ULSD TRADE: MS - Totsa 20kt+/-10% s/o Flexi terms,
French Winter 50ppm ULSD, CIF Le Havre with Hbg/Bdx options,
18-22 Nov, Dec + 29
--1633 GMT: HSFO TRADE: (NON MOC) FAMM to Chemoil 1kt 267 b/e
--Platts Global Alert--
" NEWS_CATEGORIES="0005" NEWS_SOURCE="PGA" NEWS_DATETIME="2006-11-08T16:45:00-0600"
NEWS_PAGE="000005" />
<NEWS_ARTICLE NEWS_HEADLINE="5--European Products 352: HSFO TRADE: TOTSA BP 1 kt b/e 267"
NEWS_BODY="08Nov06/1145 am EST/1645 GMT
--1645 GMT: HSFO TRADE: TOTSA BP 1 kt b/e 267
--1644 GMT: HSFO TRADE: TOTSA-BP 1kt $267 FE
--1640 GMT: HSFO TRADE: CORRECTION Totsa to Statoil 1kt 267
b/e...SHOULD READ AS F/E DATES
--1634 GMT: ULSD TRADE: Litasco - Gunvor Intl French Winter
50ppm ULSD 20kts +/-10% sellers option, CIF Le Havre during
26-30 Nov, disch options Hamburg-Bordeaux + N Spain, otherwise
std flexi terms, BP GT+Cs, Dec IPE + 27
--1633 GMT: HSFO TRADE: (NON MOC) koch chemoil 5 kt 267 be
--1633 GMT: ULSD TRADE: MS - Totsa 20kt+/-10% s/o Flexi terms,
French Winter 50ppm ULSD, CIF Le Havre with Hbg/Bdx options,
18-22 Nov, Dec + 29
--1633 GMT: HSFO TRADE: (NON MOC) FAMM to Chemoil 1kt 267 b/e
--Platts Global Alert--
" NEWS_CATEGORIES="PG" NEWS_SOURCE="PGA" NEWS_DATETIME="2006-11-08T16:45:00-0600"
NEWS_PAGE="000005" />
</NEWS_ARTICLES>
</API_RESPONSE>

3.2.6 getPriceCorrections
Returns price corrections for normal (non-ISO) instruments. The user may specify which
Tags (a.k.a., fields) they want to have returned, or rely on the default set of Tags. NOTE:
due to infrastructure limitations, this method services only one Instrument per invocation.
The current architecture of corrections only returns the INSTRUMENT_ID, the

CORRECTION_DATETIME and the TRADE_DATETIME. It is up to the user to request
the history with the “getDailyPrices” method to get the corrected data for an
instrument/date returned from a “getPriceCorrections” query. In the Request, the
START_DATE and END_DATE conditions are compared to the
CORRECTION_DATETIME value.
Arguments:
Condition Tags:
Name Description
appears in <INSTRUMENTS> (specific instrument_id’s)
or <INSTRUMENT_SEARCHES> (wildcards)
END_DATE must be specified as well. Between the two
START_DATE must be specified as well, Between the
two fields, creates a date-within-range query.
DAYS_BACK Expressed as an integer. Synonymous with the
START_DATE/ END_DATE pair, with the proviso that
END_DATE is the current date.
RECORDS_BACK Synomyn for DAYS_BACK
Other Tags Any of the User-Specifiable tags may appear as a
CONDITION tag, with the exception of NEWS_DATE
and NEWS_TIME (Use NEWS_DATETIME instead.)
Name Description
INSTRUMENT_ID Instrument ID. Must appear
CORRECTION_DATETIME Date and time on which the correction
was made.
TRADE_DATETIME Date and time of the trade

Default Tags:
Name
INSTRUMENT_ID, CORRECTION_DATETIME, TRADE_DATETIME
Response:
Type Description

<API_REQUEST>
<INSTRUMENTS>
<INSTRUMENT INSTRUMENT_ID="#PHAJL00" />
</INSTRUMENTS>
<CONDITIONS START_DATE="2008-10-06" END_DATE="2008-10-06" />
</API_REQUEST>

<INSTRUMENTS>
<INSTRUMENT INSTRUMENT_ID="#PHAJL00" TRADE_DATETIME="2008-10-03T00:00:00Z"
CORRECTION_DATETIME="2008-10-06T00:00:00Z" />
</INSTRUMENTS>
</API_RESPONSE>

3.2.7 getForwardCurve
Returns the “forward curve” for a requested date. This is for any “Future” or “Forward” type
of Instrument.
Arguments:
Condition Tags:
Name Description
CURVE_ROOT A valid INSTRUMENT_ROOT_NAME returned in a
getInstrumentRootList request.
CURVE_DATE A date in the format, ‘YYYY-MM-DD’. This is the date to
retrieve the forward curve, if no curve is available for the
date provided, the response will return “N/A” for all of the
response tags
Default Tags:
Name
INSTRUMENT_ID, TRADE_DATETIME, CLOSE
Response:
Type Description
The response includes 3 fields (INSTRUMENT_ID, TRADE_DATETIME,
CLOSE). INSTRUMENT_ID is the actual symbol based off the
CURVE_ROOT requested, CLOSE is the settling value for the requested
CURVE_DATE and TRADE_DATETIME is the “Delivery Date” for the
“Future or Forward” contract.

<API_REQUEST>
<CONDITIONS CURVE_ROOT="/RB" END_DATE="2014-03-19" />
</API_REQUEST>

<INSTRUMENTS>
<INSTRUMENT CLOSE="2.8688" INSTRUMENT_ID="/RBJ14" TRADE_DATETIME="2014-04-
01T00:00:00Z"></INSTRUMENT>
<INSTRUMENT CLOSE="2.8627" INSTRUMENT_ID="/RBK14" TRADE_DATETIME="2014-05-
<INSTRUMENT CLOSE="2.8380" INSTRUMENT_ID="/RBM14" TRADE_DATETIME="2014-06-
<INSTRUMENT CLOSE="2.8083" INSTRUMENT_ID="/RBN14" TRADE_DATETIME="2014-07-
<INSTRUMENT CLOSE="2.7758" INSTRUMENT_ID="/RBQ14" TRADE_DATETIME="2014-08-
<INSTRUMENT CLOSE="2.7381" INSTRUMENT_ID="/RBU14" TRADE_DATETIME="2014-09-
<INSTRUMENT CLOSE="2.5927" INSTRUMENT_ID="/RBV14" TRADE_DATETIME="2014-10-
<INSTRUMENT CLOSE="2.5573" INSTRUMENT_ID="/RBX14" TRADE_DATETIME="2014-11-
<INSTRUMENT CLOSE="2.5333" INSTRUMENT_ID="/RBZ14" TRADE_DATETIME="2014-12-
<INSTRUMENT CLOSE="2.5217" INSTRUMENT_ID="/RBF15" TRADE_DATETIME="2015-01-
</INSTRUMENTS>
</API_RESPONSE>

3.3 Data Quality API Methods
MarketView Web Services provides functions that allow you to inspect data quality in the Intraday,
LiveQuote, Daily, Trades, ISO-Hourly and ISO-Daily data stores. These allow you to check,
• Is there a quote available for the given day
• Does the quote lie within a certain threshold of previous quotes in the system
o Expressible as a fixed amount
o Expressible as a percentage
o The positive threshold (amount the quote goes up) can be explicitly expressed
o The negative threshold (amount the quote goes down) can be explicitly expressed
o You can set the sampling size of previous quotes – e.g., read and average the
lastmost ‘x’ quotes, then compare that value to the threshold values.
o The field being compared in the quote is user-definable. So, you could compare the
CLOSE, LAST, or VOLUME.
3.3.1 Are{dataSet}PricesAvailable
MarketView Web Services provides this family of methods (areDailyPricesAvailable,

areHourlyISOPricesAvailable, areDailyISOPricesAvailable, areTradePricesAvailable,
areLiveQuotePricesAvailable, and areIntradayPricesAvailable,,) to determine if a price
quote has been delivered for the given instrument(s) today. Reasons why quotes may not
be available vary, but can include issues such as exchange holidays or transmission
problems. If you are concerned that you may not have a complete dataset, this family of
methods can help you track down issues.
Essentially, these methods run a variant of get{dataSet}Prices methods, documented in

Sections 3.2.1 – 3.2.6, where there is a <CONDITIONS> clause of DAYS_BACK=”2” set,
to previous two days’ quotes.
MarketView Web Services determines whether a quote for today is available, and returns
that information to you through the tag QUOTE_AVAILABLE. If the quote is available, this
tag has the value of “AVAILABLE”; else “NOT AVAILABLE”.
Note that the definition of “today” is a little nebulous: MarketView’s infrastructure stores all
date/times in Greenwich Mean Time, and does not necessarily “know” then the day ends
at the Exchange where the Instrument is quoted from. Therefore, it is up to you to specify
the Exchange’s timezone (through the TIMEZONE tag.) If no timezone is specified,
MarketView Web Services assumes “America/Chicago”.
Arguments:
String requestXML Request XML. The request should contain a
<CONDITIONS> clause identifying the TIMEZONE for
which to run the query.
Condition Tags:
Name Description


appears in <INSTRUMENTS> (specific instrument_id’s)
or <INSTRUMENT_SEARCHES> (wildcards)
TIMEZONE Should appear; as all quotes’ date/time fields are stored
in Greenwich Mean Time, how does MarketView Web
Services determine when (in equivalent GMT,) the day
ends at the Exchange’s timezone?
Given that information, MarketView Web Services then

looks for the lastmost quote being within the range of
0:00:00 to 23:23:59 of todays date for the given timezone.
If you do not specify timezone, it is assumed to be

‘Americas/Chicago’, or ‘GMT-06:00’ (ISO 8601
designation for Central Standard Timezone)
Default Tags:
Name
Whatever the default tags are for the given method, plus INSTRUMENT_ID,
TRADE_DATETIME, QUOTE_AVAILABLE
Response:
Type Description

<API_REQUEST>
<INSTRUMENTS>
<INSTRUMENT INSTRUMENT_ID="/CLZ06" />
</INSTRUMENTS>
<CONDITIONS TIMEZONE="America/New York" />
</API_REQUEST>

<INSTRUMENTS>
<INSTRUMENT MONEY_FLOW="N/A" MID_POINT="59.700" CONTRIBUTOR="N/A" LAST="N/A" LOW="59.10"
EXCHANGE_ID="N/A" TICK_TYPE="34" OPEN_INTEREST="244435" EXCHANGE_CODE="N/A" VOLUME="242868"
INSTRUMENT_ID="/CLZ06" TRADE_DATETIME="2006-11-08T12:00:00-0600" TICK_COUNT="N/A"
HIGH="N/A" EXCHANGE_IDENTIFIER="N/A" OPEN="59.30" CLOSE="59.83" TRADE_VOLUME="N/A"
QUOTE_AVAILABLE="AVAILABLE" />
</INSTRUMENTS>
</API_RESPONSE>

3.3.2 are{dataSet}PricesInAbsoluteThreshold
MarketView Web Services provides this family of methods

(areDailyPricesInAbsoluteThreshold, areHourlyISOPricesInAbsoluteThreshold,
areDailyISOPricesInAbsoluteThreshold, areTradePricesInAbsoluteThreshold,
areLiveQuotePricesInAbsoluteThreshold, and
areIntradayPricesInAbsoluteThreshold,) to determine if a price quote is within a user-
specified threshold. The major difference between this family of methods and those
documented in Section 3.3.3 is these methods deal with fixed numbers (e.g., ± a
constant); the family of methods in Section 3.3.3 instead deals with changes in the quotes
that are ± a percentage.
For example, you might wish to be notified if the last price of an instrument increases or
decreases by more than $5 of the average last, established by sampling ‘x’ previous price
quotes. These methods allow you to determine that.
In order to use these methods properly, you first need to indicate which tag you want
MarketView Web Services to analyze. This is set with the THRESHOLD_FIELD tag in the
CONDITIONS clause; by default, the tag “CLOSE” is inspected. Other reasonable tags
might be LAST, or VOLUME. (Obviously, tags analyzed must be numeric)
Next, you need to set the SAMPLE_SIZE tag in the CONDITIONS clause. Doing so
establishes the number of records MarketView Web Services should look at when
establishing what the average value of the THRESHOLD_FIELD is. By default, the
SAMPLE_SIZE is set to 1 (which means, the previous quote in the system is used to
establish the average – an average, sampling one record.)
Next you need to set the CHECK_SIZE tag in the CONDITIONS clause. This indicates
how many quotes, following the SAMPLE_SIZE, you would like to analyze for being within
threshold values. The default value for CHECK_SIZE is 1. (What this means is, if both
SAMPLE_SIZE and CHECK_SIZE are set to 1, the last two quotes are read – the
second-to-last to establish the average, the last to analyze for thresholds.)

The following diagram shows the relationship of SAMPLE_SIZE versus CHECK_SIZE:

Sample Size indicates the number of quotes in the system for which you want to system to
sample, and establish an average value. Check Size designates the number of quotes
immediately following the Sample Size, which will be tested against thresholds of that
average value. Check Size always ends at the lastmost quote in the system, and Sample
Size always abuts Check Size.
Finally, you must set the thresholds to compare against. You have two ways to do this,
• If the range you want to check for is the same amount (e.g., the threshold is ± a
value, like ±2), assign THRESHOLD_AMOUNT tag in the CONDITIONS clause.
• If you would like individual control of the ceiling the quote can increase by, set the
POSITIVE_THRESHOLD_AMOUNT tag in the CONDITIONS clause. For the
floor, set the NEGATIVE_THRESHOLD_AMOUNT tag. (If you specify positive
threshold, you must also specify negative threshold.) Both amounts should be
positive.
MarketView Web Services will run a query for you, adding a tag named
THRESHOLD_REPORT, that reports whether the tag specified is within or outside the
specified threshold.
Arguments:
String requestXML Request XML. The request must contain a
<CONDITIONS> clause with the THRESHOLD_AMOUNT
or the POSITIVE_THRESHOLD_AMOUNT --
NEGATIVE_THRESHOLD_AMOUNT pair (both must
appear)
Condition Tags:
Name Description
INSTRUMENT_ID Does not appear in the <CONDITIONS>
clause; instead appears in <INSTRUMENTS>
(specific instrument_id’s) or
SAMPLE_SIZE Specifies the number of records to read from
the datastore to establish the average. Defaults

to 1.
CHECK_SIZE Specifies the number of records to read from
the datastore to for analysis against the
average. Defaults to 1.
THRESHOLD_FIELD The tag in the quote(s) to compare. Defaults to
CLOSE; must be a numeric field.
THRESHOLD_AMOUNT The threshold amount to compare against.
Shortcut for specifying
POSITIVE_THRESHOLD_AMOUNT and
NEGATIVE_THRESHOLD_AMOUNT with the
same value.
POSITIVE_THRESHOLD_AMOUNT The threshold value for positive value change
that the quote value cannot exceed. A positive
value.
NEGATIVE_THRESHOLD_AMOUNT The threshold value for negative value change
value.
Default Tags:
Name
TRADE_DATETIME, the tag specified by THRESHOLD_FIELD, and
THRESHOLD_REPORT.
Response:
Type Description

NOT A REAL SAMPLE

<INSTRUMENTS>
QUOTE_AVAILABLE="NOT AVAILABLE" />
</INSTRUMENTS>
</API_RESPONSE>

3.3.3 are{dataSet}PricesInPercentileThreshold
MarketView Web Services provides this family of methods

(areDailyPricesInPercentileThreshold, areHourlyISOPricesInPercentileThreshold,
areDailyISOPricesInPercentileThreshold, areTradePricesInPercentileThreshold,
areLiveQuotePricesInPercentileThreshold, and
areIntradayPricesInPercentileThreshold,) to determine if a price quote is within a user-
specified threshold. The major difference between this family of methods and those
documented in Section 3.3.2 is that the former deals with fixed numbers (e.g., ± a
constant); this family of methods instead deals with changes in the quotes that are ± a
percentage.
For example, you might wish to be notified if the last price of an instrument increases or
decreases by more than 5% of the average last, established by sampling ‘x’ previous
price quotes. These methods allow you to determine that.
In order to use these methods properly, you first need to indicate which tag you want
MarketView Web Services to analyze. This is set with the THRESHOLD_FIELD tag in the
CONDITIONS clause; by default, the tag “CLOSE” is inspected. Other reasonable tags
might be LAST, or VOLUME. (Obviously, tags analyzed must be numeric)
Next, you need to set the SAMPLE_SIZE tag in the CONDITIONS clause. Doing so
establishes the number of records MarketView Web Services should look at when
establishing what the average value of the THRESHOLD_FIELD is. By default, the
SAMPLE_SIZE is set to 1 (which means, the previous quote in the system is used to
establish the average – an average, sampling one record.)
Next you need to set the CHECK_SIZE tag in the CONDITIONS clause. This indicates
how many quotes, following the SAMPLE_SIZE, you would like to analyze for being within
threshold values. The default value for CHECK_SIZE is 1. (What this means is, if both
SAMPLE_SIZE and CHECK_SIZE are set to 1, the last two quotes are read – the
second-to-last to establish the average, the last to analyze for thresholds.)
Finally, you must set the thresholds to compare against. You have two ways to do this,
• If the range you want to check for is the same amount (e.g., the threshold is ± a
value, like ±2), assign THRESHOLD_AMOUNT tag in the CONDITIONS clause.
If you would like to check against 5%, THRESHOLD_AMOUNT should be set to
5. MarketView Web Services will divide your entries by 100. Which means,
fractional amounts in your arguments are considered to be fractions of a percent.
• If you would like individual control of the ceiling the quote can increase by, set the
POSITIVE_THRESHOLD_AMOUNT tag in the CONDITIONS clause. For the
floor, set the NEGATIVE_THRESHOLD_AMOUNT tag. (If you specify positive
threshold, you must also specify negative threshold.) Both amounts should be
positive. If you’d like to check against 5%, pass “5” as the argument; MarketView
Web Services will divide your arguments by 100. Which means, fractional
amounts in your arguments are considered to be fractions of a percent.
MarketView Web Services will run a query for you, adding a tag named
THRESHOLD_REPORT, that reports whether the tag specified is within or outside the
specified threshold.

Arguments:
String requestXML Request XML. The request must contain a
<CONDITIONS> clause with the THRESHOLD_AMOUNT
or the POSITIVE_THRESHOLD_AMOUNT --
NEGATIVE_THRESHOLD_AMOUNT pair (both must
appear)
Condition Tags:
Name Description
INSTRUMENT_ID Does not appear in the <CONDITIONS>
clause; instead appears in <INSTRUMENTS>
(specific instrument_id’s) or
SAMPLE_SIZE Specifies the number of records to read from
the datastore to establish the average. Defaults
to 1.
CHECK_SIZE Specifies the number of records to read from
the datastore to for analysis against the
average. Defaults to 1.
THRESHOLD_FIELD The tag in the quote(s) to compare. Defaults to
CLOSE; must be a numeric field.
THRESHOLD_AMOUNT The threshold amount to compare against.
Shortcut for specifying
POSITIVE_THRESHOLD_AMOUNT and
NEGATIVE_THRESHOLD_AMOUNT with the
same value. MarketView Web Services will
divide your argument by 100, so if you want 5%,
pass “5”.
POSITIVE_THRESHOLD_AMOUNT The threshold value for positive value change
value.
NEGATIVE_THRESHOLD_AMOUNT The threshold value for negative value change
value.
Default Tags:
Name
TRADE_DATETIME, the tag specified by THRESHOLD_FIELD, and
THRESHOLD_REPORT.
Response:
Type Description

NOT A REAL SAMPLE

<INSTRUMENTS>
QUOTE_AVAILABLE="NOT AVAILABLE" />
</INSTRUMENTS>
</API_RESPONSE>

3.4 Data Import Methods
MarketView Web Services provides data import facilities, that allows you to upload price
quotes, corrections and news stories into the GlobalView infrastructure. This is very useful
if you have information that you want to be available on a real-time basis to other
members of your company through our infrastructure and client application suite.
An obvious use of MarketView Web Services is to publish prices for a collection of

instruments, although you might also publish curves, risk management reports, etc. Each
data import client is a consulting engagement: news source(s), exchange(s), and
symbology has to be designed for you, as well as provisioning rules to limit who can see
your data. Contact your GlobalView sales person for more information.
Instrument Prices
• importInstrumentPrice
• importInstrumentPriceCorrection
• importInstrumentMetaData
// Maybe: ISO instruments

• importISOPrice
• importISOPriceCorrection
• importISOMetaData
News Articles
• importNews
Data Importation Runtime Monitoring

• getImportStatistics
MarketView Web Services’ Import Data methods require that you provide the name of the
application. That value is user-defined, and it allows you to fine-tune the granularity of the
runtime statistics we gather for you. Import Statistics keeps track of the number of success
and failures to import data, broken down by userName and application. If you partition
the application name passed by the type of data being imported (or the machine doing
the importing,) this can help you track down Production issues.
No restrictions are placed on application values you can use, nor do you have to do
anything special to register a legal value – merely pass an application to one of the API
calls – if it did not exist beforehand, it will be created.

3.4.1 importInstrumentPrice
Allows the user to import a price for an instrument. This price is inserted into two data
stores: LiveQuote and Trade/Historical. For the Trade/Historical data store, we use the
trade datetime and the close tags. For LiveQuote we use the trade datetime, open,
high, low, volume, open interest and last tags. (Last and close tags would contain the
same value.)
MarketView Web Services allows one price quote to be published per method invocation.
Arguments:
String Application User-defined name of the importing application process.
String requestXML Request XML.
Required Tags:
Name Description
INSTRUMENT_ID Identifier for the given instrument.
EXCHANGE_CODE Exchange identifier for the instrument.
TRADE_DATETIME Date/Time of the price quote
CLOSE Price communicated to the Trade/Historical data store
LAST Price communicated to the LiveQuote data store
Optional Tags:
Name Description
HIGH Session’s High price
LOW Session’s Low price
OPEN Session’s opening price
VOLUME Volume
OPEN_INTEREST Open Interest
Response:
Type Description
String XML structured to contain a response for the request. API_RESPONSE
will only contain an error code and error description.

<API_REQUEST>
<DAILY_PRICE
INSTRUMENT_ID="#TESTSYM1"
EXCHANGE_CODE="TEST"
TRADE_DATETIME="2006-06-07T14:00:00Z"
HIGH="100.0"
LOW="65.0"
OPEN="67.0"
VOLUME="45000"
OPEN_INTEREST="1200"
CLOSE="72.0"
LAST="72.0"
/>
</API_REQUEST>


3.4.2 importInstrumentMetaData
Allows the user to import metadata concerning a given instrument. Instrument metadata
includes fields such as description, currency, lot units, etc., and these are values that
generally do not change.
MarketView Web Services allows one instrument’s metadata to be published per method
invocation.
Arguments:
String Application User-defined name of the importing application process.
String requestXML Request XML.
Required Tags:
Name Description
INSTRUMENT_ID Identifier for the given symbol.
EXCHANGE_CODE Exchange identifier for the symbol.
Optional Tags:
Name Description
CURRENCY Currency
LOT_UNITS Lot Units. E.g., gallons,barrows, etc.
MARKET Market (used in symbol search)
REGION Region (used in symbol search)
LOCATION Location (used in symbol search)
CONVERSION_FACTOR Lot unit conversion factor
EXPIRATION_DATE Expiration Date
Response:
Type Description
String XML structured to contain a response for the request. API_RESPONSE
will only contain an error code and error description.

<API_REQUEST>
<INSTRUMENT_METADATA
INSTRUMENT_ID="#TESTSYM2"
EXCHANGE_CODE="TEST"
SYMBOL_DESCRIPTION="Test December Contract"
CURRENCY="USD"
LOT_UNITS="BBL"
MARKET="Gulf Coast 1% Oil"
REGION="United States"
LOCATION="QUAKERTOWN"
CONVERSION_FACTOR="100.0"
EXPIRATION_DATE="2006-12-01"
/>
</API_REQUEST>


Frequently Asked Questions
• What is the major difference between MarketView and MarketView WebServices?
Besides the obvious difference (GUI versus Web Services), the major difference is in how the
products obtain information from GlobalView’s infrastructure. The MarketView GUI application
obtains price quotes through a publish/subscribe paradigm, versus request/reply used in
MarketView Web Services. The major difference between the two is the handling of complex
requests: longer-running requests are subject to timeout constraints in a request/reply.
Should this become an issue (e.g., you want to request 10 years’ of Trade data,) it is probably a
better thing by far to have this request run for you by GlobalView as a one-time export. Contact
us for details.
• Where is MarketView Web Services Hosted?
We also have “development” servers, against which you should develop your client software.
The reason for this is quality-of-service – we’ll advise you as the name of servers assigned to
you.
• What is the Web Services topography?
We support SOAP/ XML as implemented with Apache Axis 1.x.
• What are the support contact details?
Email: DL_DataConnection_API_Support@gvsi.com
Phone:

Appendix
Security Types
Security
Type Security Type Code
F Futures
FO Futures Option
SP Spot
S Stock
ID Index
A Future Alias
C Future Continuous
FX Foreign Exchange
IS ISO Data
SF Spot Forward
Exchange Traded
ET Fund
Examples on how to search for futures roots, futures chains, futures

aliases and futures continuous symbols.
getInstrumentRootList
This query has no input parameters. The result gives you the futures root records the requesting
login id is permissioned for.
A small sample of the results is as follows:

<INSTRUMENT_ROOTS>
<INSTRUMENT_ROOT CONVERSION_FACTOR="7.803000" CURRENCY="USD" EXCHANGE_CODE="NYM"
INSTRUMENT_DESCRIPTION="NYMEX Crude Light" INSTRUMENT_ROOT_NAME="/CL" LOT_UNITS="BBL"
OPTION_ROOT="/CL" SECURITY_TYPE="F" SESSION="2"></INSTRUMENT_ROOT>
<INSTRUMENT_ROOT CONVERSION_FACTOR="1.0" CURRENCY="USD" EXCHANGE_CODE="NYM"
INSTRUMENT_DESCRIPTION="NYMEX Natural Gas" INSTRUMENT_ROOT_NAME="/NG" LOT_UNITS="MMB"
OPTION_ROOT="/NG" SECURITY_TYPE="F" SESSION="2"></INSTRUMENT_ROOT>
<INSTRUMENT_ROOT CONVERSION_FACTOR="7.803000" CURRENCY="USD" EXCHANGE_CODE="NYMG"
INSTRUMENT_DESCRIPTION="NYMEX Crude Light" INSTRUMENT_ROOT_NAME="/GCL" LOT_UNITS="BBL"
OPTION_ROOT="/CL" SECURITY_TYPE="F" SESSION="1"></INSTRUMENT_ROOT>
...
</INSTRUMENT_ROOTS>
</API_RESPONSE>
getInstrumentList
You can use the results of this query to feed the getInstrumentList method and query each
OPTION_ROOT/SESSION/EXCHANGE_CODE/SECURITY_TYPE combination to get all the
instruments for each futures root.
For example, here is the query for getInstrumentList to get the instruments of one of the futures
roots above:

<API_REQUEST>
<CONDITIONS EXCHANGE_CODE="NYM" />
<CONDITIONS SECURITY_TYPE="F" />
<CONDITIONS INSTRUMENT_ID="/CL[A-Z][0-9][0-9]" />
<CONDITIONS OPTION_ROOT="/CL" />
<CONDITIONS SESSION="2" />
</API_REQUEST>
Notice, you can get the EXCHANGE_CODE, SECURITY_TYPE, OPTION_ROOT & SESSION
from the getInstrumentRootList method above. The INSTRUMENT_ID is provided to make sure
you retried 2-digit year instruments in the request. It is built by using the OPTION_ROOT plus a
pattern "[A-Z]" for a month code and 2 patterns of "[0-9]" for the 2-digit year. This is to avoid
getting 1-digit year symbols in your response. 1-digit year symbols exist in the system for
backward compatibility.
This will give you results like the following

<INSTRUMENTS><INSTRUMENT CONVERSION_FACTOR="7.803000" CURRENCY="USD" EXCHANGE_CODE="NYM"
EXPIRATION_DATE="1999-12-20" INSTRUMENT_ID="/CLF00" LOT_UNITS="BBL" PUT_CALL="U"
SECURITY_TYPE="F" SESSION="2" SYMBOL_DESCRIPTION="Jan 00 Light Crude Oil"
UNDERLIER="/CLF00"></INSTRUMENT>
</INSTRUMENT><INSTRUMENT CONVERSION_FACTOR="7.803000" CURRENCY="USD" EXCHANGE_CODE="NYM"
</INSTRUMENT><INSTRUMENT CONVERSION_FACTOR="7.803000" CURRENCY="USD" EXCHANGE_CODE="NYM"
...
</INSTRUMENTS>
</API_RESPONSE>
If you want to limit the response for the chain for non-expired instruments, you can add the
following condition:
<CONDITIONS EXPIRATION_DATE="2013-08-12" />
th
This limits the results to any instrument with an expiration date greater than or equal to August 12
2013.
To get a list of Continuous or Alias symbols you can use the getInstrumentList method as follows:
Aliases:
<API_REQUEST>
<CONDITIONS EXCHANGE_CODE="NYM" />
<CONDITIONS SECURITY_TYPE="A" />
<CONDITIONS INSTRUMENT_ID="/CL[*]" />
</API_REQUEST>
For Alias, use the result in the INSTRUMENT_ROOT_NAME tag from the getInstrumentRootList
method above.
Continuous:
<API_REQUEST>
<CONDITIONS EXCHANGE_CODE="NYMG" />
<CONDITIONS SECURITY_TYPE="C" />
<CONDITIONS INSTRUMENT_ID="/GCL<*>" />
</API_REQUEST>
For Continuous, use the result in the INSTRUMENT_ROOT_NAME tag from the
getInstrumentRootList method above.

Web Services API 2.0

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Web Services API 2.0

Uploaded by

Copyright:

Available Formats

GlobalView Software, Inc -

MarketView Web Services API 2.0

© GVSI 2005-2009, Proprietary and Confidential

3.2.4 getIntradayPrices ............................................................... 45

1.2 Intended Audience

This document is intended for IT developers working for or on behalf of MarketView

© GVSI 2005-9, Proprietary and Confidential Page 1

Data Query Facilities

Data Quality Facilities

• Programmatically determine availability of price quotes

Data Import Facilities

Based on Industry Standards

• Uses industry-standard SOAP/XML API (Apache Axis.)

© GVSI 2005-9, Proprietary and Confidential Page 2

2.1 API Architecture

MarketView Web Services

Permissions Data Data Data

Data Data Data

© GVSI 2005-9, Proprietary and Confidential Page 3

2.2 API Architecture Message Structure

API Message Format

SSL Encryption (HTTP secure transmission)

HTTP Envelope (text):

SOAP Envelope (XML):

2.3 Messaging Detail

© GVSI 2005-9, Proprietary and Confidential Page 4

2.4 The Request String

1. A data request comprises of a list of instruments, enclosed in-between two

© GVSI 2005-9, Proprietary and Confidential Page 5

2.5 Specifying Filters in the Request String (Conditions)

© GVSI 2005-9, Proprietary and Confidential Page 6

2.6 The Response String

<?xml version="1.0" encoding="UTF-8"?> 1

1. All responses begin with the line, “API_RESPONSE”. If there is an error in

© GVSI 2005-9, Proprietary and Confidential Page 7

2.7 Values in the Request and Response String

2.8 The “Raw” XML

MarketView Web Services is implemented in SOAP/XML using Apache Axis 1

Following is a sample incoming request, captured by tcpmon,

© GVSI 2005-9, Proprietary and Confidential Page 8

POST /services/mt HTTP/1.0

<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope

© GVSI 2005-9, Proprietary and Confidential Page 9

The response from MarketView Web Services, in turn, looks like,

<?xml version="1.0" encoding="UTF-8"?>

... etc ...

© GVSI 2005-9, Proprietary and Confidential Page 10

2.9 The Data Stores

GlobalView keeps several data stores for our pricing data.

2.10 Correction Data Stores

2.11 MarketView Web Services URL

MarketView Web Services is hosted from URL,

2.12 Symbols, Aliases & Continuous

© GVSI 2005-9, Proprietary and Confidential Page 11

NYMEX Alias Examples

ICE Alias Examples

© GVSI 2005-9, Proprietary and Confidential Page 12

Continuous Symbology Examples

2.13 Authentication Issues

Authentication in MarketView Web Services is established through the published methods

2.14 Addressing Error Conditions/Error Codes

<API_RESPONSE CODE="0" DETAILS="" >

© GVSI 2005-9, Proprietary and Confidential Page 13

<?xml version="1.0" encoding="UTF-8"?>