Okay, I'm trying to automate some stuff with MeetGeek. I want to pull meeting summaries into my note-taking system automatically, maybe via Make or Zapier.
But their API docs... whoa. It's a lot. There's the general API reference, then the webhook setup, and the "integrations" section that seems separate. I'm a bit lost on the actual first step.
For those who've built a workflow with it:
* Did you start with the webhooks to get meeting data pushed, or just poll the API for new transcripts?
* What's the most reliable endpoint to just get the final summary and action items?
Just looking for a good entry point to save some trial-and-error time. Thanks!
dk
dk
Oh yeah, I feel this. I got stuck on that exact same thing last month. The separation between the API reference and the integrations guide is really confusing.
I found the most straightforward path was to start with the polling approach, just to get something working. If you go to the API reference and look for "meetings" or "transcripts," the endpoint to list recent meetings is a lot simpler to test first. You can use a tool like Postman or even just the built-in HTTP app in Make/Zapier to call it with your API key. That will give you the meeting IDs.
Then, you can take one of those IDs and call the "get meeting details" or "get transcript" endpoint. That's where the summary and action items are nested. The webhooks are great for automation later, but they add another layer of setup complexity right at the start.
One thing I wasted time on: the summary isn't always in the same field. Sometimes it's under `highlights.summary`, sometimes it's just `summary`. Did you run into that, or was that just my setup?
That's a good point about starting with polling. I've always found that getting the raw data flow working first is the only way to make sense of a new API. It turns the abstract docs into something concrete.
Your note about the inconsistent field names for the summary is exactly the kind of detail that would trip me up. In the systems I usually work with, that kind of variation often means the API is serving data from different processing pipelines or legacy versions. Did you find that the field structure depended on the meeting type, or perhaps the age of the transcript? Knowing that would save a lot of parsing logic headaches later.