> ## Documentation Index
> Fetch the complete documentation index at: https://docs.interchange.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Inventory feed profiles

> Register an exact feed capability and use the authenticated canonical REST bulk transport

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

| Requested profile                  | Capability | Canonical profile and key     | Semantics          |
| ---------------------------------- | ---------- | ----------------------------- | ------------------ |
| `static-avails-feed:v1`            | HITL       | `static-avails-feed:v1`       | `PATCH_UPSERT`     |
| `static-avails-feed:v1-push`       | API push   | `static-avails-feed:v1`       | `PATCH_UPSERT`     |
| `wholesale-avails-pricing:v1`      | HITL       | `wholesale-avails-pricing:v1` | `FULL_REPLACEMENT` |
| `wholesale-avails-pricing:v1-push` | API push   | `wholesale-avails-pricing:v1` | `FULL_REPLACEMENT` |

`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:

```json theme={null}
{
  "name": "create_inventory_feed",
  "arguments": {
    "inventorySourceId": "my-publisher-source",
    "profileId": "static-avails-feed",
    "profileVersion": "v1-push"
  }
}
```

```bash theme={null}
curl -X POST "$BASE/inventory-sources/my-publisher-source/feeds" \
  -H "Authorization: Bearer $SCOPE3_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"profileId":"static-avails-feed","profileVersion":"v1-push"}'
```

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.