The HTTP `GET` request method is meant to retrieve data from a server. The data is identified by a unique URI (Uniform Resource Identifier). A `GET` request can pass parameters to the server using "Query String Parameters". For example, in the following request, > http://example.com/hi/there?hand=wave The parameter "hand" has the value "wave". This endpoint echoes the HTTP headers, request parameters and the complete URI requested.

There are no body request

                                                  {
  "foo1": "bar1",
  "foo2": "bar2  "
}
                                                

The HTTP `POST` request method is meant to transfer data to a server (and elicit a response). What data is returned depends on the implementation of the server. A `POST` request can pass parameters to the server using "Query String Parameters", as well as the Request Body. For example, in the following request, > POST /hi/there?hand=wave > > <request-body> The parameter "hand" has the value "wave". The request body can be in multiple formats. These formats are defined by the MIME type of the request. The MIME Type can be set using the ``Content-Type`` HTTP header. The most commonly used MIME types are: * `multipart/form-data` * `application/x-www-form-urlencoded` * `application/json` This endpoint echoes the HTTP headers, request parameters, the contents of the request body and the complete URI requested.

This is expected to be sent back as part of response body.

                                                  {}
                                                

The HTTP `POST` request method is meant to transfer data to a server (and elicit a response). What data is returned depends on the implementation of the server. A `POST` request can pass parameters to the server using "Query String Parameters", as well as the Request Body. For example, in the following request, > POST /hi/there?hand=wave > > <request-body> The parameter "hand" has the value "wave". The request body can be in multiple formats. These formats are defined by the MIME type of the request. The MIME Type can be set using the ``Content-Type`` HTTP header. The most commonly used MIME types are: * `multipart/form-data` * `application/x-www-form-urlencoded` * `application/json` This endpoint echoes the HTTP headers, request parameters, the contents of the request body and the complete URI requested when data is sent as a form parameter.

There are no body request

                                                  {}
                                                

The HTTP `PUT` request method is similar to HTTP `POST`. It too is meant to transfer data to a server (and elicit a response). What data is returned depends on the implementation of the server. A `PUT` request can pass parameters to the server using "Query String Parameters", as well as the Request Body. For example, in the following raw HTTP request, > PUT /hi/there?hand=wave > > <request-body>

This is expected to be sent back as part of response body.

                                                  {}
                                                

The HTTP `PATCH` method is used to update resources on a server. The exact use of `PATCH` requests depends on the server in question. There are a number of server implementations which handle `PATCH` differently. Technically, `PATCH` supports both Query String parameters and a Request Body. This endpoint accepts an HTTP `PATCH` request and provides debug information such as the HTTP headers, Query String arguments, and the Request Body.

This is expected to be sent back as part of response body.

                                                  {}
                                                

The HTTP `DELETE` method is used to delete resources on a server. The exact use of `DELETE` requests depends on the server implementation. In general, `DELETE` requests support both, Query String parameters as well as a Request Body. This endpoint accepts an HTTP `DELETE` request and provides debug information such as the HTTP headers, Query String arguments, and the Request Body.

This is expected to be sent back as part of response body.

                                                  {}
                                                

A `GET` request to this endpoint returns the list of all request headers as part of the response JSON. In Postman, sending your own set of headers through the [Headers tab](https://www.getpostman.com/docs/requests#headers?source=echo-collection-app-onboarding) will reveal the headers as part of the response.

There are no body request

                                                  {}
                                                

This endpoint causes the server to send custom set of response headers. Providing header values as part of the URL parameters of a `GET` request to this endpoint returns the same as part of response header. To send your own set of headers, simply add or replace the the URL parameters with your own set.

There are no body request

                                                  {
  "foo1": "bar1",
  "foo2": "bar2  "
}
                                                

This endpoint simulates a **basic-auth** protected endpoint. The endpoint accepts a default username and password and returns a status code of `200 ok` only if the same is provided. Otherwise it will return a status code `401 unauthorized`. > Username: `postman` > > Password: `password` To use this endpoint, send a request with the header `Authorization: Basic cG9zdG1hbjpwYXNzd29yZA==`. The cryptic latter half of the header value is a base64 encoded concatenation of the default username and password. Using Postman, to send this request, you can simply fill in the username and password in the "Authorization" tab and Postman will do the rest for you. To know more about basic authentication, refer to the [Basic Access Authentication](https://en.wikipedia.org/wiki/Basic_access_authentication) wikipedia article. The article on [authentication helpers](https://www.getpostman.com/docs/helpers#basic-auth?source=echo-collection-app-onboarding) elaborates how to use the same within the Postman app.

There are no body request

                                                  {}
                                                

This endpoint sends a hashed Digest Authorization header to gain access to a valid `200 Ok` response code. In Postman, it uses the stored [global variables](https://www.getpostman.com/docs/environments#gloval-variables?source=echo-collection-app-onboarding), `echo_digest_realm` and `echo_digest_nonce`, to generate the hashed authorisation header. Within Postman, for this request to successfully authenticate, running the previous request "DigestAuth Request" stores the relevant information within the global variables.

There are no body request

                                                  {}
                                                

OAuth1.0a is a specification that defines a protocol that can be used by one service to access "protected" resources (endpoints) on another service. A major part of OAuth1.0 is HTTP Request Signing. This endpoint allows you to check whether the request calculation works properly in the client. The endpoint supports the HTTP ``Authorization`` header. In case the signature verification fails, the endpoint provides the four debug values, * ``base_uri`` * ``normalized_param_string`` * ``base_string`` * ``signing_key`` For more details about these parameters, check the [OAuth1.0a Specification](http://oauth.net/core/1.0a/) In order to use this endpoint, you can set the following values: > Consumer Key: ``RKCGzna7bv9YD57c`` > > Consumer Secret: ``D+EdQ-gs$-%@2Nu7`` If you are using Postman, also check the "Add params to header" and "Auto add parameters" boxes.

There are no body request

                                                  {}
                                                

The cookie setter endpoint accepts a list of cookies and their values as part of URL parameters of a `GET` request. These cookies are saved and can be subsequently retrieved or deleted. The response of this request returns a JSON with all cookies listed. To set your own set of cookies, simply replace the URL parameters "foo1=bar1&foo2=bar2" with your own set of key-value pairs.

There are no body request

                                                  {
  "foo1": "bar1",
  "foo2": "bar2  "
}
                                                

Use this endpoint to get a list of all cookies that are stored with respect to this domain. Whatever key-value pairs that has been previously set by calling the "Set Cookies" endpoint, will be returned as response JSON.

There are no body request

                                                  {}
                                                

One or more cookies that has been set for this domain can be deleted by providing the cookie names as part of the URL parameter. The response of this request is a JSON containing the list of currently set cookies.

There are no body request

                                                  {}
                                                

This endpoint allows one to instruct the server which status code to respond with. Every response is accompanied by a status code. The status code provides a summary of the nature of response sent by the server. For example, a status code of `200` means everything is okay with the response and a code of `404` implies that the requested URL does not exist on server. A list of all valid HTTP status code can be found at the [List of Status Codes](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes) wikipedia article. When using Postman, the response status code is described for easy reference. Note that if an invalid status code is requested to be sent, the server returns a status code of `400 Bad Request`.

There are no body request

                                                  {}
                                                

Using this endpoint one can configure how long it takes for the server to come back with a response. Appending a number to the URL defines the time (in seconds) the server will wait before responding. Note that a maximum delay of 10 seconds is accepted by the server.

There are no body request

                                                  {}
                                                

A simple `GET` request to return the IP address of the source request in the following `JSON` format: ```json { ip: "request-ip-address" } ```

There are no body request

                                                  {}
                                                

A simple `GET` request to `/time/now` to return the current timestamp as a UTC string. ``` Fri, 04 Nov 2016 09:00:46 GMT ```

There are no body request

                                                  {}
                                                

A simple `GET` request to `/time/valid` to determine the validity of the timestamp, (current by default). This endpoint accepts `timestamp`, `locale`, `format`, and `strict` query parameters to construct the date time instance to check against. Responses are provided in JSON format, with a valid key to indicate the result. The response code is `200`. ``` { valid: true/false } ```

There are no body request

                                                  {
  "timestamp": "2016-10-10  "
}
                                                

A simple `GET` request to `/time/format` to convert the timestamp to any desired valid format. This endpoint accepts `timestamp`, `locale`, `format`, and `strict` query parameters to construct the date time instance to check against. Responses are provided in JSON format, with a `format` key to indicate the result. The response code is `200` for valid query parameters, and `400` otherwise. ``` { format: "formatted-timestamp" } ```

There are no body request

                                                  {
  "timestamp": "2016-10-10",
  "format": "mm  "
}
                                                

A simple `GET` request to `/time/unit` to extract the specified timestamp unit (as provided in the `unit` query parameter). The default unit returned is the `year`. This endpoint accepts `timestamp`, `locale`, `format`, and `strict` query parameters to construct the date time instance to check against. Responses are provided in JSON format, with a `unit` key to indicate the result. The response code is `200` for valid query parameters, and `400` otherwise. ``` { unit: "extracted-timestamp-unit" } ```

There are no body request

                                                  {
  "timestamp": "2016-10-10",
  "unit": "day  "
}
                                                

A simple `GET` request to `/time/add` to add units of time to the specified / current timestamp (as provided in the `years`, `months`, `days`, `hours`, `minutes`, `seconds`, and `milliseconds` query parameters). This endpoint accepts `timestamp`, `locale`, `format`, and `strict` query parameters to construct the date time instance to check against. Responses are provided in JSON format, with a `sum` key to indicate the result. The response code is `200` for valid query parameters, and `400` otherwise. ``` { sum: "sum of (provided / current) and provided timestamps" } ```

There are no body request

                                                  {
  "timestamp": "2016-10-10",
  "years": "100  "
}
                                                

A simple `GET` request to `/time/subtract` to subtract units of time from the specified / current timestamp (as provided in the `years`, `months`, `days`, `hours`, `minutes`, `seconds`, and `milliseconds` query parameters). This endpoint accepts `timestamp`, `locale`, `format`, and `strict` query parameters to construct the date time instance to check against. Responses are provided in JSON format, with a `difference` key to indicate the result. The response code is `200` for valid query parameters, and `400` otherwise. ``` { difference: "difference between (provided / current) and provided timestamps" } ```

There are no body request

                                                  {
  "timestamp": "2016-10-10",
  "years": "50  "
}
                                                

A simple `GET` request to `/time/start` to return a relative timstamp in the past from the specified / current timestamp (as provided in the `unit` query parameter). For instance, if the `unit` has been specified as `month`, the returned timestamp would indicate the beginning of the current month. Similar results are returned for other units of time, like: `years`, `months`, `days`, `hours`, `minutes`, `seconds`, and `milliseconds` This endpoint accepts `timestamp`, `locale`, `format`, and `strict` query parameters to construct the date time instance to check against. Responses are provided in JSON format, with a `start` key to indicate the result. The response code is `200` for valid query parameters, and `400` otherwise. ``` { start: "A timestamp from the past, depending on the `unit` specified" } ```

There are no body request

                                                  {
  "timestamp": "2016-10-10",
  "unit": "month  "
}
                                                

A simple `GET` request to `/time/object` to return the current / provided timestamp as a JSON object. For instance, if the `unit` has been specified as `month`, the returned timestamp would indicate the beginning of the current month. Similar results are returned for other units of time, like: `years`, `months`, `days`, `hours`, `minutes`, `seconds`, and `milliseconds` This endpoint accepts `timestamp`, `locale`, `format`, and `strict` query parameters to construct the date time instance to check against. Responses are provided in JSON format. The response code is `200` for valid query parameters, and `400` otherwise. ``` { years: 2016, months: 10, days: 10, hours: 23, minutes: 34, seconds: 20, milliseconds: 980 } ```

There are no body request

                                                  {
  "timestamp": "2016-10-10  "
}
                                                

A simple `GET` request to `/time/before` to check if the provided timestamps is before a comparison `target` (query parameter). This endpoint accepts `timestamp`, `locale`, `format`, `strict`, and `target` query parameters to construct the date time instance to check against. Responses are provided in JSON format, with a `before` key to indicate the result. The response code is `200` for valid query parameters, and `400` otherwise. ``` { before: true/false } ```

There are no body request

                                                  {
  "timestamp": "2016-10-10",
  "target": "2017-10-10  "
}
                                                

A simple `GET` request to `/time/after` to check if the provided timestamps is after a comparison `target` (query parameter). This endpoint accepts `timestamp`, `locale`, `format`, `strict`, and `target` query parameters to construct the date time instance to check against. Responses are provided in JSON format, with a `after` key to indicate the result. The response code is `200` for valid query parameters, and `400` otherwise. ``` { after: true/false } ```

There are no body request

                                                  {
  "timestamp": "2016-10-10",
  "target": "2017-10-10  "
}
                                                

A simple `GET` request to `/time/between` to check if the provided timestamp is between a range specified by the `start` and `end` query parameters. A resolution limit can also be specified by the `unit` query parameter. For instance, for a resolution `unit` of `month`, `2016-10-05` does lie between `2016-11-02` and `2016-09-01`. This endpoint also accepts `timestamp`, `locale`, `format`, `strict`, and `target` query parameters to construct the date time instance to check against. Responses are provided in JSON format, with a `between` key to indicate the result. The response code is `200` for valid query parameters, and `400` otherwise. ``` { between: true/false } ```

There are no body request

                                                  {
  "timestamp": "2016-10-10",
  "start": "2017-10-10",
  "end": "2019-10-10  "
}
                                                

A simple `GET` request to `/time/leap` to check if the provided/current timestamp belongs to a leap year. This endpoint also accepts `timestamp`, `locale`, `format`, `strict`, and `target` query parameters to construct the date time instance to check against. Responses are provided in JSON format, with a `leap` key to indicate the result. The response code is `200` for valid query parameters, and `400` otherwise. ``` { leap: true/false } ```

There are no body request

                                                  {
  "timestamp": "2016-10-10  "
}
                                                

Performing a simple `GET` request to this endpoint returns status code `401 Unauthorized` with `WWW-Authenticate` header containing information to successfully authenticate subsequent requests. The `WWW-Authenticate` header must be processed to extract `realm` and `nonce` values to hash subsequent requests. When this request is executed within Postman, the script attached with this request does the hard work of extracting realm and nonce from the header and set it as [global variables](https://www.getpostman.com/docs/environments#global-variables?source=echo-collection-app-onboarding) named `echo_digest_nonce` and `echo_digest_realm`. These variables are re-used in subsequent request for seamless integration of the two requests.

There are no body request

                                                  {}