Fulcrum Integration Guide for Production Scheduling with SkyPlanner APS

Fulcrum is one multi-tenant cloud product, so every customer runs the same API. The developer hub describes it as a public API for “REST API calls directly into your Fulcrum site.”

• Spec. OpenAPI “Fulcrum PublicAPI” v1, downloadable at https://api.fulcrumpro.com/swagger/v1/swagger.json. Fulcrum suggests generating a typed client from it. A dated History page lists every change.
• Hosts. https://api.fulcrumpro.com for standard sites. ITAR sites use api.fulcrumpro.us, and ITAR tokens receive a 401 on the .com host.
• Style. Lists are POST .../list with a filter body, Skip and Take paging and Sort.Field / Sort.Dir. Many objects accept PUT, and jobs also accept JSON Patch.

The endpoints a scheduling integration uses:

Fulcrum’s own integrations page is direct about the work: “Every system is a little bit different and requires some configuration.” The SkyPlanner team takes on exactly that configuration during onboarding.

Fulcrum supports webhooks, configured by an admin. Since September 2026, failing webhooks pause and are re-tested daily instead of retrying forever. The API History names events such as PurchaseOrderUpdated and ItemUpdated.

The integration reads Fulcrum like this:

• Open jobs filtered to scheduled and inProgress with hasIncompleteOperations: true, polled every few minutes. This is the filter Fulcrum itself gives for matching its schedule page.
• Purchase orders and inventory before each schedule run, or on a PurchaseOrderUpdated webhook where it is configured.
• Items, routings, equipment and shifts on change, or nightly.

In the other direction, SkyPlanner’s own webhooks push schedule changes as they happen, so the write-back side is event-driven.

1. Initial master data load. Pull items, materials, routings, work centers and equipment, then department shifts and downtimes. Each Fulcrum work center becomes a SkyPlanner workstation group with its equipment as members, and each routing operation’s selected equipment becomes its allowed workstations. Unlimited Capacity equipment such as ovens and paint booths becomes batch jobs.

2. Order sync. Read open jobs with their items to make and operations, plus open purchase orders and inventory. SkyPlanner treats ordered material as available on the PO delivery date and updates stock when the PO is marked Delivered. The schedule checks stock and incoming purchases on every replan.

3. Schedule write-back. Fulcrum computes scheduledStartUtc, scheduledEndUtc and scheduledEquipmentId itself and returns them read-only. The operation update accepts customFields. SkyPlanner writes planned start, planned finish and workstation to custom fields on each job operation, and the planned finish to a job custom field. Sales and purchasing see SkyPlanner’s dates on the job in Fulcrum.

4. Shop-floor confirmations. Operators log work in SkyPlanner with Mobile Confirmations, Production Timer or Quick Log Mode. SkyPlanner posts the time to Fulcrum through /api/job-tracking-timers/start and /stop, or as a completed block through /api/timers. Quantities go through add-quantity-completed, and the final count with scrap through complete. Job costing in Fulcrum stays live.

5. Ownership and conflict rules. Fulcrum’s scheduler “dictates the order of operations in Job Tracking.” So pick one dispatch channel per operation: SkyPlanner’s operator queue or Fulcrum Job Tracking. Write the rules down before go-live:

• Labor lives in shift counts. Fulcrum’s Max Equipment per shift “is usually determined by how many people you have working in a certain area at that time.” Named operators and their shifts are set up in SkyPlanner. Users in /api/users give the names.
• Scheduling is to equipment. Fulcrum work centers are groups of interchangeable equipment. Keep the routing’s selected equipment accurate, because it becomes the alternatives the engine chooses between.
• Work orders group jobs. A work order groups operations of several jobs, for example a nest. A timer started on a grouped operation starts the work order timer instead, and it covers every job operation in the group.
• Timer limits. Retroactive /api/timers blocks “may not be in the future, older than 30 days, or longer than 7 days.” Post time as operators log it.
• Time formats differ. Shifts use local HHmm values, downtimes and scheduled dates are UTC, and operation estimates come in seconds.
• Equipment updates replace the whole record. An equipment PUT clears any field it omits. SkyPlanner reads equipment and never writes it.
• ITAR sites. Use the .us host and an ITAR token.