Dear community I’m seraching for someone who can build an evironment based on make.com+typebot+Airtable. I need someone who can help me with the setup (or better, create a setup for me ) Small project budget available
So if you’re able:
to build flows within typebot (with several staged, connections, conditions and AI
to integrate typebot and airtable
seit up make and connect with other tools & buid flows
and you’re interessted
Than let me know!!!
PS: if you can German it’s GREAT, but if not, we can try in English .
What is the problem & what have you tried?
I tried to create typebot under some conditions - failed
Tried to connect my flow in typebot with API Airtable - failed
Sceenshot shows only one part of the problem : and I tried several times with new tokens, new tables, seraching errors in table name sand much more, but nothing worked.
and that’s not the end of the story…
Error messages or input/output bundles
{
“statusCode”: 403,
“data”: {
“error”: {
“type”: “INVALID_PERMISSIONS_OR_MODEL_NOT_FOUND”,
“message”: “Invalid permissions, or the requested model was not found. Check that both your user and your token have the required permissions, and that the model names and/or ids are correct.”
}
}
}
Hello @Ann , welcome to make.com community, I have worked and have experience with Make.com and l will love to collaborate with you on this you can schedule a call Here and you can checkout my upwork profile Here, for my pastworks and certifications
Hey @Ann , I can build this setup for you end-to-end in Make, Typebot, and Airtable, including the conditional bot logic, API connections, and the scenarios around it. The 403 error looks like a permissions/model configuration issue on the OpenAI side, and I can fix that while structuring the flow so the bot, Airtable records, and Make automations work reliably together. I’ve built similar multi-step workflows with branching, AI actions, webhook handling, and Airtable syncing, so this is a straightforward implementation rather than trial and error. If needed, I can also improve the setup so it’s easier for you to maintain after handoff. German is fine for me if you prefer. Send me the current Typebot flow, Make scenario, and Airtable structure, and I can review it and start from there. You can book a call with me here to discuss this further
Have sent you a DM as well. Would love to help you integrate Typebot with Airtable using Make. I run an automation studio called Automation Jinn where we help companies automate their processes and increase efficiency. I am Make advanced certified, Airtable Certified builder with a background in computer science so quite comfortable in integrating API and custom code. I have experience working with both SMB’s and large enterprises.
Some of my relevant work-
• For a bakery brand with a large social following, I implemented chatbots integrated with a custom CRM in Airtable and automation workflows to handle orders and FAQs saving hours of manual coordination every day.
• For a digital agency, I set up a smart call-routing system using Twilio, Airtable, and Zapier to automate lead handling.
• For an education company, I integrated LearnWorlds with Airtable, Make, and Pipedrive via API handling complex pagination and syncing data in real time.
I work more as an AI transformation partner for my clients rather than just a builder. Would love to learn about your day to day operations
This looks like a combination of permission + configuration issues across your setup.
The error you’re getting: INVALID_PERMISSIONS_OR_MODEL_NOT_FOUND
usually comes from:
• incorrect API key permissions
• wrong model name (especially with AI integrations)
• or mismatched workspace/project access
Also from what you described, the challenge isn’t just one error, it’s the overall setup between Typebot, Airtable, and Make.
I’ve worked on similar flows involving:
• multi-step Typebot logic (conditions, AI responses)
• Airtable integrations via API
• Make scenarios connecting everything together
It would be best to structure everything properly from the start so the flows don’t keep breaking.
A few quick questions:
Which AI provider/model are you trying to use in Typebot?
Is your Airtable base already structured or still in progress?
Do you want a full setup or just fixing the current errors?
Happy to help you get this running smoothly.
Website Portfolio: Click here to view my past automation setups.
Book a Call: Click here to schedule a walkthrough call session.
Email: folafoluwaolaneye@gmail.com
The kind of project that usually frustrates people here is not the bot itself, it is the weak logic between the bot, the database, the AI layer, and the automations. That is exactly where I am strongest. I step into builds like this when the flow technically exists, but the conditions break, the data does not land cleanly, permissions fail, or one bad setup choice upstream causes constant errors downstream. Your 403 issue tells me this needs someone who can think through the full chain, not just patch one module and hope the rest holds.
I can take this from messy setup to a working system.
I would start by tracing the exact failing point in the current stack so we know whether the 403 is coming from the AI provider, the model name, token scope, or the way the request is being passed through the flow.
Then I would review the Typebot structure itself, including staged logic, variables, conditions, and where the AI calls are being triggered, because bad bot logic creates false errors that look like API problems.
Before wiring more automations, I would check the Airtable structure closely, including table names, field types, required values, and record relationships, so the bot is writing clean data into a base that actually supports the workflow.
After that I would rebuild or clean up the Make scenarios so each scenario has a clear job, instead of one long brittle automation that becomes impossible to debug.
I would standardize how data moves between Typebot, Airtable, and Make so field names, outputs, and conditions stay predictable across the full system.
I would separate the testing into layers: bot logic, Airtable read and write behavior, Make routing, then full end to end execution. That is the fastest way to stop guessing.
If AI is part of the decision making inside the flow, I would keep the logic controlled and deliberate so the system stays stable and does not become unpredictable every time you update a step.
I would also build in proper failure handling and visibility, so when something breaks later, you can see where and why instead of redoing tokens and tables blindly.
A few relevant examples from my work:
I built a full automation and systems integration layer from the ground up using Zapier and Make for a heavy equipment and service business. That included designing how inquiries were captured, categorized, routed, tagged, handed off internally, and synchronized across connected systems. I also built fallback logic, error routing, retry-aware flows, and field mapping so bad data would not corrupt downstream workflows. That is directly relevant here because your project has the same real challenge: getting multiple tools to behave like one clean operational system instead of a chain of fragile handoffs.
I built a full operational automation system from the ground up using Zapier and Make for an HVAC company, covering quote requests, service inquiries, follow-up workflows, CRM updates, internal notifications, and lifecycle automation. I had to define branching logic around request type, urgency, geography, timing, and customer intent, then make sure the workflows stayed maintainable long term. That matters here because Typebot and Make projects fall apart fast when the conditions and routing are not structured properly from day one.
Cococure AI WhatsApp Chatbot I oversaw an AI-powered automation system that connected conversational flows with live business rules, backend services, and real operational outcomes. The key part was not just adding AI, but structuring how conversation flow, data retrieval, and response generation worked together reliably. That ties directly into a Typebot setup where AI needs to behave like part of a system, not a random add-on.
If you are open to it, I would be glad to jump on a call and look at the current setup with you.
Which AI provider and exact model are you calling when the 403 happens?
Is Airtable only storing submissions, or is it also driving decisions and lookups inside the flow?
How much of the current Typebot structure is already built versus still flexible?
What other tools need to be connected through Make besides Typebot and Airtable?
Do you want this repaired in place, or do you want it cleaned up and rebuilt properly where needed?
You need somebody who can step into a broken automation chain, identify exactly where permissions, model access, field mapping, and workflow logic are failing, then rebuild it so Typebot, Airtable, Make, and AI all behave like one clean system instead of four separate tools fighting each other.
What stands out to me here is that your problem is likely not one issue. The 403 model error points to a permissions or model configuration problem on the AI side, but projects like this usually also have hidden problems in payload structure, Airtable field mapping, conditional logic, and scenario sequencing. That is the kind of work I handle well because I do not treat the chatbot, the database, and the automation layer as separate little tasks. I treat them as one operating system that has to be structured correctly from the start.
How I would approach it:
I would review the AI connection first, because the 403 error needs to be isolated before the rest of the flow can be trusted.
I would inspect how Typebot is sending data, what model is being called, and whether the token, endpoint, or model name is wrong.
I would verify the Airtable setup at the schema level, including base access, table names, field names, required fields, and what each step is actually expected to write.
I would map the full path from user input to AI response to Airtable to Make so the logic is clean and not split across tools in a way that becomes hard to debug later.
I would decide what logic belongs in Typebot and what should live in Make, because pushing too much branching into the bot usually turns maintenance into a mess.
I would structure the Airtable layer around the workflow, not just around storage, so records are usable for status tracking, follow up actions, and future automation.
I would test each stage independently before reconnecting the whole chain, which is the fastest way to stop guessing and find the real breakpoints.
I would standardize any AI output that needs to hit Airtable fields so downstream automations are not dealing with inconsistent data.
I would build fallback handling for bad inputs, failed writes, or partial runs so the system is reliable in real use, not just during setup.
I would keep the final build modular so future changes to prompts, tables, tools, or flow stages do not require rebuilding everything.
A few relevant examples from my work:
Cococure AI WhatsApp Automation System was a strong match because it involved AI driven conversation flows tied to live business rules, structured logic, and backend orchestration. I designed and delivered the system architecture connecting conversational AI, workflow control, and operational handoffs so the bot could respond intelligently without becoming unpredictable. That kind of work is directly relevant here because your setup also depends on AI behaving correctly inside a larger automated process, not as a standalone gimmick.
RiggsCAT.com is relevant because I built the automation layer from the ground up using Zapier and Make for a business with multiple intake paths, routing rules, internal notifications, CRM sync, exception handling, and downstream operational actions. I handled the workflow architecture, field mapping, categorization logic, fallback paths, and maintainability so the automation could keep working once real volume and messy data hit the system. That ties directly into your project because Make and Airtable setups usually fail from poor logic design, not from the tools themselves.
YacDaddy.com is another relevant example because I consolidated fragmented workflows into a single structured platform with clean role logic, operational visibility, and systems thinking behind the scenes. I handled the architecture and workflow design so the product stayed organized and scalable instead of becoming a pile of disconnected logic. That matters here because the real goal is not just to make one flow work. It is to give you a setup that stays usable as it grows.
I would be glad to jump on a call and look at the current setup with you.
Which AI provider and model are you calling right now from Typebot?
Do you want Airtable to act only as storage, or also as the source of status and workflow logic?
What should Make handle after form completion, record creation, notifications, follow up, or all of it?
Is your Airtable structure already finalized, or does that still need to be cleaned up?
Are you looking for targeted setup help, or for someone to fully build and stabilize the whole system?
I see your error. I’ve been there. Usually, it’s not just about the token itself, but about the specific Scopes (data.records:read/write) and Base Access permissions in Airtable’s new developer settings. I can fix this for you in day.
How I will help you with this setup:
Typebot Logic: I’ll build your multi-stage flows with conditions and AI integration. I’ll make sure the AI doesn’t just “talk” but actually structured the data for Airtable.
Airtable Integration: I’ll fix your API connection. I’ll ensure the JSON sent from Typebot matches your Airtable fields perfectly so you never see that “Invalid Permissions” error again.
Make.com Orchestration: I’ll set up Make as the “brain” to connect everything else, handling error filtering and data routing between your tools.
Language: I communicate fluently in English, and I can handle the German interface/data structures without any issues.
Why me? I’m a developer, so I don’t just guess—I debug. I’ll check your API headers and JSON bundles to find exactly why it’s failing.
Hi, This is exactly the kind of setup I handle regularly. I’ve worked with Typebot, Airtable, and Make.com to build complete automation systems—handling flow logic, API integrations, and fixing issues like the permissions error you’re facing.
From your description, it looks like the main problem is around API permissions/model access and flow structuring. I can help you set up the Typebot flows properly, connect Airtable correctly, and build Make scenarios to tie everything together so it runs smoothly.
I’ve done similar work where chatbots were connected to Airtable via Make, handling user inputs, conditions, and syncing data reliably without errors.
What is your goal?
) Small project budget available 
What is the problem & what have you tried?
Error messages or input/output bundles
Check my profile:
Book a quick call: