VendorPulse

AI-powered vendor intelligence platform that helps businesses monitor supplier risk, detect issues early, and make smarter procurement decisions.

Comment

Challenges we ran into

No SDK for the core integration. CALL E doesn't provide a REST API or Python SDK. It works through an MCP server and an official CLI (@call-e/cli). To connect it with FastAPI, we had to run the CLI as a subprocess, read its JSON output, and handle the call flow ourselves: plan_call → run_call → get_call_run polling. This took some extra work because the process is mainly designed for interactive use.

Windows specific subprocess issues. We ran into a couple of issues while running the CLI from Python on Windows. The CLI wasn't being found correctly when using subprocess.run, so we had to use shutil.which() with shell=True. We also had problems with non English text in transcripts because Windows was using the cp1252 encoding. We fixed this by forcing UTF 8 and using errors="replace".

CALL E's regional restrictions changed during development. During development, outbound calls to Pakistani numbers started failing without giving us a useful error. This made testing difficult, so we switched to CALL E's official US testing hotline and continued development from there.

Designing a risk model from scratch. There wasn't an existing vendor risk formula that we could simply use. We created our own 5 factor model using variance, benchmark, macro conditions, confidence, and behavioral signals. We also added a manual override for serious delays so that certain critical situations cannot receive a low risk score just because the overall calculation happens to be low.

Neon's idle connection drops. Some CALL E calls can take 1 to 3 minutes, which meant our database connections could stay idle for a while. Neon would sometimes close those connections, leading to SSL connection has been closed unexpectedly errors. We fixed this by adding pool_pre_ping=True to the SQLAlchemy engine so closed connections are detected and replaced automatically.

Deployment was its own challenge. We tried a few different hosting platforms before finding one that worked for us. We ran into issues like dashboards not loading properly, unexpected credit card verification, and broken navigation. We eventually deployed the backend on FastAPI Cloud. Even then, we had a caching issue where an older build was being reused after we had already fixed a dependency. We had to force a new build before the updated code was picked up.

Accomplishments that we're proud of

• A real voice AI integration, not a mock. We were able to place actual outbound calls, answer them, and get live transcripts during development and testing.

• A custom built risk engine with clear and explainable scoring decisions instead of using an arbitrary formula.

• A retry and escalation system that makes up to 3 call attempts, tracks each attempt, and automatically marks an unreachable vendor and sends an email alert.

• A fully deployed production system with the FastAPI backend on FastAPI Cloud, Next.js frontend on Vercel, and PostgreSQL on Neon, with the required CORS configuration between them.

• Every major workflow, from adding a vendor to making a call, extracting information, calculating risk, sending alerts, and showing the results on the dashboard, was tested with real data.

What we learned

• How to work with a platform that doesn't have a traditional REST API or SDK by using its CLI as the integration layer and handling structured JSON output.

• That external platform rules can change during a project. CALL E's regional restrictions forced us to change our testing approach, and having an alternative testing route helped us keep moving.

• How much work goes into deploying even a relatively simple FastAPI application. Things like Docker, environment variables, CORS, database connections, and caching can become important parts of the deployment process.

• That building a risk model is not just about choosing numbers. We had to make clear decisions about which signals should matter more and why, and make sure the final score could be explained.

What's next for VendorPulse

• Move the 3 attempt retry process into a background job or queue so POST /call can return immediately instead of keeping the HTTP connection open for several minutes.

• Add historical vendor analytics so we can see delay patterns and risk changes over time instead of only looking at the latest call.

• Add live call transfer to a human agent for critical cases when CALL E's account level transfer functionality is available.

• Improve the risk model using real usage data once we have enough call history instead of relying only on our initial weights.

• Complete the inbound webhook flow so CALL E can send call completion events directly instead of requiring us to keep polling for the call status.

Built With

  • call-e
  • full-stack
  • next.js
  • postgresql
  • procurement
  • python
  • react
  • rest-api
  • risk-alerts
  • supplier-analytics
  • supplier-risk
  • tailwind-css
  • typescript
  • vendor-management
  • vendor-monitoring
Share this project:

Updates

Submission history