Thanks to visit codestin.com
Credit goes to pipedream.com

Integrate and automate any API using Pipedream workflows. Use app specific pre-built actions, or an HTTP request action for a no code interface. If you need more control over error handling, then use your same connected accounts with code in Node.js or Python.

​
Pre-built actions

Pre-built actions are the most convenient option for integrating your workflow with an API. Pre-built actions can use your connected accounts to perform API requests, and are configured through props. Pre-built actions are the fastest way to get started building workflows, but they may not fit your use case if a prop is missing or is handling data in a way that doesn’t fit your needs. For example, to send a message using Slack just search for Slack and use the Send Message to a Public Channel action:
Then connect your Slack account, select a channel and write your message:
Now with a few clicks and some text you’ve integrated Slack into a Pipedream workflow.
Pre-built actions are open sourceAll pre-built actions are published from the Pipedream Component Registry, so you can read and modify their source code. You can even publish your own from Node.js code steps privately to your own workspace.

​
HTTP Request Action

The HTTP request action is the next most convenient option. Use a Postman-like interface to configure an HTTP request - including the headers, body, and even connecting an account.
Selecting this action will display an HTTP request builder, with the Slack app slot to connect your account with.
Once you connect your account to the step, it will automatically configure the authorization headers to match. For example, the Slack API expects a Bearer token with the Authorization header. So Pipedream automatically configures this HTTP request to pass your token to that specific header:
The configuration of the request and management of your token is automatically handled for you. So you can simply modify the request to match the API endpoint you’re seeking to interact with.

​
Adding apps to an HTTP request builder action

You can also attach apps to the Send any HTTP Request action from the action selection menu. After adding a new step to your workflow, select the Send any HTTP Request action:
Then within the HTTP request builder, click the Autorization Type dropdown to select a method, and click Select an app:
Then you can choose Slack as the service to connect the HTTP request with:
The HTTP request action will automatically be configured with the Slack connection, you’ll just need to select your account to finish the authentication. Then it’s simply updating the URL to send a message which is https://slack.com/api/chat.postMessage:
Finally modify the body of the request to specify the channel and message for the request:
HTTP Request actions can be used to quickly scaffold API requests, but are not as flexible as code for a few reasons:
  • Conditionally sending requests - The HTTP request action will always request, to send requests conditionally you’ll need to use code.
  • Workflow execution halts - if an HTTP request fails, the entire workflow cancels
  • Automatically retrying - $.flow.retry isn’t available in the HTTP Request action to retry automatically if the request fails
  • Error handling - It’s not possible to set up a secondary action if an HTTP request fails.

​
HTTP Requests in code

When you need more control, use code. You can use your connected accounts with Node.js or Python code steps. This gives you the flexibility to catch errors, use retries, or send multiple API requests in a single step. First, connect your account to the code step:

​
Conditionally sending an API Request

You may only want to send a Slack message on a certain condition, in this example we’ll only send a Slack message if the HTTP request triggering the workflow passes a special variable: steps.trigger.event.body.send_message 
import { axios } from "@pipedream/platform"
 
export default defineComponent({
  props: {
    slack: {
      type: "app",
      app: "slack",
    }
  },
  async run({steps, $}) {
    // only send the Slack message if the HTTP request has a `send_message` property in the body
    if(steps.trigger.body.send_message) {
      return await axios($, {
        headers: {
          Authorization: `Bearer ${this.slack.$auth.oauth_access_token}`,
        },
 
        url: `https://slack.com/api/chat.postMessage`,
 
        method: 'post',
        data: {
          channel: 'C123456',
          text: 'Hi from a Pipedream Node.js code step'
        }
      })
    }
  },
})

​
Error Handling

The other advantage of using code is handling error messages using try...catch blocks. In this example, we’ll only send a Slack message if another API request fails: 
import { axios } from "@pipedream/platform"
 
export default defineComponent({
  props: {
    openai: {
      type: "app",
      app: "openai"
    },
    slack: {
      type: "app",
      app: "slack",
    }
  },
  async run({steps, $}) {
    try {
      return await axios($, {
        url: `https://api.openai.com/v1/completions`,
        method: 'post',
        headers: {
          Authorization: `Bearer ${this.openai.$auth.api_key}`,
        },
        data: {
          "model": "text-davinci-003",
          "prompt": "Say this is a test",
          "max_tokens": 7,
          "temperature": 0
        }
      })
    } catch(error) {
      return await axios($, {
        url: `https://slack.com/api/chat.postMessage`,
        method: 'post',
        headers: {
          Authorization: `Bearer ${this.slack.$auth.oauth_access_token}`,
        },
        data: {
          channel: 'C123456',
          text: `OpenAI returned an error: ${error}`
        }
      })
    }
  },
})
Subscribing to all errorsYou can use a subscription to subscribe a workflow to all errors through the $errors channel, instead of handling each error individually.

​
Automatically retrying an HTTP request

You can leverage $.flow.rerun within a try...catch block in order to retry a failed API request. See the example in the $.flow.rerun docs for Node.js.

​
Platform axios

​
Why @pipedream/platform axios?

axios is an HTTP client for Node.js (see these docs for usage examples). axios has a simple programming API and works well for most use cases. But its default error handling behavior isn’t easy to use. When you make an HTTP request and the server responds with an error code in the 4XX or 5XX range of status codes, axios returns this stack trace:
This only communicates the error code, and not any other information (like the body or headers) returned from the server. Pipedream publishes an axios wrapper as a part of the @pipedream/platform package. This presents the same programming API as axios, but implements two helpful features:
  1. When the HTTP request succeeds (response code < 400), it returns only the data property of the response object — the HTTP response body. This is typically what users want to see when they make an HTTP request:
  1. When the HTTP request fails (response code >= 400), it displays a detailed error message in the Pipedream UI (the HTTP response body), and returns the whole axios response object so users can review details on the HTTP request and response:

​
Using @pipedream/platform axios in component actions

To use @pipedream/platform axios in component actions, import it: 
import { axios } from "@pipedream/platform"
@pipedream/platform axios uses methods provided by the $ object, so you’ll need to pass that as the first argument to axios when making HTTP requests, and pass the standard axios request config as the second argument. Here’s an example action: 
import { axios } from "@pipedream/platform"
 
export default {
  key: "my-test-component",
  name: "My Test component",
  version: "0.0.1",
  type: "action",
  async run({ $ }) {
    return await axios($, {
      url: "https://httpstat.us/200",
    })
  }
}