Skip to main content
An inventory feed registration binds one source, one proven module assignment, and one canonical profile identity. Registration is idempotent. The canonical key is always canonicalProfile.profileId:canonicalProfile.profileVersion; it is derived by the server and cannot be supplied by a caller.

​
Supported profile capabilities

v1-push is capability evidence, not a second feed identity. It proves the exact API-push assignment while creating or returning the same canonical v1 head used by HITL. Foundation, non-feed, unratified, and unknown profiles are rejected.

​
Register a feed

Use create_inventory_feed or the equivalent REST endpoint:
The response contains the canonical feedId and key, canonical and requested profiles, the exact module assignment, standard tenant/storefront bearer-auth requirements, and scoped data-plane paths. It never returns a secret or a feed-specific credential. Retrying the same request returns the same feed. For HITL, the returned paths are:
  • POST /inventory-sources/:sourceId/feed/preview
  • POST /inventory-sources/:sourceId/feed/upload
  • POST /inventory-sources/:sourceId/feed/commit
The push path is returned only when exact v1-push capability evidence was requested and proven:
  • POST /inventory-sources/:sourceId/feed/push
These authenticated REST endpoints are the canonical bulk transport for feed bytes. Control-plane tool results contain identities, counts, digests, states, and paths—not feed rows, CSV/JSON text, secrets, or raw diagnostic payloads.

​
Status and transport authority

GET /inventory-sources/:sourceId/feeds/:feedId and get_inventory_feed_status return the canonical identity, registered capabilities, active head, sync health, and latest attempt. The feed-level registrationTransport records how the head was first registered; it is not the active transport. head.transport and latestAttempt.transport come from the active/latest revision. Therefore an API-push revision can report API_PUSH while the canonical profile and key remain v1. Latest-attempt diagnostics are summarized as a count and codes. Raw rows and diagnostic payloads are not returned by these control-plane reads.

​
Explicitly unsupported operations

Registration returns structured UNSUPPORTED_OPERATION diagnostics for pull, schedule, provider trigger, credential issuance, credential rotation, credential revocation, and signed transfer. The control plane does not create, return, or manage secrets for any of these operations.

​
Compatibility bridge debt

The current app-only Inventory Feed Task still has a compatibility bridge to the older modular/wholesale import endpoints. That bridge can carry feed input inside app-only tool calls, and its audit projection is deliberately limited to IDs, counts, digests, and statuses. It remains migration debt: integrations should use the authenticated canonical REST preview/upload/commit or push paths for bulk data instead of treating the app-only bridge as the public transport.