Data Retrieval Interface Protocol 1.5

1.0 Introduction to the Data Retrieval Interface Protocol 1.5

NETbilling has the most powerful Direct Mode payment interfaces available in the gateway industry. These interfaces allow merchants to completely automate payment processing. The Data Retrieval Interface (formerly known as "Scriptable Reporting Interface" or SRI, prior to version 1.5) is a Direct Mode style interface allowing merchants to access their transaction and membership data in a machine parsable format through an easy-to-use network API. This data can be used for a merchant's own statistical monitoring or in conjunction with third party affiliate management software. All data is stored in the Gateway system and shared according to stringent Visa PCI regulations.

1.1 Overview

This interface is intended to be used by merchants to develop their own software for monitoring transaction and membership data or to utilize third party affiliate management software to accomplish these tasks. As outlined below, the Data Retrieval Interface is actually divided into two separate interfaces for separately acquiring transaction and membership data.

This document outlines the technical specifications needed to take advantage of the Data Retrieval Interface and is intended for a technical audience. Knowledge of HTTP standards is assumed.

1.2 Principles of Operation

To make client implementation as simple as possible, the Data Retrieval Interface protocol is based on the standard HTTP protocol and SSL (HTTPS) encryption. Most modern languages have built in libraries that can be used to implement HTTP clients with very little effort.

A request is initiated by sending an HTTP POST to our host. The host will respond momentarily with the resulting information on the same socket. All attribute-value pairs in the request should be URL encoded, just like a standard <form> POST from a browser. All response data will be returned in CSV format or text format.

1.3 Host Addresses

The following host addresses should be used to access the Data Retrieval Interface:

Host Description
https://secure.netbilling.com/gw/reports/member1.5 Member Reporting Interface
https://secure.netbilling.com/gw/reports/transaction1.5 Transaction Reporting Interface
Table 1.3.1

1.4 Security Considerations

The secure handling of an account's transaction and membership data is achieved through two separate security considerations. The primary security method comes in the form of a required list of authorized static client IP addresses. The management of such authorized IP addresses can be handled through the "Data Retrieval Interface" section of the "Access Security" page. Multiple addresses and/or entire subnets can be added to this approved listing to allow merchants to utilize this tool for both personal reporting usage as well as to grant access to this data for a 3rd party affiliate organization or multiple such entities. Proper management of approved IP addresses is the most important method for ensuring the protection of all membership and transaction data within an account.

The second method of security required to take advantage of these reporting interfaces comes in the form of providing a list of approved access keywords for each site tag that is to be available for remote data access. The merchant has the option of providing multiple keywords for each site tag to provide parallel access to separate reporting entities, and doing so will ensure that access can easily be revoked for one specific reporting entity without affecting others.

2.0 Protocol Request Reference

This section will outline and explain all parameters recognized by the system relating to the Data Retrieval Interface protocol as well as which of these are required for proper operation of each of the separate interfaces.

2.1 Required Request HTTP Headers

The following standard HTTP headers are expected in the request.

HeaderStatusComments
Content-Length Required The length of the POST request body in bytes.
Content-Type Required The value must be "application/x-www-form-urlencoded"
Host Optional The name of the server you are connecting to: "secure.netbilling.com"
User-Agent Required A descriptive name of your client software and the most recent date it was updated.
is is important because it allows us to identify and notify clients using old software when new features are added to the protocol.

Example: "MyDRIClient/Version:2010.Feb.20"

Table 2.1.1


2.2 Required Request Parameters

The following input parameters are necessary for proper operation of both the Member and Transaction Data Retrieval Interfaces.

ParameterConditionDetails
account_idRequiredThe 12-digit gateway account ID from which data is to be extracted.
site_tagOptionalThis field specifies a particular site tag from which the data will be extracted. If this is not provided data from all site tags will be returned. This field can be specified multiple times to return data from several specific site tags. Examples of this can be found in sections 2.2 and 2.3 below.
authorizationRequiredThis field should contain the authorization keyword for the given site tag. These keywords can be managed from the Website Config page for the given site tag. This field can be specified multiple times with each request to provide authorization keywords for multiple site tags. Examples of this can be found in sections 2.2 and 2.3 below.
Table 2.2.1


2.3 Request Parameters for the Member Reporting Interface

The following input parameters are for use with the Member Reporting Interface (member1.5). At least one "_after" parameter must always be specified. Ensure the date range is limited to period of interest only, and avoid repetitive requests returning the same data. Excessive usage triggers automatic IP lock-out for up to 24 hours. These limits should never be a problem for a properly coded client implementation.

Date formats with or without 24-hour times can be used. "2013-12-31" is identical to "2013-12-31 00:00:00". A range includes records on or after the start-time, until immediately before the end-time. This ensures that records at the boundaries are returned exactly once, and the client can simply reuse the most recent end-time as the start-time for the next request.

For example, a contiguous range can be fetched by combining multiple requests and intervals:

Req. No.Transactions AfterTransactions Before
1st 2012-12-29 2012-12-30
2nd 2012-12-30 2012-12-31
3rd 2012-12-31 2013-01-01
4th 2013-01-01 2013-01-01 08:00:00
5th 2013-01-01 08:00:00  2013-01-01 16:00:00
6th 2013-01-01 16:00:00  2013-01-02 00:00:00
7th 2013-01-02 2013-01-05

The following date-range parameters are supported:

ParameterConditionDetails
expire_afterRequired*If used, only data for members who expired or would expire on or after the date specified by this field would be returned.
expire_beforeOptionalIf used, only data for members who expired or would expire before the date specified by this field would be returned.
transactions_afterRequired*If used, only data for members who had transaction data processed on or after the date specified by this field would be returned.
transactions_beforeOptionalIf used, only data for members who had transaction data processed before the date specified by this field would be returned.
changed_afterRequired*If used, only data for members whose last status change occurred on or after the date specified by this field would be returned.
changed_beforeOptionalIf used, only data for members whose last status change occurred before the date specified by this field would be returned.
Table 2.3.1
*One of these parameters must be provided.

The following is an example of a typical HTTP POST request to the Member Reporting Interface for a single site tag:


POST /gw/reports/member1.5 HTTP/1.0
Host: secure.netbilling.com
User-Agent: MyDRIClient/Version:2010.Feb.20
Content-Type: application/x-www-form-urlencoded
Content-Length: 125
account_id=123456789012&site_tag=TEST&transactions_after=2006-12-30&transactions_before=2006-03-01&authorization=TEST_KEYWORD

The following is an example of a typical HTTP POST request to the Member Reporting Interface for multiple site tags with multiple access keywords:


POST /gw/reports/member1.5 HTTP/1.0
Host: secure.netbilling.com
User-Agent: MyDRIClient/Version:2010.Feb.20
Content-Type: application/x-www-form-urlencoded
Content-Length: 123
account_id=123456789012&site_tag=TEST1&site_tag=TEST2&expire_after=2006-12-30&authorization=TEST1_KW&authorization=TEST2_KW


2.4 Request Parameters for the Transaction Reporting Interface

The following input parameters are for use with the Transaction Reporting Interface (transaction1.5).

ParameterConditionDetails
transactions_afterRequired1Transactions issued on or after the date specified by this field will be returned.
transactions_beforeOptionalIf Used, transactios issued before the date specified by this field will be returned.
disputes_afterRequired1Download only NBCheck chargeback transactions having resulted from disputes by customer on or after specified date.
disputes_beforeOptional
" "
returned_afterRequired1Download only NBCheck transactions which were returned ("bounced") on or after specified date. This can be combined with transactions_after / transactions_before or used by itself.
returned_beforeOptional
" "
charged_back_afterRequired1Download only transactions reported by ChargeBack LookoutTM on or after specified date. Both ChargeBacks and Retrieval Requests can be downloaded. This may be combined with transactions_after / transactions_before or used by itself. Newly reported chargebacks, even when back-dated, will not be missed as the query is based on the reporting date in the system, not the bank's posting date. See dispute_report_date.
charged_back_beforeOptional
" "
captured_afterRequired1Previously authorizied transactions which were captured on or after the date specified will be returned. When specified, only transactions subject to delayed capture will be returned.
Table 2.4.1
1At least one of these fields is required.

The following is an example of a typical HTTP POST request to the Transaction Reporting Interface for a single site tag:


POST /gw/reports/transaction1.5 HTTP/1.0
Host: secure.netbilling.com
User-Agent: MyDRIClient/Version:2010.Feb.20
Content-Type: application/x-www-form-urlencoded
Content-Length: 94
account_id=200274083904&site_tag=TEST&transactions_after=2006-12-30&authorization=TEST_KEYWORD

The following is an example of a typical HTTP POST request to the Transaction Reporting Interface for multiple site tags with multiple access keywords:


POST /gw/reports/transaction1.5 HTTP/1.0
Host: secure.netbilling.com
User-Agent: MyDRIClient/Version:2010.Feb.20
Content-Type: application/x-www-form-urlencoded
Content-Length: 129
account_id=200274083904&site_tag=TEST1&site_tag=TEST2&transactions_after=2006-12-30&authorization=TEST1_KW&authorization=TEST2_KW


3.0 Protocol Response Reference

This section will outline and explain all response fields provided by the Data Retrieval Interface. Data will be returned in CSV (text/x-comma-separated-values MIME type) with field names provided on the first line of the response. All data is double quote (") enclosed. Any double-quotes within a data field will be removed to simplify parsing rather than double quoted per the CSV standard. Responses will be guaranteed to never contain a newline-linefeed sequence except at the end of each record. New columns may be added in the future and the column ordering may change. The client MUST parse the header line to determine the column numbers when processing a response.

3.1 Response HTTP Headers

Standard HTTP headers are returned in the response:

Header Present Comments
Content-Type Always The value is normally "text/x-comma-separated-values", but "text/plain" is used for the body of error messages.
Content-Length Not Always For some reports the Content-Length is not known until after the response has been streamed to the client. You should continue reading until an End-Of-File is received on the socket.
Retry-After In case of HTTP 503 Service Unavailable This header is sent for HTTP 503 response codes. It indicates the number of seconds your client should wait before resubmitting the request. We strongly recommend that all clients implement this to ensure that the response is received as soon as it's available.

We process certain requests asynchronously, the criteria for which is subject to change. If you fail to implement Retry-After handling, your client may stop working in the future.

Table 3.1.1


3.2 Member Reporting Interface Response Fields

The following fields are those that will be returned following every successful request to the Member Reporting Interface.

FieldDetails
site_tagThe site tag the given member belongs to.
member_idThe unique 12-digit member ID identifying the given member. This ID can be used to directly link membership and transaction data.
member_statusThe current status of the membership. This status will be one of the following:
  • "PENDING" - Member has been created but not activated yet.
  • "ACTIVE" - Member is active.
  • "ACTIVE/R" - Member will automatically be "RESIGNED" at the next recurring billing date.
  • "RESIGNED" - Member has resigned.
  • "DISABLED" - Member has been disabled.
  • "EXPIRED" - Member has expired.
previous_member_statusThe membership status prior to the most recent status change.
status_change_dateThe date (YYYY-MM-DD HH:MM:SS) when this member's status last changed.
member_user_nameThe login name for the given member. Login names are unique to particular site tags and will also be unique across all site tags if configured that way in the "Website Config" for that site.
signup_dateThe date (YYYY-MM-DD HH:MM:SS) the membership was created.
expire_dateThe date (YYYY-MM-DD HH:MM:SS) the membership will expire or has already expired on.
email_addressThe e-mail address associated with the given membership.
recurring_statusThe current recurring billing status for the membership. Status messages are subject to change. Current messages are:
  • NO REBILLING
  • BROKEN: INVALID TEMPLATE ID
  • BROKEN: TOO MANY FAILURES
  • RUNNING: INVALID TEMPLATE ID
  • RUNNING: RETRYING FAILED ATTEMPT
  • RUNNING: RETRYING AFTER DECLINE
  • RUNNING: RETRYING AFTER EXCEPTION
  • RUNNING: STOP AT NEXT DUE DATE
  • RUNNING: OK
  • STOPPED: NO MORE PAY PERIODS
  • STOPPED: NO CREDIT CARD
  • STOPPED: INVALID TEMPLATE ID
  • STOPPED: ERROR: JOB MISSING
  • STOPPED: OK
recurring_next_dateThe date (YYYY-MM-DD HH:MM:SS) scheduled for the next automatic recurring billing.
recurring_periodThe recurring billing schedule. This will either be a number of days or a special period expression. A special period expression would be an Oracle style date expression such as "last_day(sysdate)+1" for the first day of every month or "add_months(sysdate,1)" for the same day every month.
recurring_periods_leftThe number of recurring billing periods remaining.
recurring_amountThe normal dollar amount to be charged with each recurring billing.
next_recurring_amountThe dollar amount that will be charged to this customer at the next scheduled recurring billing.
Table 3.2.1

The following is an example of a typical request and response exchange for the Member Reporting Interface:

Request:

POST /gw/reports/member1.5 HTTP/1.0
Host: secure.netbilling.com
User-Agent: MyDRIClient/Version:2010.Feb.20
Content-Type: application/x-www-form-urlencoded
Content-Length: 88

account_id=123456789012&site_tag=TEST&expire_after=2004-01-01&authorization=TEST_KEYWORD


Response:

HTTP/1.1 200 OK
Connection: close
Content-Type: text/x-comma-separated-values
Content-Length: 883

"SITE_TAG","MEMBER_ID","MEMBER_STATUS","PREVIOUS_MEMBER_STATUS","STATUS_CHANGE_DATE","MEMBER_USER_NAME","SIGNUP_DATE","EXPIRE_DATE","EMAIL_ADDRESS","RECURRING_STATUS","RECURRING_NEXT_DATE","RECURRING_PERIOD","RECURRING_PERIODS_LEFT","RECURRING_AMOUNT","NEXT_RECURRING_AMOUNT"
"TEST1","100321355797","ACTIVE","","","Test","2004-08-04 17:52:04","2005-01-15 00:15:48","","BROKEN: TOO MANY FAILURES","4000-01-01 00:00:00","5","","0","0"
"TEST1","100321273872","ACTIVE","","","Trans","2004-08-04 17:50:03","2005-01-15 10:08:31","test@test.com","BROKEN: TOO MANY FAILURES","4000-01-01 00:00:00","5","","0","0"
"TEST1","100588461382","ACTIVE","","","User0001","2006-01-04 16:17:25","2006-01-10 16:17:37","","STOPPED: NO MORE PAY PERIODS","","1","0","0","0"
"TEST1","100525811991","ACTIVE","","","test01","2005-04-12 15:31:51","2005-05-12 15:31:51","x@x.com","STOPPED: OK","","5","","0","0"


3.3 Transaction Reporting Interface Response Fields

The following fields are those that will be returned following every successful request to the Transaction Reporting Interface.

FieldDetails
original_idIndicates the ID of the original transaction which was the basis for this chargeback. This field is only returned when using the disputes_after / disputes_before parameters to query disputes.
original_dateThe date of the original transaction which was the basis for this chargeback. This field is only returned when using the disputes_after / disputes_before parameters to query disputes.
return_dateThe date when a return was reported for this NBCheck transaction. This field is only returned when using the returned_after / returned_before parameters to query NBCheck returns.
return_codeThe NACHA standard reason code for this NBCheck return, such as "R01" indicating Non-Sufficient Funds. The AUTH_MSG field provides a text version of the error. This field is only returned when using the returned_after / returned_before parameters to query NBCheck returns.
trans_idThe unique 12-digit transaction ID identifying the given transaction.
trans_status_codeSingle character status code.
  • "0" - Failed transaction
  • "T" - Successful auth only transaction
  • "1" - Successful transaction
  • "I" - Pending transaction, such as an unfunded NBCheck payment
  • "R" - Refunded transaction
  • "F" - Settlement failure or returned NBCheck transaction
  • "Z" - Transaction has been undone
trans_status_msgA human readable status message corresponding to the trans_status_code above, for example "SALE/OK" or "SALE/FAILED". Please note that these messages may change over time and are not intended to be machine readable.
site_tagThe site tag, if any, this transaction was submitted in association with.
originThe origin of the given transaction. This will typically be one of the following:
  • "V-TERM" - Virtual Terminal transaction
  • "ND3.TRANS" - Direct Mode 3.x Transaction
  • "ND3.SIGNUP" - Direct Mode 3.x Membership Signup Transaction
  • "RECURRING" - Automated recurring billing transaction
  • "N2.PURCHASE" - Native Payment Form Transaction
  • "N2.SIGNUP" - Native Payment Form Membership Signup Transaction
  • "BA.TRANS" - Transaction submitted as part of a batch upload
  • "ND2.TRANS" - Direct Mode 2.x Transactions
issue_dateThe date (YYYY-MM-DD HH:MM:SS) the given transaction was issued.
capture_dateThe date (YYYY-MM-DD HH:MM:SS) a previously authorized transaction was captured. This field is blank for transactions which were not subject to delayed capture.
member_idThe unique 12-digit member ID, if any, this transaction was submitted in association with. This ID can be used to directly tie transactions to the associated membership.
amountThe dollar amount of the given transaction.
currencyThe 3 letter currency code of the processing currency. (e.g. "USD")
auth_msgA human readable approval message, for example "APPROVED 123456", or "DECLINED 05". These messages are processor specific, may change, and are not intended to be machine readable.
card_typeThe abbreviated card issuer for the transaction. For example, "VISA", "MC", "DISC", "AMEX", etc.
card_numberThe partial card number of the transaction in question. This partial card number will have all but the trailing 4 digits blocked out. For NBCheck transactions this field will contain the partial routing:account number for the transaction.
card_expireThe expiration date (MMYY) for the card number. For NBCheck transactions this field will be empty.
descriptionThe product description data associated with the given transaction. This data will be provided as it appears on the transaction details page for the transaction in the web system interface.
bill_name1The first name of the customer associated with this transaction.
bill_name2The last name of the customer associated with this transaction.
bill_streetThe billing street address associated with this transaction.
bill_cityThe billing city associated with this transaction.
bill_stateThe billing state associated with this transaction.
bill_zipThe billing ZIP code associated with this transaction.
bill_countryThe billing country associated with this transaction.
ship_name1The first name on the shipping address associated with this transaction.
ship_name2The last name on the shipping address associated with this transaction.
ship_streetThe shipping street address associated with this transaction.
ship_cityThe shipping city associated with this transaction.
ship_stateThe shipping state associated with this transaction.
ship_zipThe shipping ZIP code associated with this transaction.
ship_countryThe shipping country associated with this transaction.
customer_ipThe remote IP address associated with the given transaction. Note that this data will only be available if it (or the hostname) was provided to the system at the time the transaction was processed.
customer_hostThe hostname associated with the given transaction. Note that this data will only be available if it (or the ip address) was provided to the system at the time the transaction was processed.
customer_emailThe e-mail address of the customer as it was submitted at the time the transaction was processed.
customer_phoneThe customer's phone number (if specified) for transaction.
misc_infoThe misc info associated with the given transaction. This data will be provided as it appears on the transaction details page for the transaction in the web system interface.
user_dataThe user data associated with the given transaction. This data will be provided as it appears on the transaction details page for the transaction in the web system interface.
dispute_typeProvided when downloading transactions with charged_back_after / charged_back_before. Values can be:
  • "A" (Arbitration, funds were taken from the merchant, a typical chargeback)
  • "R" (Retrieval request, funds may be held pending resolution)
  • "W" (cardholder was proven Wrong, merchant won dispute, funds released)
There can be more than one sequential dispute_type value for a single transaction, as a dispute progresses. If so, they will be downloaded in order, and immediately following each other on separate rows, the other transaction details being identical on each row.
dispute_post_dateProvided when downloading transactions with charged_back_after / charged_back_before. Date (YYYY-MM-DD HH:MM:SS) of dispute/chargeback posting to bank. This field can appear "back-dated" due to bank data import delays.
dispute_report_dateProvided when downloading transactions with charged_back_after / charged_back_before. Date (YYYY-MM-DD HH:MM:SS) of dispute/chargeback reporting in the system. The charged_back_after / charged_back_before query parameters are matched based on this date.
dispute_msgProvided when downloading transactions with charged_back_after / charged_back_before. An acquirer-specific code or message string, indicating the reason for the dispute.
master_idFor refunds or recurring billing, this is the trans_id of the original transaction.
processorThe processor routing prefix used to process transaction. This is useful primarily for load-balanced multi-processor accounts.
affiliate_tagMerchant specified affiliate tag (if any) for transaction.
processor_rec_idThe processor record ID for transaction. Not all processors provide this. Some processors modify this value after successful settlement.
settle_idThe gateway's settlement ID for the transaction. Will be blank or 0 for unsettled transactions. Can be used as a tool for grouping transactions together by batch, since transactions in settled in a batch will all have the same settle_id.
card_flagsWill be P if the card is a prepaid card, blank otherwise.
Table 3.3.1

The following is an example of a typical request and response exchange for the Transaction Reporting Interface:

Request:

POST /gw/reports/transaction1.5 HTTP/1.0
Host: secure.netbilling.com
User-Agent: MyDRIClient/Version:2010.Feb.20
Content-Type: application/x-www-form-urlencoded
Content-Length: 97

account_id=200274083904&site_tag=CLOTHING&transactions_after=2006-03-22&authorization=OFFICE_1234


Response:

HTTP/1.1 200 OK
Connection: close
Content-Type: text/plain
Content-Length: 1627

"TRANS_ID","TRANS_STATUS_MSG","TRANS_STATUS_CODE","SITE_TAG","ORIGIN","ISSUE_DATE","MEMBER_ID","AMOUNT","AUTH_MSG","CARD_TYPE","CARD_NUMBER","CARD_EXPIRE","DESCRIPTION","BILL_NAME1","BILL_NAME2","CUSTOMER_IP","CUSTOMER_HOST","CUSTOMER_EMAIL","MISC_INFO","USER_DATA"
"200592674898","SALE/OPEN","1","CLOTHING","ND3.TRANS","2006-03-23 12:54:40","200592674899","19.95","TEST APPROVED","VISA","xxxxxxxxxxxx1111","0110","30 day subscription.","John","Smith","255.255.255.0","clothing.com","JohnSmith@anywhere.com","Special offer.","Customer number: 1237 Order number: 16"
"200592920662","SALE/OPEN","1","CLOTHING","ND2.TRANS","2006-03-24 10:32:50","200592937042","14.95","TEST APPROVED","VISA","xxxxxxxxxxxx1111","0408","30 day subscription.","Dave","Rowan","255.255.255.0","clothing.com","DaveRowan@somewhere.com","Special offer.",""
"200593707010","SALE/OPEN","1","CLOTHING","V-TERM","2006-03-24 14:33:36","","9.95","TEST APPROVED","VISA","xxxxxxxxxxxx1111","0407","30 day subscription.","Jake","Williams","","","JakeWilliams@billing.net","Special offer.",""
"200593707015","SALE/OPEN","1","CLOTHING","ND2.TRANS","2006-03-24 14:39:08","200593723395","4.95","TEST APPROVED","VISA","xxxxxxxxxxxx1111","0708","10 day subscription.","Kelly","Dale","124.54.163.0","school.somewhere.edu","KellyDale@school.edu","Special sale offer.",""
"200593641490","SALE/OPEN","1","CLOTHING","ND3.TRANS","2006-03-24 14:39:20","200593641491","7.75","TEST APPROVED","VISA","xxxxxxxxxxxx1111","0211","T-shirt.","Clara","Williams","147.22.255.0","access.internet.com","ClaraWilliams@access.net","2 day sale only.","Customer number: 1947 Order number: 12"


4.0 Exception Handling

Exceptions result from invalid requests, excessive usage or other abnormal conditions. Exceptions are returned as HTTP header error codes, and would typically trigger an exception in the client programming language. HTTP codes other than 200 indicate an exception. The HTTP message will contain a brief description.

4.1 Exception Codes and Handling

Clients should be designed to treat all non-200 HTTP codes as exceptions and display or log the code anandd message. It's not recommended to implement individual handlers for all possible exception codes. A catch-all handler is usually sufficient. Sometimes special handling of an exception is useful, such as for the 503 code described below. Test whether the HTTP error code matches a particular code seen previously. Note that new exception codes are added, and text messages are subject to change.

One important error code, 503 Service Unavailable, does require special handling. When a 503 code is received, the client will also receive a HTTP Retry-After header. This header indicates the number of seconds the client must wait before resubmitting the request. This is part of the HTTP/1.1 protocol standard described in RFC2616, but is not automatically supported by all client libraries.

Example 1:

HTTP/1.1 503 Service Unavailable
Connection: close
Content-Type: text/plain
Retry-After: 60

503 Service Unavailable

Example 2:

HTTP/1.1 456 No valid authorization for requested site_tag(s)
Connection: close
Content-Type: text/plain

456 No valid authorization for requested site_tag(s)

Note: If you're testing the interface using a web-browser and not a programming language API, you may not be able to see error messages. This is because some browsers display a generic error page, or a blank page, regardless of what error message was returned from the server.