GET `/v1/receiving/{posReceivingId}`

Get a receiving document live by POS receiving id

Key	Required. See Authentication.
Capability	`purchasing-data`
Scope	`purchasing.read`
Price	1 credit, per call. How pricing works.
Estimate	Add `estimate=true` for a free quote. With estimate=true the 200 body is EstimateResponse (a priced quote for exactly this request), not the schema documented under responses.200; nothing is reserved or dispatched.

Example

curl -s "https://api.compudime.com/v1/receiving/{posReceivingId}" \
  -H "Authorization: Bearer $PUBLIC_API_KEY"

Parameters

Name	In	Type	Description
`posReceivingId` required	path	string	The POS receiving id (receivingId on any receiving row), percent-encoded as ONE path segment: a / inside the id must be sent as %2F. 1-40 characters: a letter or digit, then letters, digits, spaces or . _ # & + @ / = -; anything else, and an unencoded /, is a free 400 before billing. At most 40 characters. Pattern: ^[A-Za-z0-9][A-Za-z0-9 ._#&+@/=-]{0,39}$
`fields`	query	string	Comma-separated receiving detail fields to include (see x-compudime-field-catalog), or * for every field the key may see. Omitted: a flat-priced endpoint returns every field; once IT prices the endpoint by field count (includedFields in x-compudime-pricing), an omitted fields returns the standard set at the base price and each field beyond the included count adds extraFieldCost. An unknown or denied field is a free 400 field_not_allowed.
`estimate`	query	boolean	When true, returns EstimateResponse instead of the normal body and never reserves credits: the request is authenticated, authorized and field-resolved exactly like a real call, then priced by billing (base cost plus extra-field credits for the resolved fields) and returned without dispatching to the store. Free of charge. Default: false.

Responses

Status	Description	Body
`200`	The live receiving document with that POS receiving id, with its lines (ordered next to received, in cases; costs per case).	`ReceivingResponse`
`400`	The posReceivingId is missing, longer than 40 characters, contains characters outside the documented set, or carries an unencoded / (code bad_request); or a requested field is not allowed (code field_not_allowed). Rejected before billing.	`Problem`
`401`	Public API key is missing, invalid, or revoked.	`Problem`
`402`	The request was blocked by billing policy: no_api_plan (no plan funds this meter), billing_card_missing, billing_card_failed, usage_exhausted, overage_cap_reached, subscription_paused, sandbox_exhausted, or billing_blocked. A key the store pays for under its approval gets grant_cap_exceeded (the store's monthly limit for your calls) or payer_billing_blocked (the store cannot be charged right now; ask the store owner) instead: what is wrong with the store's billing is not shown to it.	`Problem`
`403`	capability_not_enabled: the API key's integration was not created for the purchasing-data capability, or CompuDime has not enabled that capability for the store. Rejected before billing. No other capability implies it: a sales-data key answers this too. purchasing_data_not_enabled: the key is entitled, but the store has not turned on purchasing data on its own POS agent (the store-side purchasingDataEnabled opt-in, which the store's per-item sales-data opt-in does not imply). The reservation is released, nothing is charged; ask the store to enable it.	`Problem`
`404`	The store has no receiving document with that POS receiving id (code receiving_not_found; an expense invoice such as rent or utilities is not a receiving document and counts as not found). The reservation is released, nothing is charged.	`Problem`
`405`	The requested method is not allowed for this endpoint.	`Problem`
`422`	scope_not_applicable: the API key carries a row scope, and no row scope can be applied to a purchasing document (its totals and lines span every product on it); rejected before billing. receiving_unsupported: the store's POS database has no receiving tables these reads can answer. The reservation is released, nothing is charged.	`Problem`
`429`	Too many requests from this API key (code rate_limited). Each key has its own request budget at the API edge, refilled continuously; it covers every authenticated endpoint, including the free ones, and is checked before anything is billed or sent to the store. Billed endpoints are also subject to the store plan's per-minute ceiling, which answers the same problem code. Wait at least Retry-After seconds before the next request with this key, then resume; if 429 answers again, back off exponentially (double the wait each time, up to a minute or so) and add random jitter so parallel workers do not retry in step. A 429 is never charged and reserves nothing. Header `Retry-After`: Whole seconds to wait before retrying with this key: the time until the key's next request token at the edge (never less than 1), or 60 when the store plan's per-minute ceiling refused the call.	`Problem`
`500`	The API edge encountered an internal error.	`Problem`
`502`	The store's POS could not complete the receiving read (code store_error): the agent answered an error, or the agent or relay build predates this operation. The reservation is released.	`Problem`
`503`	The store's POS agent is offline (code store_offline), or a Public API dependency is unavailable. The reservation is released. Also answered, with code endpoint_disabled, while CompuDime has temporarily switched the endpoint off: the whole API, the endpoint's family (x-compudime-family) or this endpoint alone; the detail says which and why. It is checked before anything is validated, reserved or sent to the store, so it is never charged; it is retryable and carries Retry-After. Header `Retry-After`: Sent with code endpoint_disabled: whole seconds to wait before asking again. A switch has no scheduled end, so this is a polling interval (60), not a promise.	`Problem`
`504`	The store did not answer inside the read ceiling (code store_timeout). The reservation is released.	`Problem`

Error bodies are problem JSON; every code is listed there.

Fields

Choose with fields=; see Choosing fields.

All fields	`receivingId`, `number`, `vendorId`, `vendorName`, `vendorCode`, `vendorInvoiceNumber`, `date`, `billDue`, `businessDay`, `purchaseOrderId`, `purchaseOrderNumber`, `transactionType`, `statusCode`, `quick`, `ignoreInventory`, `inventoryLocation`, `source`, `discountPercent`, `totals`, `createdAt`, `modifiedAt`, `lines`, `linesTruncated`
Standard set	`receivingId`, `number`, `vendorId`, `vendorName`, `vendorCode`, `vendorInvoiceNumber`, `date`, `billDue`, `businessDay`, `purchaseOrderId`, `purchaseOrderNumber`, `transactionType`, `statusCode`, `quick`, `ignoreInventory`, `inventoryLocation`, `source`, `discountPercent`, `totals`, `createdAt`, `modifiedAt`, `lines`, `linesTruncated`

Access level

What your integration's access level changes here.