Skip to main content
Manufacturing API (Roadmap)roadmap

Manufacturing API — Roadmap Overview

Manufacturing endpoints are NOT yet exposed at /public/v1/*. The internal HelloBooks app uses six manufacturing controllers today; the public-API curated subset is roadmap.

Where we stand today

**The HelloBooks Manufacturing API is on the roadmap, not yet shipped to /public/v1/*.** This page exists so integrators can preview the planned contract, register interest, and start designing against a stable shape.

Two facts to internalize before building:

  1. The manufacturing internal app routes (/bom, /work-orders, /recipes, /quality-inspections, /subcontract-orders, /manufacturing-reports) exist today and serve the HelloBooks frontend. They authenticate user JWTs only and explicitly reject marketplace tokens with Marketplace app tokens cannot be used on user routes. Do not point your integration at them.
  2. The public API gateway (/public/v1/*) is live but currently exposes only auth-foundation, health, /me, and webhook-subscription endpoints. The curated subset for invoices/bills/customers is stubbed (501) pending follow-up work; manufacturing follows after that.

Subscribing to manufacturing topics on a webhook subscription today will create the subscription, but no events are published yet — the publisher work lands alongside the public-API exposure.

What will land

When manufacturing ships to the public API, the curated subset will mirror the internal HTTP shape with three changes:

  • URL pattern: /public/v1/orgs/:orgId/entities/:entityId/<resource>/... (vs internal /<resource>/...)
  • Auth: Bearer marketplace token (vs internal user session JWT)
  • Response shape: @internal-tagged fields stripped (e.g. raw repository internals will not be exposed)

Six resources are in scope:

ResourceInternal route prefix todayPlanned scope
BOM/bombom:read, bom:create, bom:update, bom:delete
Work Orders/work-ordersworkOrder:read, workOrder:create, workOrder:update, workOrder:delete
Recipes/recipesrecipe:read, recipe:create, recipe:update, recipe:delete
Quality Inspections/quality-inspectionsqualityInspection:read, qualityInspection:create, qualityInspection:update, qualityInspection:delete
Subcontract Orders/subcontract-orderssubcontractOrder:read, subcontractOrder:create, subcontractOrder:update, subcontractOrder:delete
Manufacturing Reports/manufacturing-reportsmanufacturingReport:read

Planned webhook events

Manufacturing will publish events through the existing webhook subscription mechanism (see webhook subscriptions quickstart). Topics will follow the standard <domain>.<resource>.<verb> pattern. Anticipated topics:

  • work_order.released — Work Order moves from Draft → InProgress (allocations created)
  • work_order.completed — Work Order moves from InProgress → Completed (stock movements posted)
  • work_order.cancelled — any non-completed → Cancelled (allocations released)
  • bom.created / bom.updated / bom.archived / bom.restored
  • subcontract_order.materials_issued / subcontract_order.goods_received / subcontract_order.completed
  • quality_inspection.created / quality_inspection.completed

Lot traceability, ECO, and job-work-challan events (e.g. lot.created, eco.released, jobwork_challan.overdue) are tied to features still on feature branches and have no defined timeline yet.

How to register interest

If your integration depends on any of the above, contact your HelloBooks partner manager with:

  1. The resource(s) you need (BOM read-only? Work Order full lifecycle?)
  2. The use case (one or two sentences — "we run an ERP middleware that syncs WIP" beats "everything")
  3. Whether you need webhook events or polling is acceptable
  4. Your timeline / launch dependency

Prioritization is driven by partner demand. Concrete use cases move faster than wish lists.

Frequently asked questions

Can I just call /bom or /work-orders directly with a marketplace token?

No. The user-token middleware on those routes explicitly rejects marketplace tokens with HTTP 401 "Marketplace app tokens cannot be used on user routes." Even with valid scopes, the audience guard fires first.

Are the internal route shapes shown in the resource pages stable?

The internal shape is what the HelloBooks frontend reads today, so it is reasonably stable. But the curated public-API subset will strip @internal fields and may rename/normalize keys (e.g. PascalCase → snake_case in some envelopes). Treat the internal shape as a 90% preview, not a contract.

    HelloBooks Manufacturing API — Roadmap