@Manu Rai Manu, this is a pretty standard build with the right stack. The core is a voice or chat AI, VAPI for voice or Manychat for text, wired into a CRM like GHL with Calendly handling the booking side. The qualification layer is where most people mess up, Manu, you need to tune the intent scoring to your offer or bad-fit leads slip through to calls. If you want text-based, n8n or Make can handle the orchestration without much overhead. For voice, VAPI is probably the cleanest option right now. Feel free to DM me, Manu, and I'll be happy to look at your setup and give you a honest assessment of whats needed.

@Manu Rai No worries. Here’s my Emai : mofedulalamjoy09@ gmail.com Here’s my WhatsApp: +8801628675223

@Luka Švenda Luka the proxy question depends on how you're running the accounts. Five accounts on the same IP from the same device is a flag for Instagram, they pattern-match on that pretty fast. Cheapest lean setup: one account per device if you have spare phones, or mobile data per account. Not ideal but avoids the shared IP problem without paying for proxies. Residential proxies are better than VPNs for this, VPNs get flagged way more. For warmup, the method that works is 2 weeks of normal behaviour before any outreach. Follow people, watch stories, post once or twice, engage with comments. Instagram needs to see the account as real before you start DMing strangers. Start at 5 DMs a day Luka, not 25. Ramp up over 3-4 weeks. Jumping straight to the limit on a fresh account is what gets you restricted. Feel free to DM me if you want to compare notes on what warmup cadence has been working, Luka.

@Luka Švenda I think there are some easier solutions and third-party tools or software that you can use to spin up a separate environment for those five accounts. Feel free to reach out to discuss this further: Here's my Emai : mofedulalamjoy09@ gmail.com Here's my WhatsApp: +8801628675223

@Scott Hamilton Hey Scott, I can see exactly whats happening from your screenshots and its just a UI update in VAPI, nothing is broken on your end. VAPI added native Google Calendar and Google Sheets tools directly into their platform since that video was recorded a year ago. So instead of needing to connect Make.com as a middleman for calendar booking you can now use the google_calendar_tool directly inside VAPI which is actually simpler and more reliable. You have two options. First option is use the native Google Calendar tool you can already see in your VAPI dashboard, fill in your Calendar ID and timezone, connect your Google account and your done. No Make webhook needed at all for the booking piece. This is the cleaner approach for most restaurant builds. Second option if you specifically want to follow the video and use Make, scroll back in the Create Tool screen, there should still be a Custom Tool option which lets you paste in a webhook URL from Make. Thats the equivalent of what the video shows as the Make tool, just got renamed or moved in the UI update Scott. Given that you already have the Google Calendar tool sitting right there in your VAPI dashboard I'd honestly just use that instead of following the Make route from the video. Saves you building the Make scenario entirely and does the same job with fewer moving parts. Fill in your Calendar ID from Google Calendar settings, set your timezone, and connect your Google account. Feel free to DM me if you get stuck on the Google Calendar connection step!

@Scott Hamilton You're welcome brother. Feel free to reach out if you have any question or confussion. Here's my Emai : mofedulalamjoy09@ gmail.com Here's my WhatsApp: +8801628675223

@Adarsh Yadav Hey Adarsh, you've diagnosed this correctly, the 7 day refresh token expiry on testing mode apps is exactly what's biting you. The permanent fix without going through Google's full verification process is switching to a service account for Sheets and Drive. Service accounts dont use OAuth refresh tokens at all, they use a JSON key file that never expires until you manually revoke it. Zero reconnection issues once its set up properly. This works perfectly for Sheets and Drive since those are server to server operations where you dont need user consent flows. To set it up go into Google Cloud, create a service account, download the JSON key, then share your specific Google Sheets or Drive folders with the service account email address just like you'd share with a regular person. In n8n create a Google credentials using the service account option and paste in the JSON key contents. Done, never disconnects. The one gotcha is service accounts cant access files in My Drive unless explicitly shared with them. So if your workflows read files from personal Drive folders you need to share those specific files or folders with the service account email. For Sheets this is usually a non issue since you just share the sheet once during setup. If you genuinely need OAuth for some reason rather than service accounts the other fix is publishing your Google Cloud app which removes the 7 day limit but requires going through Google's verification process which takes weeks and requires a privacy policy Adarsh. Service account is the move for 95 percent of n8n use cases. Feel free to DM me if you need help with the exact setup steps in Google Cloud!

@Elad Rosenberg Hey Elad, yeah the Remotion plus Claude Code setup has a steeper learning curve than the videos make it look so your not alone here. On your two questions, switching to Opus is worth trying for complex video composition logic but honestly the bigger issue is usually prompt structure not model capability. And five days old is fine, Claude Code version isnt your problem here. The real issue with Remotion specifically is Claude doesnt have deep training on Remotion's component structure so it makes plausible looking code that renders wrong or breaks the preview. The fix is to give Claude the exact Remotion component patterns it should follow before asking it to build anything. Start every session by pasting in a working minimal Remotion component as a reference, tell Claude explicitly to follow that exact structure for every new component it creates. Something like "use this exact pattern for all components, do not deviate from this structure." That alone cuts bad output dramatically. For the preview issues check that your Remotion version in package.json matches what the video uses because Remotion has breaking changes between major versions and older tutorial code breaks on newer installs. Run npx remotion versions to check for mismatches. Also tell Claude to make one small change at a time and preview after each change rather than building large chunks. Smaller iterations with visual verification between steps is way more reliable than generating a full video composition in one shot Elad. What specifically is going wrong with your output, wrong timing, broken layout, render errors? That would help narrow it down faster. Feel free to DM me with your current prompt and I can help you restructure it!