Vendor integration for automatic parts reordering

Keiko, thank you for the detailed context. In my experience working with operations teams in your range, the procurement automation question usually surfaces once inventory management matures inside FieldPulse — which sounds like where you are.

What I typically recommend is a staged approach rather than trying to solve the full stack in one implementation. FieldPulse's native inventory capabilities handle the consumption side exceptionally well: tracking parts to jobs, maintaining accurate counts, and surfacing low-stock alerts. The procurement trigger, however, requires bridging to your supplier systems.

Currently, FieldPulse does not maintain direct vendor API integrations for purchase order submission. The platform exposes inventory events via webhook (stock level changes, threshold breaches) that your middleware or ERP can consume. What I've seen work in practice is using FieldPulse as the system of record for field consumption while keeping the ERP authoritative for procurement. The webhook fires to a middle layer — something like Zapier, Make, or a custom Azure function — which translates the event into a purchase requisition in your ERP.

From a configuration standpoint, you'd set your reorder thresholds in Settings > Inventory > Alerts, then subscribe to the inventory.threshold_breached webhook event. The payload includes the part number, current quantity, and configured reorder point — sufficient for your middleware to calculate order quantities and submit to your vendor's API or portal.

For the audit trail requirement you mentioned: webhook deliveries are logged in FieldPulse, but the procurement action itself would be auditable in whichever system generates the PO. If you need a unified audit view, that's a custom integration consideration we'd scope separately.

Happy to discuss specific vendor APIs if you'd like to share which suppliers you're working with — some have more mature EDI or API capabilities than others.

We've got a similar setup running — 35 techs, Ferguson and Grainger as primary suppliers. YMMV depending on your vendor's API maturity, but here's what actually worked for us:

• FieldPulse webhooks → Make (Integromat) → Ferguson's API for most items
• Grainger still needs manual PO entry because their API requires pre-negotiated EDI agreements we don't have
• We built a small Node service that sits between Make and Ferguson to handle auth token refresh and line-item validation

Worth noting: Ferguson's API has a quirk where they require your customer branch code in every request, not just the auth handshake. Took us a while to catch that.

The webhook payload from FieldPulse is reliable, but heads up — it doesn't include your preferred vendor per part. We maintain that mapping in a separate lookup table. If you're expecting FieldPulse to tell you which vendor to order from, you'll need to build that logic downstream.

Happy to share our Make blueprint if helpful.

@devon.marsh what endpoint are you hitting on Ferguson's side? Their v2 API docs mention /purchase-orders but last I checked it was still in beta with whitelist access only. Are you on the legacy SOAP integration?

From a governance perspective, I would strongly caution against routing procurement approvals through automation layers without explicit sign-off thresholds. It is worth noting that SOX-compliant organizations typically require segregation of duties between inventory consumption recording and purchase authorization.

If FieldPulse is generating the consumption event and also triggering the procurement action through webhooks, you have effectively collapsed those duties unless your middleware enforces approval gates. From a policy standpoint, I recommend:

1. Webhook generates purchase requisition, not purchase order
2. Requisition enters your ERP's standard approval workflow
3. Only upon approved status does PO transmit to vendor

Additionally, ensure webhook payload signing is verified at your middleware layer — FieldPulse supports HMAC-SHA256 signatures. Without this, you are exposed to spoofed inventory events triggering unauthorized procurement.

Audit trail completeness will depend on whether your middleware logs the full request/response cycle. FieldPulse's native webhook logs do not capture downstream system responses.

We're on the beta — had to get our account rep to flag us for access. Took about two weeks. The SOAP route is documented but we didn't want to deal with the XML parsing overhead. If you're stuck waiting for beta access, I've heard of teams screen-scraping the B2B portal as a stopgap, but that's obviously brittle.

Keiko, happy to help clarify the current state of native functionality.

FieldPulse does not currently offer direct vendor integrations for automatic purchase order submission. Daniel and Devon have outlined the standard architecture our customers use: webhook events to middleware to supplier APIs.

For your specific requirements:

Automated reorder triggers: Yes — configurable in Settings > Inventory > Low Stock Alerts. You can set per-part thresholds and receive notifications. For programmatic use, subscribe to the webhook Daniel mentioned.

Purchase order generation with approval workflow: This lives outside FieldPulse today. Most customers in your scale range integrate with ERPs (NetSuite, Sage Intacct, or custom) that handle procurement governance.

Audit trails: FieldPulse captures inventory adjustments, consumption events, and alert triggers in Admin > Audit Logs. Procurement actions initiated downstream would be logged in your ERP.

If you're evaluating whether to shift procurement authority into FieldPulse, I'd be glad to connect you with our product team for a roadmap discussion. We are actively exploring deeper ERP integration patterns, but I don't have committed timelines for native procurement workflows.

See this article for full steps on webhook configuration: Setting Up Webhooks

Thank you all. This confirms my suspicion that we'd be building middleware regardless of direction.

Devon — I'll follow up on your Make blueprint separately. Ferguson's API access is worth pursuing.

Priya — please do connect me with product. Even absent committed timelines, understanding roadmap priorities helps our capex planning.

We'll proceed with webhook-to-ERP architecture for Q1 and revisit native options if they materialize.