Why am I encountering a 'TypeError' when calling the 'action/run' API for a configured Account in Pipedream?

Help
1

This topic was automatically generated from Slack. You can find the original thread here.

Hi -

I am having trouble calling the action/run API for a configured Account. When I make the following REST call:

https://api.pipedream.com/v1/connect/proj_XYZ/actions/run

Body:
{
    "id": "openweather_api-get-weather-forecast-by-location",
    "configured_props": {
        "openweather_api": {
            "authProvisionId": "app_ABCD"
        },
        "city": "Redwood City",
        "stateCode": "CA",
        "countryCode": "US"
    }
}

I get the following error:

"err": {
                "name": "TypeError",
                "message": "Cannot read properties of undefined (reading 'api_key')",
                "stack": "TypeError: Cannot read properties of undefined (reading 'api_key')\n    at Object.run (file:///tmp/__pdg__/dist/code/aff23efbe30bdcdcda41b2abe507c93f0e20aa908365d5e347ce6517299144e8/code/actions/get-weather-forecast-by-location/get-weather-forecast-by-location.mjs:59:45)\n    at file:///var/task/component_maker.mjs:165:42\n    at captureObservations (/var/task/node_modules/@lambda-v2/component-runtime/src/captureObservations.js:28:11)\n    at run (file:///var/task/component_maker.mjs:155:26)\n    at async MessagePort.anonymous (file:///var/task/component_maker.mjs:193:9)"
            }

The authProvisionId points to the configured account (OpenWeatherAPI) that works fine in a workflow.

Thoughts on what I’m doing wrong? Thanks!

2

2 ways to troubleshoot that I’d start with —

  1. Test in the SDK playground and compare the payloads: One SDK, thousands of API integrations
  2. Check out the troubleshooting section in the docs, specifically this section: Pre-built tools for your app or agent — Pipedream
3

Thanks . I looked at the demo app and the payloads look the same. I think the issue is the fact that its unable to find the account.

The account exists, but when I call the /accounts API (connect and non-connect APIs), nothing is returned. I created the account via the UI. I do not understand how to associate it to a specific project.

image.png
image.png2208×668 41 KB

4

Ah gotcha, yea that can be a bit confusing. Check out the managed auth quickstart: Managed Auth Quickstart — Pipedream

5
  • Is their a headless option? Can I generate Connect tokens iin an automated, headless fashion? I’d like to stick with REST calls and the standard OAuth flow, but it does not appear to be available (or documented). Thanks!
6

How will your users connect their accounts?

7

Connect Tokens are generated via API, but the end user needs to connect their account somehow.

8

In this scenario we’d like to use a Service Account rather than an actual end user.

9

Ah, gotcha. Which API(s) are you looking at that support a service account, and how would you be capturing those credentials?

10

We’ll be capturing those credentials in our application (for service accounts). I’m using OpenWeather for testing which is purely key-based.

If this is an anti-pattern please let me know.

11

Yea it’s not something that Connect is well-suited for today. The Connect API right now relies on the end user providing the credentials and Pipedream storing them on our end.

12

We will have other sources that where OAuth will be required.

13

Gotcha - thanks!

14

If this is a critical use case for y’all happy to hear more about exactly what you’d need, so we can prioritize support.

15

Many of the integration we have use service accounts rather than user credentials. Using OpenWeather as an example, ideally we’d have API access to create the account. We will collect the credentials from the administrator and pass them to you when configuring the account. Credentials typically take the for of tokens or the OAuth client credentials grant flow.

Once the account is registered, we’d like the ability run/execute actions associated with the account - e.g. get the weather forecast for a specific location. We’d have a token with sufficient scope/permissions to invoke operations on the account on behalf of the customer.

Essentially we’d like a “headless” option where we configure the account programmatically and then invoke it at some later date.

There are use-cases where the end user will also need to provide credentials.

We’d like to try and use 1 product for both solutions.

16

Yea, I get it, generally makes sense. Going to DM you some follow-up questions I have.