# Postman Echo

> Postman's own free service for testing HTTP requests. Send a request and get back exactly what arrived - the query values, the headers and the data, as the server received them - so you can see what a half-built workflow is really sending before you point it anywhere that matters. It will also misbehave on request: ask it for a 404 or a 500 to watch your retry and fallback paths run, ask it to take ten seconds to answer, ask it to return particular headers, or check that a username and password arrive intact. It can tell you the public address your workflows call out from, too, which is the one to put on another service's allow-list. Nothing is stored and nothing is private. No account or API key required.

App · Utilities · 6 actions. Web page: https://docs.lodol.com/docs/integrations/postman-echo

## Actions

### Get your outbound IP address

Find out which public address your workflows call out from. This is the address another service sees, and the one to put on its allow-list when it only accepts calls from addresses you have named. No account or API key required.

**Inputs**: None.

**Outputs**

- `ip_address` (text): The public address the request came from, as the service saw it.

**Example output**

```json
{
  "ip_address": "34.122.87.19"
}
```

### Send a test request

Send a request to Postman Echo and get back exactly what it received: the query values, the headers and the data, as they arrived. The step to point a half-built workflow at when you need to see what it is really sending before you send it anywhere that matters. No account or API key required.

**Inputs**

- Method (`method`, text): How to send the request. GET is the plain fetch and carries no data; the other four do. One of: `GET`, `POST`, `PUT`, `PATCH`, `DELETE`. Default: `GET`.
- Query values (`query`, object): Optional. Values to add to the end of the web address, as names and values. They come back under 'query' so you can see they arrived.
- Headers (`headers`, object): Optional. Headers to send with the request, as names and values. Useful for checking that an Authorization or tracing header your workflow builds arrives intact.
- Data to send (`data`, object): Optional. The data to put in the request body, as field names and values. Sent as JSON. Leave blank for a GET, which carries no data.

**Outputs**

- `body` (object): The data the service received, as it parsed it. Null for a request that carried none.
- `headers` (object): Every header the service received - the ones you set and the ones added automatically (host, user-agent). Names arrive in lower case.
- `method` (text): The method the request was sent with.
- `query` (object): The query values the service received, as names and values.
- `url` (text): The full address the service was reached at, including any query values.

**Example output**

```json
{
  "body": {
    "customer": "Ada Lovelace",
    "total": 42
  },
  "headers": {
    "content-type": "application/json",
    "host": "postman-echo.com",
    "user-agent": "Lodol-PostmanEcho-Integration/1.0 (+https://lodol.ai; integrations@lodol.ai)",
    "x-request-source": "lodol-workflow"
  },
  "method": "POST",
  "query": {
    "order_id": "1042"
  },
  "url": "https://postman-echo.com/post?order_id=1042"
}
```

### Test a response code

Ask Postman Echo to answer with one particular response code, so you can see what the rest of your workflow does about it. Pick a success code and the step succeeds. Pick an error code and the step fails with that error - which is the point: it is the only way to watch a retry, a fallback or an alert path actually run. No account or API key required.

**Inputs**

- Response code (`status_code`, text): The code to ask for. The three in the 200s succeed; the rest fail the step, the way a real API answering that way would. One of: `200` (200 OK), `201` (201 Created), `204` (204 No content), `400` (400 Bad request), `401` (401 Unauthorized), `403` (403 Forbidden), `404` (404 Not found), `429` (429 Too many requests), `500` (500 Server error), `503` (503 Service unavailable). Default: `200`.

**Outputs**

- `meaning` (text): What that code means, in words - 'OK', 'Created', 'No content'.
- `response_time_ms` (number): How long the round trip took, in milliseconds. Null if the service did not report it.
- `status_code` (number): The code the service answered with.

**Example output**

```json
{
  "meaning": "OK",
  "response_time_ms": 38.4,
  "status_code": 200
}
```

### Test a slow response

Ask Postman Echo to take a few seconds before it answers, so you can see how your workflow handles a service that has gone slow rather than gone down. Waits up to ten seconds, which is as long as the service will hold a request. No account or API key required.

**Inputs**

- Seconds to wait (`seconds`, number): How long the service should take before answering. Between 1 and 10 seconds, which is its limit. From 1 to 10. Default: `3`.

**Outputs**

- `response_time_ms` (number): How long the round trip took, in milliseconds. Null if the service did not report it.
- `seconds_requested` (number): The wait this step asked for.
- `seconds_waited` (number): The wait the service reports it took. The same number unless the service capped it.

**Example output**

```json
{
  "response_time_ms": 3041.7,
  "seconds_requested": 3,
  "seconds_waited": 3
}
```

### Test a username and password

Send a username and password the standard way and see whether the server accepted them. Postman Echo accepts one published test pair and rejects everything else, so this proves the credentials your workflow builds leave it intact and arrive readable. Being rejected is reported, not treated as a failure, so a workflow can branch on it. No account or API key required.

**Inputs**

- Username (`username`, text): The username to send. Postman Echo's published test username is filled in already. Default: `postman`.
- Password (`password`, text): The password to send. Postman Echo's published test password is filled in already - it is public, and the only one it accepts. Default: `password`.

**Outputs**

- `authenticated` (true/false): True when the server accepted the username and password. This is the field to branch on.
- `message` (text): What happened, in a sentence.
- `status_code` (number): The code the service answered with: 200 when accepted, 401 when rejected.

**Example output**

```json
{
  "authenticated": true,
  "message": "Postman Echo accepted 'postman'. The username and password reached the server intact.",
  "status_code": 200
}
```

### Test response headers

Ask Postman Echo to send back headers of your choosing, and see which of them survived the trip. The way to check that a header a workflow depends on reading - a rate-limit count, a request id, a signature - really does come back. No account or API key required.

**Inputs**

- Headers to send back (`headers`, object, required): The headers Postman Echo should put on its response, as names and values. At least one.

**Outputs**

- `headers` (object): The headers that came back, read off the response itself rather than its body.
- `missing_headers` (list): The names that did not come back.
- `returned_all` (true/false): True when every header asked for came back. This is the field to branch on.

**Example output**

```json
{
  "headers": {
    "X-Rate-Limit-Remaining": "97",
    "X-Request-Id": "b1f4c0a2"
  },
  "missing_headers": [],
  "returned_all": true
}
```