This topic was automatically generated from Slack. You can find the original thread here.
Hi, I’m building the frontend of an application where users are able to create, deploy and edit Pipedream triggers. The create/deploy steps are working well, but I’m really having trouble working out how to piece together API calls to update a deployed trigger. As far as I can tell the steps should be:
Get the deployed trigger with GET /deployed-triggers/{trigger_id} (this part works fine, kind of. I get CORS errors when using this endpoint but not when using any other endpoint)
Get the generic trigger (or component, it shouldn’t matter) with GET /triggers/{id}
a. I can’t get this call to work, because the component_id (e.g. sc_12345) returned when getting a deployed trigger doesn’t seem to be the ID that this endpoint needs
b. This endpoint seems to require a key instead, e.g. 'slack-new-user-mention', and as far as I can tell there’s no way to get this key from the deployed trigger endpoint
Render the form using the trigger’s configurable/configured props. Make calls to POST /components/configure to load remote options
a. This also doesn’t work because it seems to require a component key that I am unable to get from the deployed-triggers endpoint
It all seems to boil down to the fact that I have no way to link a deployed trigger to its component key. Am I missing something?
Yes, your question makes sense, and I can help clarify what’s happening and suggest next steps. ### Summary of Your Issue You’re building a frontend to manage Pipedream triggers (create, deploy, edit). You can create and deploy triggers, but you’re struggling to update/edit a deployed trigger because: - When you fetch a deployed trigger (GET /deployed-triggers/{trigger_id}), you get a component_id (like sc_12345). - The endpoint to fetch the generic trigger/component (GET /triggers/{id}) seems to require a “key” (like 'slack-new-user-mention'), not the component_id. - You can’t find a way to map the component_id to the required “key”. - This prevents you from rendering the form and loading remote options, since those also require the component key. ### Does This Make Sense? Yes, this is a common pain point when working with APIs that have both internal IDs and public keys/names for components. If the deployed trigger only returns a component_id and not the “key”, and there’s no documented way to map between them, it blocks your ability to fetch the component definition and render the edit form. ### What You Can Do #### 1. Double-Check the Deployed Trigger Response - Sometimes, the deployed trigger object may have a key, slug, or similar property in addition to the component_id. Double-check the full JSON response for any field that might be the key you need. #### 2. Look for a “List Components” or “List Triggers” Endpoint - If there’s an endpoint like GET /triggers or GET /components, you might be able to fetch all available triggers/components and build a mapping from component_id to key in your frontend. - This would let you look up the key when you have the component_id. #### 3. Contact Pipedream Support - If the API truly does not expose a way to map component_id to the component key, this is a gap in the API. You should contact Pipedream support and request: - That the deployed trigger response includes the component key. - Or, that an endpoint is provided to map component_id to key. - You can reach them at Support - Pipedream. #### 4. CORS Errors - The CORS errors you see on GET /deployed-triggers/{trigger_id} but not on other endpoints may be a bug or a misconfiguration on the API server. This is also worth reporting to support. ### Next Steps - Check the deployed trigger response for any field that might be the component key. - Check for a “list” endpoint to build your own mapping. - Contact support if neither of the above work. — Sorry you’re running into this! If you need more help or want to talk to someone at Pipedream, please visit Support - Pipedream.
Thanks for trying, but none of this helps - the generic list endpoints only return keys (no IDs), and the deployed-trigger endpoint only returns an ID (no keys).
If someone sees this, I’d appreciate some help. I’m pretty sure we have an enterprise account (or a trial? we’re still ramping up with Pipedream) and this is blocking us.
Hi . Like you mentioned, it looks like GET /connect/triggers/{component_id} currently supports passing component key, but not ID, as the component_id parameter.
As a workaround, I think you could use the non-Connect REST API’s GET /components/{key|id} endpoint: Get a component - Pipedream
Sorry for the delay in responding , I’ve been diverted onto different work for the last few days! Unfortunately this doesn’t seem to work either, I get 404 errors on that endpoint regardless of whether I use the ID or the key. Would my auth token (generated against the connect API) also be valid for the REST API?
Is there documentation anywhere on the difference between these two APIs? Is the Connect API the replacement for the REST API or are there times when the REST API is still recommended over the Connect API?
I don’t think there’s documentation anywhere on the difference between these two APIs. I believe the platform REST API is used to manage resources for yourself (a single user). Whereas the Connect API can be used to build integrations for either just yourself or many of your app’s/system’s users.
If you’re working with external users, then yes, I think the Connect API generally replaces the platform REST API. However, there are some gaps, like you discovered.