Node.js Developer – API Integration (Bridallive POS System, WhatsApp, WooCommerce)

Overview Emily Bridalwear is a bridal shop (bricks-and-mortar in Sheffield plus online sales) using Claude as an operating assistant across the business. The goal is to stop routine questions and manual admin from landing on the owner by giving the team's AI assistant live access to real shop data and the channels the business already uses. That's three connected projects, all centered on the shop's BridalLive system: • BridalLive connector — so Claude can see live appointments, stock, and orders instead of stale exports. • WhatsApp connector — so the team can ask questions where they already communicate, with Claude drafting answers from the shop's SOPs and decision tree, and only escalating to the owner what actually needs her. • WooCommerce ↔ BridalLive inventory sync — so the website's product stock reflects what's actually available in BridalLive, and vice versa. One thing to be clear about: the goal is a single, consistent source of answers, not two different assistants. Whether a team member asks a question by messaging the WhatsApp number (Project 2) or by asking Claude directly (already possible today, and much better once Project 1 is live), the answer should be built the same way — grounded in live BridalLive data plus the shop's SOPs and decision tree, not guessed. WhatsApp is simply an additional door into that same capability, for the moments the team is already on their phone rather than in Claude. These can be scoped and bid as one engagement, or split across projects — happy to hear a freelancer's preference in their proposal. All three depend on the same underlying BridalLive API work, so there's real efficiency in one person or team handling all three. Project 1: BridalLive connector Current state — please read carefully There is a starter codebase, not a working integration. It's a Node.js MCP (Model Context Protocol) server that implements BridalLive's documented authentication flow and appointments/contacts endpoints, but it has never been run against BridalLive's actual API — it was built inside an environment with no network access to BridalLive's servers, so it's untested against a live response. Treat it as a well-informed first draft, not a proven starting point. What's included in the starter • Auth flow (login, token refresh, retry-on-expiry logic) coded per BridalLive's documentation. • Appointments tools (list appointments, check available slots) and contacts tools (search, lookup) coded against documented endpoints. • A README flagging exactly what's confirmed vs. guessed, including that inventory/stock and order endpoints are unconfirmed placeholders — BridalLive's full reference lives behind a JavaScript-rendered Swagger page that needs a real browser to read. What needs to happen • First: actually test the existing auth and appointments code against BridalLive's QA/sandbox credentials and fix whatever doesn't match reality — assume this needs debugging, not just polishing. • Confirm the real inventory/stock and order endpoints via BridalLive's Swagger UI and build those tools — this is the highest-priority part of the whole project, since it also unlocks Project 3, and stock/order awareness matters more than appointment visibility for reducing owner involvement in decisions. • Work with BridalLive support to sort production API access (current credentials are QA/sandbox only; a support ticket about this is already open with them). • Convert the connector from a local stdio process to a hosted HTTP service, deploy it with credentials stored as secrets, and help register it as a custom MCP connector in the Claude org's admin settings. Project 2: WhatsApp connector The team currently communicates on WhatsApp and defaults to asking the owner directly. The goal is a WhatsApp number the team can message with questions, where Claude answers using live BridalLive data (from Project 1) plus the shop's documented SOPs and decision-tree framework (already written) — the same grounded answer a team member would get asking Claude directly, just available on WhatsApp too — and flags anything that genuinely needs the owner instead of guessing. What needs to happen • Set up a WhatsApp Business number via Meta's WhatsApp Business Platform (Cloud API) or a Business Solution Provider such as Twilio — advise which route fits best given cost and setup time, including Meta's business verification process, which can take time and needs to be started early. • Build a webhook service that receives incoming WhatsApp messages, sends them to Claude for a response (grounded in the shop's SOPs/decision tree and live BridalLive data from Project 1 — not a separate, independent answer engine), and sends the reply back via the WhatsApp API. • Build in a simple escalation path — messages that should reach the owner directly (per the shop's existing Leaf/Branch/Trunk/Root decision framework) get flagged rather than answered automatically. • This is a new build, not an existing starter — there is no code for this yet. Project 3: WooCommerce ↔ BridalLive inventory sync The shop's website runs WordPress with WooCommerce. Stock shown online should reflect what's actually available in BridalLive, so customers don't order something that's already sold or reserved in-store, and vice versa. A specialist bridal-retail platform (Syvo) offers something in this space, which confirms it's a solved problem in principle, though as a full site-replacement platform rather than a plugin for an existing WooCommerce store — this project assumes staying on the current WordPress/WooCommerce setup. What needs to happen • Build a sync service (likely a small WordPress/WooCommerce plugin, or a scheduled script hitting the WooCommerce REST API) that reads stock/availability from BridalLive (via the inventory endpoint confirmed in Project 1) and updates WooCommerce product stock status accordingly. • Decide and implement a sensible sync direction and frequency (e.g., BridalLive as the source of truth, syncing to WooCommerce every N minutes, or via webhook if BridalLive supports one). • Handle edge cases sensibly — one-of-a-kind sample gowns, items mid-alteration, etc. — in consultation with the owner. Future phase (not part of this engagement's scope or budget) The longer-term goal is full autonomy: the system rescheduling appointments, updating BridalLive records, and messaging brides directly without a human in the loop. That's a meaningfully higher-risk category than read-only visibility or inventory syncing — it touches customer relationships and brand reputation directly — so it is intentionally not part of this project's scope or price. Any proposal should design the connectors above to be extensible toward this (clean, well-documented write endpoints; clear logging), but should not attempt to build autonomous customer-facing actions now. How this should shape the architecture now, so nothing built here has to be thrown away later: • The BridalLive connector should be built as one MCP server designed to grow, not replaced. Write actions (rescheduling an appointment, updating a record) get added as new tools on the same server later — e.g. BridalLive's appointment-update and create-transaction endpoints, which this phase doesn't need but shouldn't be designed against. • The WhatsApp connector stays a separate, second MCP server, since it's a different API and authentication model entirely — it's not a phase of the BridalLive connector, it's always been its own piece. • Autonomy itself is not a connector concern — it's governed by the shop's Leaf/Branch/Trunk/Root decision framework sitting above whichever tools exist at the time. That framework decides what's safe to act on without a human; the connectors just need to expose actions cleanly (clear inputs/outputs, good logging) so that framework can be applied to them later. Only clearly low-risk, precedented actions become autonomous, and anything touching a bride, money, or a policy exception continues to require a human to review before it goes out. Must-have skills • Solid Node.js/JavaScript backend experience. • Comfortable integrating with a REST API from partial or JavaScript-rendered documentation — testing against a live sandbox and figuring out the rest. • Experience with WhatsApp Business Platform (Cloud API) or a BSP like Twilio's WhatsApp API, including webhook handling. • WordPress/WooCommerce development experience, including the WooCommerce REST API or plugin development. • Experience deploying and securing a small backend service (environment secrets, HTTPS, basic hosting). Nice-to-have • Familiarity with Anthropic's Model Context Protocol (MCP), or willingness to learn it from the official SDK docs. • Past experience with retail/POS system integrations (Shopify, Square, Lightspeed, etc.) — nobody will have direct BridalLive experience since it's a niche vendor, but this signals faster ramp-up on how these systems typically model inventory, orders, and appointments. • Experience building simple AI-assistant-over-chat workflows (routing a message to an LLM and back). What you'll be given • The BridalLive starter codebase (untested, as noted above) with a detailed README. • Access to the open BridalLive support thread and QA credentials. • The shop's existing SOPs and decision-tree documentation to ground WhatsApp answers in. • Access to the WordPress/WooCommerce site as needed. • A single point of contact (the business owner) for questions and approvals. Scope, timeline & budget Rough estimate only, to be refined by whoever bids: BridalLive connector (including debugging the untested starter) is probably 20–35 hours; the WhatsApp connector, being a new build with a third-party verification step outside anyone's control, is probably 25–45 hours; the WooCommerce sync is probably 15–25 hours once the BridalLive inventory endpoint is confirmed.