High-signal n8n projects.

Hiring: Noor Saray Real Estate We are looking for a skilled AI engineer to build an intelligent, integrated AI operating system that automates our company's daily operations with minimal human intervention. Responsibilities: * Build AI agents to manage sales, leads, CRM, marketing, property data, and reporting. * Automate emails, follow-ups, workflows, and internal processes. * Integrate AI tools, APIs, databases, and business applications. * Implement human approval systems, security, and error monitoring. * Build a scalable, well-documented system with minimal ongoing maintenance. Requirements: Proven experience with AI agents, n8n/Make, LLMs, APIs, and business automation. Must be practical, independent, and capable of delivering working systems. Budget: Maximum AED 3,000/month for 2–3 months (AED 7,000 total). Application: Share previous projects, proposed technology stack, development timeline, monthly deliverables, and estimated additional costs. Goal: Build a smart, reliable AI-powered company operating system for Noor Saray Real Estate within our budget. Nsr@noorsaray .com

AI-powered agent that integrates with SpruceHealth, Acuity Scheduling, and AestheticRecord via their APIs and Integuru-generated APIs. Aura will serve as a natural-language interface for both staff and patients, allowing routine tasks—such as finding patient information, checking availability, scheduling or modifying appointments, and communicating through Spruce—to be completed conversationally across our existing systems. The goal is to connect our currently separate platforms into a more seamless workflow while reducing repetitive administrative work for our team.

One of two parallel tracks on a fully documented content-automation project. A formal requirements document with numbered requirements and an acceptance matrix is shared with shortlisted experts. This posting is the n8n engine track; a separate posting covers the Python / GitHub Actions delivery track. Bid on one or both. CONTEXT A client runs two small businesses in different sectors (one regulated). Each gets its own instance of the same engine: identical workflows, prompts, schema and gate code, differing only in configuration. Everything runs on accounts the client owns and pays for (n8n Cloud, Supabase, Anthropic API, GitHub). No vendor-hosted infrastructure; the vendor holds no production credential after handover. The engine delivers drafts only; a human publishes. SCOPE 1) Ingestion in n8n - Source registry as database rows, not nodes: adding or disabling a source requires no workflow edit. - Kinds: RSS/Atom, REST and GraphQL APIs (JSON, XML, CSV, text, HTML), cloud-folder PDF/DOCX, social sources. - Per-source config: extraction rules (JSONPath, XPath/CSS, CSV columns), pagination (cursor, page, offset), auth (API key, bearer, OAuth2 with refresh), fetch interval, trust tier, authority tier, failure counters. - Social adapters through official APIs only: X, Reddit, YouTube (uploads and captions), LinkedIn company page, Bluesky, Mastodon, Telegram public channels. No scraping, no logged-in surfaces, no writes to any platform. A new platform is a new adapter, not a pipeline change. - Polite fetching: per-host throttling, 429 back-off, content-type checks, boilerplate stripping, configurable truncation. - Sync of the client's own published posts and sent campaigns back into the store, re-chunked when modified. 2) Retrieval store: specification, not build You write the spec (tables, columns, indexes, embedding model and dimension, distance measure, query shapes). The internal team builds it in Supabase Postgres with pgvector; you test against their instance. Targets: HNSW-indexable dimension, sub-second queries at 100k chunks. 3) Generation pipeline: n8n + Anthropic API - Three content types (news, evergreen, newsletter issue) through one shared pipeline parameterised by type, with three thin wrapper workflows. - Schedules are configuration. News can instead fire on a significance trigger: hourly triage, a classification step, a minimum number of distinct citable sources, configurable caps. A check with no qualifying cluster ends silently but is logged. - Stages: title-embedding clustering and ranking, look-back against the client's own published work, grounding retrieval with a stand-down floor, outline call, section-by-section drafting with the voice guide and an auto-selected exemplar passage, assembly, deterministic gates, a model-editor pass, then targeted per-section rewrites. Sources list built from passages actually used. - Newsletter rules: one issue per send date, one section per post published in the period plus one exclusive item, sequential issue numbers assigned at ingestion. 4) Quality gates: deterministic code plus one model editor Length band, per-section length, grounding (every number, date, quotation and named claim must match a retrieved passage or linked post), authority-tier check for regulated claims, register bands (sentence length, variation, grade level), per-client banned-constructs list, structure and front-matter checks, link resolution, and a per-client rule pack for forbidden claim types, required disclosures and personal-data rules. Every threshold is configuration; every gate result with measured values goes on the audit row. 5) Operations Exactly one email per run (delivered / stood down with reason / failed with stage, node, raw error, audit id), an error-trigger workflow covering everything, a weekly summary, one audit row per run (documents, model per stage, gate results, token usage, outcome), configurable per-run token budget and monthly spend cap, dry-run mode, fixtures exercising every gate, daily reconciliation. BOUNDARY AND EXCLUSIONS Your pipeline ends by committing one Markdown file with YAML front matter on its own branch and opening a pull request in the client's repository. Validation, CMS ingestion, archiving and callbacks belong to the delivery track; both tracks share the front-matter schema and the signed callback contract. No WordPress, PHP or database work: the connector plugin and the Supabase store are built by other parties to your specifications. DELIVERABLES Normalised n8n workflow JSON in the repository as source of truth (deployed from Git, never imported by hand), prompt library as files, per-instance configuration file covering every configurable value, retrieval-store specification, runbook, fixtures, recorded handover plus a live session per operator. IP assigns on final payment. ACCEPTANCE PER INSTANCE Four consecutive weeks unattended with at most one manual intervention per week; at least 80% of scheduled runs deliver a draft passing every gate; zero unsupported figures or quotations in a ten-draft sample; no topic repeated inside the look-back window; every enabled source fetched within its interval or reported; spend inside the cap; the operator can add a source, change a threshold and re-run a failed run from the runbook alone. PROPOSAL Phases: discovery, shared build plus first instance, second instance, stabilisation (budgeted at no less than the build phase), handover. Give a duration and fixed price per phase, a support retainer option, your recommended n8n Cloud plan tier and model per stage with monthly running cost per instance, and two comparable deliveries including what broke during stabilisation and how you fixed it. The budget range shown is indicative; quote the real scope. Alternative architectures are welcome if you state which requirements change and how each is still met; client account ownership, drafts-only delivery and the client's repository as home for everything are fixed.

One of two parallel tracks on a documented content-automation project. A formal requirements document with numbered requirements and an acceptance matrix is shared with shortlisted experts. This is the Python / GitHub Actions delivery track; the other covers the n8n engine. Bid on one or both. CONTEXT A client runs two small businesses (one regulated). Each gets its own instance: its own GitHub organisation and private repository, environments and secrets, WordPress site and FluentCRM. Shared code, per-instance configuration. Everything runs on accounts the client owns, and no production credential stays with the vendor after handover. The system creates drafts only, with one exception: the web version of a campaign a human has already sent. WHAT YOU OWN The other track generates content in n8n and opens a PR adding one Markdown file with YAML front matter to staged-content/. From there it is yours: validate the PR, ingest the merged file into WordPress or FluentCRM as a draft, archive it, publish web versions of sent campaigns, call back to n8n over a signed webhook, and run GitOps for the n8n workflows. SCOPE 1) Five Python CLI scripts, each with a --dry-run flag doing every read and lookup but no write, JSON on stdout, non-zero exit on failure, config and secrets from environment variables only: - validate: front matter against a JSON schema, changed-path check, read-only slug and send-date lookup in the CMS, one issue per send date. - ingest: list files the push added or modified, convert Markdown to WordPress HTML (classic or block markup, your call to justify), render newsletters into the FluentCRM template as email-safe inline-styled HTML, check for an existing item, create the draft, assign the next issue number inside the concurrency group. - archive: move the file to archived-content/<year>/<month>/, write CMS id, URL, issue number, ingestion time and run URL into front matter, commit as a GitHub App without restarting ingestion. - webversion: detect sent campaigns, fetch the body as sent, strip the template wrapper, unsubscribe and preference links, tracking pixels and per-subscriber content, resolve or fail on merge tags, commit the cleaned body into the archive, publish the post idempotently. - callback: HMAC-sign the result and send it to n8n, including from a failed job. The n8n deploy and drift-check scripts follow the same rules. 2) GitHub Actions workflows Validation on every content PR; ingestion on pushes to main touching staged-content/, processing only the files that push changed; a concurrency group so two runs never touch the same file; a scheduled sweep retrying stuck files to an attempt limit then reporting; CI running pytest and linting on every code PR. Pinned runner images and Python, actions pinned to commit SHAs, dependencies pinned with hashes in a lockfile. Workflow files hold no business logic: checkout, setup, install, call a script. The scripts must also run from a plain shell with the same environment variables, so the client can move ingestion off Actions later without a rewrite. 3) Idempotency and collisions Before creating anything, look up the slug in any status and the run identifier (posts) or the send date and issue number (campaigns). An item this engine created for the same run identifier means record and archive, create nothing. Any other item is a collision: leave the file staged and report it. Slug suffixing is not a collision detector. 4) n8n GitOps The repository is the source of truth for every n8n workflow. A deploy workflow calls the n8n public API on merge, matching workflows through a per-instance mapping file and never by name, deploying in dependency order, writing new ids back by a GitHub App commit, recording release version and commit SHA, rolling back by redeploying a previous tag. A scheduled drift check exports the live workflows, normalises them and opens a PR for any difference. 5) Integration surface WordPress and FluentCRM REST plus a small PHP connector plugin a separate supplier builds. You write its interface specification (routes, parameters, response shapes, error codes, required capability, a fixture per route) and a conformance test either party can run against a site; you do not build the plugin. A phase-1 spike per site establishes FluentCRM version and status values, which fields REST can actually set, and whether Cloudflare, Cloudways bot protection and Wordfence admit REST calls from GitHub-hosted runners. HARD CONSTRAINTS No code path may publish a post, send, schedule, resume or duplicate a campaign, or change the status of an item it did not create; CI fails any PR that introduces one. Web versions are the only publish. No secret in a workflow parameter, file, log, row or email. ACCEPTANCE PER INSTANCE Every merged file ingested and archived within 30 minutes of merge or reported; nothing left in staged-content/ past the sweep limit without a failure report; re-runs and concurrent runs create no duplicate; across four sent issues each web version is published within an hour, matches the sent body, carries no subscriber data or unresolved merge tags and exists exactly once; the conformance test passes on each site; a workflow change goes PR to merge to live n8n with no manual import, and the drift check catches a direct edit. DELIVERABLES Scripts with unit tests and CI, Actions workflow files, front-matter schema, connector specification and conformance test, per-instance configuration, a runbook (stuck file, failed web version, credential rotation, deploy and rollback, drift report, collision), recorded handover plus a live session per operator. IP assigns on final payment. PROPOSAL Phases: discovery and site spike, build plus first instance, second instance, stabilisation (budgeted at no less than the build phase), handover. Give a duration and fixed price per phase, a support retainer option, and two comparable deliveries including what broke during stabilisation.