Looking for an n8n freelancer/consultant with telecom OSS experience.
Scope:
Initial PoC:
Preference:
Hey @Devender_Indora , I would love to collaborate with you on this, REST API integration, PostgreSQL data storage, correlation workflows, and AI agents for operations automation are what I work with in n8n.
For your PoC specifically:
I work US night-shift hours from Nigeria (GMT+1) which gives solid overlap with India timezone (IST is GMT+5:30 4.5 hours ahead). Fully open to fixed-price or milestone-based engagement.
Happy to review your full requirements document before any commercial discussion send it over and I’ll come back with a scoped proposal.
Website: https://www.pathfinderautomationsolutions.com
Upwork: https://www.upwork.com/freelancers/~01446d60f782215efa
Book a call: Calendly
Taiwo
Pathfinder Automation Solutions
Hi,
Found this through a lead-aggregator I run that scrapes job sources and scores them with an LLM.
I build and run LingoVox, a production Telegram bot doing real-time voice translation — OpenAI API integration, PostgreSQL, webhook-driven workflows, live with paying users. The aggregator itself is also a relevant proof point for this specific scope: it’s a decoupled pipeline (collector/scorer, DB queue, retry logic, process isolation) — architecturally closer to what you’re describing for correlation workflows than a straight bot.
Telecom OSS specifically (RFMS/ONMSi, GIS) is new territory for me, so I want to say that upfront rather than imply otherwise. The n8n/API/PostgreSQL/correlation-pipeline side of this I can deliver; the telecom-specific data model is what I’d need to ramp up on.
Before any commercial discussion — could you share the RFMS/ONMSi API docs or sample payloads for the Power Dip TT and alarm pulls? That would let me give you an honest read on the PoC scope rather than a guess.
Hi @Devender_Indora,
I would be interested in the PoC, with one caveat upfront: I will not claim telecom OSS/RFMS domain expertise I do not have. The part I can contribute is the integration and reliability layer: REST API ingestion, payload normalization, PostgreSQL schema, correlation workflow design, retry/error handling, and an audit trail so the PoC can be reviewed before any commercial discussion.
For the first milestone, I would scope it as a small evidence-driven PoC: pull Power Dip TT payloads, pull RFMS alarms, store raw and normalized events in PostgreSQL, apply section + time-window correlation rules, and produce a correlation result table plus operator alerts/logs. If the OSS/RFMS/GIS docs or sample payloads are clear, I can turn that into a fixed-price milestone with assumptions and acceptance tests.
I am in Asia/Kuala_Lumpur UTC+8, close enough to India timezone for async plus overlap. I would prefer to review API docs/sample payloads first, then give an honest scoped quote rather than guessing.
No production credentials needed at the start; sample payloads or a sandbox endpoint are enough for initial review.
Devender, I’m Misha, an n8n and AI automation developer with a strong focus on backend integration. I see you need to pull data from OSS, RFMS (ONMSi), and GIS REST APIs, store it in PostgreSQL, then run correlation workflows based on section mapping and time windows — and eventually build AI agents on top of that. For the initial PoC, I’d wire webhooks to poll the Power Dip TT and RFMS alarm endpoints, land the raw data into PostgreSQL with proper date indexing, then build the correlation logic in n8n using function nodes or a small Python service to match by section ID and alarm timestamps. I keep my builds structured with logging, retry logic, and clear error handling so the integration stays reliable from day one. I can review your API docs and schema requirements quickly and lock scope into fixed milestones. Portfolio: https://mikedevai.netlify.app/ | Telegram: Telegram: Contact @hely_chatbots | WhatsApp: +375293761570
Hi Devender,
I read the scope. Pulling OSS, ONMSi and GIS into Postgres and wrapping it in n8n is the routine part. What decides whether the PoC is trustworthy is the correlation rule: a Power Dip TT and the RFMS alarms only count as one incident when the section mapping and time window are tight enough to avoid false joins and loose enough not to drop a real one. Get that wrong and the NOC chases phantoms or misses real outages.
That correlation layer, plus clean API integration and Postgres modelling, is what I build. I have not worked ONMSi specifically, so I would read its API and confirm the alarm and TT payloads before quoting rather than guess.
Two questions to scope the PoC: what time gap still counts as a valid correlation, and is the section mapping already in GIS or does it need deriving? EU based, comfortable with India overlap for milestone work.
Hi Devender,
I’m an n8n consultant with hands-on experience in REST API integrations, PostgreSQL pipelines, and correlation workflows is a good fit for this telecom OSS PoC.
For the PoC, I’d pull Power Dip TTs and RFMS alarms via API, store them in PostgreSQL, and build the correlation logic based on section mapping and time window.
Before scoping commercials, quick questions:
Happy to do this as a fixed-price milestone, working in IST hours. Let me know and we can move forward.
Best,
Samuel
Hey, I’m Basit — n8n specialist, I build custom nodes and complex automation workflows (you can see my published nodes: Zep Memory, ClickHouse, Power BI, Clay, Google Ads, among others).
Your scope is something I can hit running — REST API pulls from OSS and ONMSi via HTTP Request nodes, RFMS alarm ingestion, storing everything in PostgreSQL (I’ve built ClickHouse nodes so DB integration is very familiar territory), and then the correlation logic on top with time-window + section mapping. The AI agent layer for telecom ops is exactly the kind of thing I’ve been building.
Quick questions before I review the full requirements:
On timezone — I’m PKT (UTC+5), one hour behind IST. Works fine for overlap and async is always an option.
Happy to go through the requirements doc before any commercial discussion — that’s the right way to scope this anyway. Milestone-based works well for a PoC like this.
Book a 20-min call here: https://calendar.app.google/qDYxm4uA6cpScfTD7
Hi Devender, welcome to the community 
.
Interesting project.
While my background is primarily in automation, APIs, databases, AI agents, and workflow orchestration rather than telecom OSS specifically, I have experience integrating REST APIs, working with PostgreSQL, building correlation logic, and developing AI-powered workflows in n8n and Make.com.
I’ve attached a few relevant case studies and would be happy to discuss the PoC requirements further to see if we’re a good fit.
Website Portfolio: Click here to view my Portfolio website.
Book a Call: Click here to book a walkthough call session.
Email: folafoluwaolaneye@gmail.com
Looking forward to connecting.
Folafoluwa Olaneye
AI-Powered Telegram Community Management System.pdf (260.6 KB)
Amazon Price Monitoring & Competitive Intelligence System.pdf (280.9 KB)
Automated Document Processing & Approval Workflow.pdf (138.6 KB)
This is a strong fit for a fixed-scope first slice.
I would keep v1 narrow and measurable:
- ingest the two REST feeds into PostgreSQL with idempotent writes
- normalize the section-mapping and time-window logic
- correlate Power Dip TT and RFMS alarms into one clear flag/alert output
- keep the workflow modular so the telecom-specific mapping can evolve without rewiring everything
For a clean PoC, my fixed quote is USD 500, delivered in 1-3 days after access and the sample payloads are shared. I work asynchronously and can hand over concise workflow notes as soon as v1 is stable.
Best,
OpsPilot AI Studio
Hi Devender, for the PoC I’d keep the first version very narrow: pull Power Dip TT from the OSS API, pull RFMS alarms, store the raw events in Postgres, then run one separate correlation workflow using section mapping and a time window. That gives you something testable before adding an AI-agent layer. Happy to review the requirements and suggest a clean first workflow structure if useful.
Hi Devender,
I can help with a bounded paid sandbox or PoC sprint for this n8n OSS workflow. I would start with sample payloads, API docs, or sandbox endpoints for OSS, RFMS/ONMSi, GIS, and PostgreSQL, then scope the first milestone around pulling Power Dip TTs, pulling RFMS alarms, storing raw and normalized events, and producing a section plus time-window correlation output with logs and acceptance checks.
No production credentials are needed for the first review. If useful, please share the first OSS workflow you want proved out and the systems involved, for example OSS, RFMS/ONMSi, GIS, PostgreSQL, and any alerting or AI agent target.
Best,
Thomas
Hire Thomas Inc
Hi @Devender_Indora ,
I’m interested in discussing your project requirement to share detail scope.
I have hands-on experience in REST API integrations, PostgreSQL database, and automation agents.
Do you have the RFMS/ONMSi API docs or sample payloads for the Power Dip TT & alarm pulls?
Please connect further, If you are still hiring
Regards
Deep
Hi @Devender_Indora — I would approach this as a small evidence-driven PoC first, not as a broad automation build.
I should be transparent upfront: I am not claiming deep telecom OSS/RFMS/ONMSi domain expertise. The part I can help with is the integration and reliability layer around the PoC:
- REST API ingestion for Power Dip TT and RFMS alarm payloads
- raw payload capture plus normalized PostgreSQL tables
- section mapping and time-window correlation logic
- n8n workflow structure with retry/error paths
- a result table or alert output that can be reviewed before commercial discussion
- short handoff notes with assumptions, sample payloads, and acceptance checks
For the first milestone, I would ask for sample API docs or redacted payload examples only. No production credentials are needed at the start. From that I can map the PoC, list assumptions, and quote a fixed milestone instead of guessing.
I am UTC+7, close enough to India timezone for async work plus overlap. I can share public work-style notes later if the forum allows the host, but I will keep this first reply focused on the PoC scope.
Hi @Devender_Indora — addressing your scope point by point, including the one gap:
n8n: 13+ workflows in production on my self-hosted instance (orchestration with retries, dead-letter queues, failure alerts)
REST API integration: daily work — multi-source capture pipelines with error handling and human review gates
PostgreSQL: my production datastore — schema design for correlation and reporting, not just storage
AI/automation agents: Claude/Gemini with structured JSON outputs running in production (qualification scoring, routing, alerting)
India timezone: I’m based in Maharashtra (IST native, not just overlap)
Telecom OSS specifically (ONMSi/RFMS, GIS): I haven’t worked with these platforms yet, but I’m fully confident I can — they expose REST APIs, and your PoC is at its core an event-correlation problem: two API sources joined on section mapping within a time window, which is exactly the shape of pipeline I build every day.
For the PoC I’d propose a small fixed price, ~1 week: Power Dip TT + RFMS alarm ingestion → PostgreSQL → correlation rule (section + time window) → flagged events with alert/report output, documented and handed over.
90-sec walkthrough of my live systems: https://media.rasaltechsolutions.com · rasaltechsolutions.com
Happy to review the full requirements before any commercial discussion — where should I send for the document?
Hi @Devender_Indora,
I can take a look at the PoC if this is still open. The REST API → PostgreSQL → correlation-window part is a good fit: normalize both Power Dip TT and RFMS alarm payloads, keep raw payloads for audit, map sections explicitly, then produce a correlated event table plus alerts/logs for unmatched or uncertain cases.
Telecom OSS/RFMS specifics would depend on your API docs and sample payloads, so I would start by reviewing one Power Dip sample, one alarm sample, the section mapping format, and the expected output. After that I can suggest the simplest PoC scope before any commercial discussion.