Bin Content Table in Business Central: API & Schema

The Bin Content table (table 7302) in Microsoft Dynamics 365 Business Central stores the relationship between a Bin and the items that can or do reside in it. Each row represents one combination of Location, Bin, Item, Variant, and Unit of Measure, and carries the per-bin replenishment parameters (Min. Qty., Max. Qty.), placement flags (Fixed, Default, Dedicated, Cross-Dock Bin), and read-time FlowFields that summarise the bin’s current and committed quantities. Bin Content is what makes warehouses with Bin Mandatory work: the warehouse engine reads it (not Item Ledger Entry) when deciding where stock physically is, where it should go, and whether a bin is allowed to receive more.

Microsoft API status

The Bin Content table is not exposed in the Business Central REST API v2.0. There is no standard binContents endpoint. Historically the workaround was to publish Page 7304 (Bin Content) or Page 7305 (Bin Contents List) as an OData web service, but Microsoft is deprecating the practice of exposing standard pages as APIs, so that path is no longer recommended for new integrations. The remaining options are to write a custom API page in AL and deploy it as an extension to every tenant, or to use Skuno BI, which exposes the table as a full OData v4 endpoint (https://<tenant>.skuno.app/api/v2.0/odata/bc/Bin_Content_7302) without per-environment AL development.

Anything that does slotting analysis, replenishment, or order promising needs both the live bin quantity and the constraints that govern it. The usual workaround is to read Warehouse Entry and re-derive the bin parameters in client code, but that loses every flag on the row (Fixed, Default, Dedicated) and every constraint (Min. Qty., Max. Qty., Block Movement, Warehouse Class Code) that actually decides how picking and put-away happen.

When to use the Bin Content table

Use Bin Content when you need a bin-level view: how much of an item is in a particular bin right now, whether a bin is the home for an item, whether it’s blocked inbound or outbound, or what the bin’s replenishment trigger is. Use Warehouse Entry when you need the immutable ledger of every movement (and the point-in-time history). Use the SKU table when you need per-location planning parameters but don’t care which bin the stock sits in.

A useful rule of thumb: if your warehouse operator ever says “the system thinks Bin A-01-01 has 12 pallets but it actually has 11,” you’re looking at a Bin Content vs. Warehouse Entry reconciliation problem, not an Item Ledger Entry one.

Query examples

AL

var
    BinContent: Record "Bin Content";
    MinQtyBase: Decimal;
begin
    BinContent.SetRange("Location Code", 'WHITE');
    BinContent.SetRange(Fixed, true);
    BinContent.SetFilter("Item No.", '1000..1999');
    BinContent.SetAutoCalcFields("Quantity (Base)", "Pick Quantity (Base)");
    if BinContent.FindSet() then
        repeat
            MinQtyBase := BinContent."Min. Qty." * BinContent."Qty. per Unit of Measure";
            if BinContent."Quantity (Base)" < MinQtyBase then
                // bin is below the replenishment threshold
        until BinContent.Next() = 0;
end;

SetAutoCalcFields is the AL pattern for FlowField-heavy tables: it tells the platform to evaluate the listed FlowFields on every FindSet/Next, which is a single round trip rather than one per row.

SQL (on-prem only)

SELECT TOP 100
    [Location Code], [Bin Code], [Item No_], [Variant Code], [Unit of Measure Code],
    [Min_ Qty_], [Max_ Qty_], [Fixed], [Default], [Dedicated]
FROM [CRONUS$Bin Content$00000000-0000-0000-0000-000000000000]
WHERE [Location Code] = 'WHITE'
  AND [Fixed] = 1;

Direct SQL access is only supported on Business Central on-prem deployments; SaaS environments lock down the database. Note that SQL only returns the stored columns: every quantity field on Bin Content is a FlowField, so a SELECT * FROM "Bin Content" returns no current quantities. You have to join Warehouse Entry and aggregate by the same key to reconstruct the FlowField values.

Custom API page (AL)

page 50100 "Bin Content API"
{
    PageType = API;
    SourceTable = "Bin Content";
    APIPublisher = 'contoso';
    APIGroup = 'warehouse';
    APIVersion = 'v1.0';
    EntityName = 'binContent';
    EntitySetName = 'binContents';
    DelayedInsert = true;
    ODataKeyFields = SystemId;

    layout
    {
        area(content)
        {
            repeater(Group)
            {
                field(locationCode; Rec."Location Code") { }
                field(binCode; Rec."Bin Code") { }
                field(itemNo; Rec."Item No.") { }
                field(variantCode; Rec."Variant Code") { }
                field(unitOfMeasureCode; Rec."Unit of Measure Code") { }
                field(minQty; Rec."Min. Qty.") { }
                field(maxQty; Rec."Max. Qty.") { }
                field(fixed; Rec.Fixed) { }
                field(default; Rec.Default) { }
                field(quantityBase; Rec."Quantity (Base)") { }
            }
        }
    }
}

A custom API page is now the only Microsoft-supported way to expose Bin Content over HTTP from a SaaS tenant. It must be deployed as part of an AL extension to each environment that needs it, and every FlowField you list (like quantityBase above) is recalculated against the live transactional tables on every read.

Skuno BI (OData v4)

Skuno BI exposes Bin Content as a full OData v4 endpoint. The path is tenant-scoped and table-numbered, so the table is addressable without any per-environment AL deployment.

The response is a superset of the base schema documented above: in addition to every base-table field, Skuno BI surfaces every FlowField evaluated server-side and any columns added by table extensions installed on the tenant. Warehouse and Manufacturing modules can add fields here (especially around Bin Type Code semantics); third-party WMS apps frequently do as well. The $metadata document at the endpoint root reflects whichever extensions are actually deployed on the tenant.

GET https://mycompany.skuno.app/api/v2.0/odata/bc/Bin_Content_7302
    ?$filter=Location_Code eq 'WHITE' and Fixed eq true
    &$select=Location_Code,Bin_Code,Item_No,Variant_Code,Unit_of_Measure_Code,Quantity_Base,Pick_Quantity_Base,Min_Qty,Max_Qty
    &$top=100

A trimmed response:

{
	"@odata.context": "https://mycompany.skuno.app/api/v2.0/odata/bc/$metadata#Bin_Content_7302",
	"value": [
		{
			"Location_Code": "WHITE",
			"Bin_Code": "W-01-0001",
			"Zone_Code": "PICK",
			"Item_No": "1000",
			"Variant_Code": "",
			"Unit_of_Measure_Code": "PCS",
			"Qty_per_Unit_of_Measure": "1",
			"Min_Qty": "10",
			"Max_Qty": "100",
			"Fixed": 1,
			"Default": 1,
			"Dedicated": 0,
			"Cross_Dock_Bin": 0,
			"Block_Movement": "_0",
			"Warehouse_Class_Code": "",
			"Bin_Ranking": 100,
			"Quantity_Base": "37",
			"Pick_Quantity_Base": "4",
			"Put_away_Quantity_Base": "0",
			"Positive_Adjmt_Qty_Base": "0",
			"Negative_Adjmt_Qty_Base": "0",
			"ATO_Components_Pick_Qty_Base": "0",
			"systemId": "{A7B23F8C-E43A-F111-BEC2-6045BDC3ECAB}",
			"SystemCreatedAt": "2026-04-18T05:10:56.417Z",
			"SystemModifiedAt": "2026-05-22T11:42:08.911Z"
		}
	]
}

Standard OData query options apply: $filter, $select, $top, $skip, $orderby, and $count.

Gotchas

Almost every quantity is a FlowField, not a column. Quantity, Quantity (Base), Pick Qty., Put-away Qty., Pos. Adjmt. Qty., Neg. Adjmt. Qty., and the ATO variants are all FlowFields summed from Warehouse Entry or Warehouse Activity Line. SQL SELECT * returns zero for every one of them. AL queries that don’t use SetAutoCalcFields or CalcFields see zero too. The only “stored” quantitative fields on the row are Min. Qty., Max. Qty., and Qty. per Unit of Measure.

Min. Qty. and Max. Qty. are in the row’s UoM, not in base units. The bin’s replenishment check multiplies them by Qty. per Unit of Measure before comparing against Quantity (Base). A bin with Min. Qty. = 2 PALLET and Qty. per Unit of Measure = 48 means a 96-piece base threshold, not a 2-piece one.

OnDelete is stricter than “empty.” Even if Quantity (Base) is zero, the OnDelete trigger still errors out if there are open pick, put-away, or warehouse-journal lines referencing the bin. The “the bin looks empty so I’ll delete the row” workflow fails as soon as a pick is pending.

Dedicated bins return 0 from the standard available-to-pick figure. This is by design, since the stock in a dedicated bin is reserved for a specific resource. Integrations that need to see this stock as available have to use the “including dedicated” variant of the available-to-pick call explicitly, and won’t get it from a generic on-hand query.

Capacity checks span every row in the bin. Max. Qty. validation sums projected cubage and weight across every Bin Content row at the same Location Code / Bin Code (regardless of item), and prompts the user when Bin."Maximum Cubage" or Bin."Maximum Weight" would be exceeded. A change to one row can therefore be rejected because of stock owned by a different item in the same bin.

Published-page OData is being deprecated. Publishing Page 7304 (Bin Content) or Page 7305 (Bin Contents List) as an OData web service was the historical workaround for the missing API. Microsoft is winding that pattern down, and the page-based property names were always unstable, as they’re derived from the AL caption and can break when the page is edited. New integrations should use a custom API page in AL or a sync-based product like Skuno BI rather than starting on page-based OData today.

How Skuno BI exposes Bin Content

Skuno BI surfaces the full Bin Content table, including FlowFields and any columns added by Warehouse or third-party table extensions installed on the tenant, as a queryable OData v4 endpoint at https://<tenant>.skuno.app/api/v2.0/odata/bc/Bin_Content_7302. Bin, Location, Warehouse Entry, Warehouse Activity Line, and the rest of the warehouse-relevant tables are exposed on the same convention, with the BC table number suffixed onto the resource name. Standard OData query options ($filter, $select, $top, $orderby, $count) work against any column, including FlowFields like Quantity_Base, Pick_Quantity_Base, and Put_away_Quantity_Base, which are evaluated server-side so consumers don’t have to mimic CalcFields. The endpoint is backed by an analytical column store, so filter performance doesn’t depend on the underlying BC SQL keys.

Change tracking on calculated fields

Bin Content is where Skuno BI’s change tracking on FlowFields earns its keep. The Quantity (Base) on a Bin Content row is a sum of Warehouse Entry, and Pick Quantity (Base), Put-away Quantity (Base), and the adjustment quantities work the same way — calculated at read time from the warehouse transaction tables, never persisted on the row. Warehouse Entry holds the full history, but recovering it means either subscribing to the entire entry stream and re-summing on every event (for change notifications) or scanning back to the right cutoff (for a point-in-time read). Both are expensive against the live BC SQL store, and neither is something most integrations are equipped to do on their own.

Skuno BI exposes its own RowVersion column on every synced table. BC’s SystemRowVersion is backed by SQL Server’s native rowversion type, so it only advances when a stored column on the row itself is written. Skuno BI’s RowVersion advances when a FlowField value changes too. A pick that drops Quantity (Base) from 40 to 35 adds a row to Warehouse Activity Line and never touches the Bin Content row: SystemRowVersion doesn’t move, Skuno BI’s RowVersion does. That makes delta sync viable on a FlowField-heavy table like this one — an integration filtering RowVersion gt <last sync> sees the bin movements, not just the metadata edits, and it doesn’t have to replicate the Warehouse Entry stream to do it.

For finer-grained history — what Quantity (Base) was at 2pm last Tuesday rather than at the last sync — Warehouse Entry sits in the same analytical store, indexed for the aggregations FlowFields perform. A Skuno BI Query that derives bin contents over time runs against the historical record there, with the aggregation pushed down to the column store rather than executed in client code or against the production BC database. Forecasting, audits, and “when did this bin go negative?” investigations become a Query filtered by Location/Bin/Item/Variant/UoM and date.

The same combination lets you audit Min. Qty. and Max. Qty. changes against what the bin actually held over the same window. The stored-field change feed on Bin Content joins to a derived Quantity_Base timeline against Warehouse Entry, so “who changed Max. Qty. to 200 on 12 May, and what did Quantity (Base) do over the next two weeks?” is one Query rather than a two-stage scrape.

None of this needs AL development on a per-tenant basis. Bin Content sits behind every pick, put-away, and replenishment decision in your warehouse, and reading it (with history) out of your own database shouldn’t require developing and maintaining a custom extension just to get an API page.

See how Skuno BI surfaces Business Central data →