Using Gorgias to Create Internal Notes on Tickets: What Am I Missing?

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

Anyone here use Gorgias? I’m trying to set up something that makes an internal note on a ticket. But so far I can’t seem to use the trigger’s Create Source to actually interact with anything. Am I missing something really simple?

Can you tell me more about what isn’t working?

Sorry for the delay! My work computer does not have Slack, so I didn’t realize I got a response once the browser hibernated the tab.

I’ll attach a photo. If I use the create ticket option. I see this all spit out. But it doesn’t form anything I can use in the next steps. Is there a step I am missing?

Ah, interesting. It looks like we failed to successfully create the source, seemingly due to a rate limit from Gorgias.

The goal is to make it so that on a new ticket, this flow will append an internal note to the ticket with the information from our warehouse.

I have tried using it more via webhooks, and while that works, I noticed Gorgias would perform the webhook 2-3 times minimum and that really ate into the the base tier of my quota.

Are we maybe trying to fetch too many historical events when creating a Gorgias source, and getting timed out as a result?

I’d much prefer if it was not my mistake, at least! :slight_smile:

Yes, seems like so. Currently, there is no limit on the number of historical events being fetched. We also can definitely improve on the way it fetches the historical events. Sorry bout that

I’ll create an issue and work on a fix

Thanks, Andrew. We should figure out how to improve this more broadly across all sources that fetch historical events, since it’s not the first time it’s happened. I believe in our guidelines docs we have 100 events as the limit?

Yea Contributing to the Pipedream Registry

I think 25 would be a better number, since it’s enough data and not too much.
We can add a constant in @pipedream/platform and make sure the sources are retrieving 25 at max.
What do you think?

Oh, and I think it’s missing in the Webhook Sources docs

Oh, and I think it’s missing in the Webhook Sources docs
Good call, we should move this out of the Polling Sources section, and discuss trying to fetch historical events for webhook sources too.

I think 25 would be a better number, since it’s enough data and not too much.
You’re probably right, maybe we land in the middle at 50?

We can add a constant in @pipedream/platform and make sure the sources are retrieving ~25~ 50 at max.
Yes, good idea

Sure!

Good call, we should move this out of the Polling Sources section, and discuss trying to fetch historical events for webhook sources too.
Yeah, actually the polling sources run once when deployed, so they automatically “fetch” historical events

the issue can be tracked here

Some APIs don’t support listing resources by descending date. In these cases, would it be ok to just get the first 50 events? There are many sources that fetch all events and then discard all but the most recent ones. This could be problematic for large quantities of data