Collection

Replacements

Deprecation

Retirement

|\n|:--------------------------|:----------------------------------------------------------------------------------------------------|:----------|:----------|\n|V2 Employees |[Team API](${SQUARE_TECH_REF}/team-api)
[Migration guide](/team/migrate-from-v2-employees) |2020-08-26 |2021-09-15|\n|V2 Transactions |[Payments API](${SQUARE_TECH_REF}/payments-api)
[Migration guide](/payments-api/migrate-from-transactions-api) |2019-08-15 |TBD|\n\n### Retired\nThe following endpoints have been retired and are no longer supported by documentation. If you have not migrated your code to use Square API endpoints, refer to the migration guides in the table to learn about the needed migrations.\n|

Collection

Replacements

Deprecation

Retirement

|\n|:--------------------------|:----------------------------------------------------------------------------------------------------|:----------|:----------|\n|V1 Employees.Employees |[Team API](${SQUARE_TECH_REF}/team-api)
[Migration guide](/migrate-from-v1/guides/v1-employees) |2020-08-26 |2021-09-15 |\n|V1 Employees.EmployeeRoles |[Team API](${SQUARE_TECH_REF}/team-api)
[Migration guide](/migrate-from-v1/guides/v1-employees) |2020-08-26 |2021-09-15 |\n|V1 Employees.Timecards |[Labor API](${SQUARE_TECH_REF}/labor-api)
[Migration guide](/migrate-from-v1/guides/v1-timecards) |2020-02-26 |2021-02-26 |\n|V1 Employees.CashDrawers |[Cash Drawers API](${SQUARE_TECH_REF}/cash-drawers-api)
[Migration guide](/migrate-from-v1/guides/v1-cashdrawershifts)|2020-02-26|2021-02-26 |\n|V1Items |[Catalog API](${SQUARE_TECH_REF}/catalog-api)
[Inventory API](${SQUARE_TECH_REF}/inventory-api)
[Migration guide](/migrate-from-v1/guides/v1-items)|2019-11-20|2021-02-26|\n|V1 Locations |[Locations API](${SQUARE_TECH_REF}/locations-api)
[Migration guide](/migrate-from-v1/guides/v1-locations)|2019-11-20 |2020-11-18 | \n|V1 Transactions.BankAccounts|[Bank Accounts API](${SQUARE_TECH_REF}/bank-account-api)
[Migration guide](/migrate-from-v1/guides/v1-bankaccounts) |2020-02-26 |2021-02-26|\n|V2 Reporting |[Payments API](${SQUARE_TECH_REF}/payments-api)
[Migration guide](/payments-api/migrate-from-transactions-api) |2019-08-15 |2020-08-26|\n\n### Work in progress\nThe following endpoints will be deprecated when corresponding functionality is available in the Square API.\n\n|

Collection

Replacements

Deprecation

Retirement

|\n|:--------------------------|:----------------------------------------------------------------------------------------------------|:----------|:----------|\n|V1 Batching |Various
[Migration guide](/migrate-from-v1/general-guidance#batching) |2019-11-20 |TBD | \n|V1 Transactions.Payments |pending |TBD |TBD |\n|V1 Transactions.Refunds |pending |TBD |TBD |\n|V1 Transactions.Settlements|pending |TBD |TBD |\n"}},{"id":"LOYALTY_SANDBOX_PHONE","type":"constant","attributes":{"value":"You test the sample walkthrough in the Square Sandbox environment. After creating a loyalty program, you need a phone number to set up a loyalty account. In the Sandbox, you provide a Sandbox phone number, instead of a real phone number, using the following format:\n\n```\n+1555\n```\n\nFor example, +14255551111.\n"}},{"id":"MASTERPASS_LONG","type":"constant","attributes":{"value":"Masterpass (now Mastercard Click to Pay)"}},{"id":"MASTERPASS","type":"constant","attributes":{"value":"Secure Remote Commerce"}},{"id":"MASTERPASS_SRC","type":"constant","attributes":{"value":"!!!info\nThe names of `SqPaymentForm` ${MASTERPASS} (SRC) objects have not changed from the original Masterpass to minimize the amount of recoding that you must do to support SRC.\n!!!"}},{"id":"TERMINAL_CHECKOUT","type":"constant","attributes":{"value":"Terminal API"}},{"id":"TERMINAL_REFUND","type":"constant","attributes":{"value":"Terminal API"}},{"id":"MONITARY_AMOUNT_LIMITS","type":"constant","attributes":{"value":"## Monetary amount limits\n\nSquare enforces two lower numerical limits on cash and card payment amounts:\n* Smallest unit of currency \n* Minimum amount for a payment \n\nNote that cash and card payment amounts have different limits. \n\nThese limits vary by country as shown in the following table.\n\n|Country | Smallest unit of currency /
Minimum payment |\n|:-------------|:-------------------------------------------------------|\n|Australia |${DOLLAR_SIGN}:0.01 /
**Card:** ${DOLLAR_SIGN}1.00, **Cash:** ${DOLLAR_SIGN}0.05|\n|Canada |${DOLLAR_SIGN}:0.01 /
**Card:** ${DOLLAR_SIGN}0.01, **Cash:** ${DOLLAR_SIGN}0.05 |\n|Japan |${YEN_SYMBOL}: 1 /
**Card:** ${YEN_SYMBOL}100, **Cash:** ${YEN_SYMBOL}1 |\n|United Kingdom|${UK_POUND}:0.01 /
**Card:** ${UK_POUND}1.00, **Cash:** ${UK_POUND}0.01 |\n|United States |${DOLLAR_SIGN}:0.01 /
**Card:** ${DOLLAR_SIGN}0.01, **Cash:** ${DOLLAR_SIGN}0.01 |"}},{"id":"SQUARE_ONLINE_EAP","type":"constant","attributes":{"value":"!!!\nSquare Online APIs are publicly available as part of an early access program. For more information, see [Early access program for Square Online APIs.](/online-api#early-access-program-for-square-online-apis)\n!!!"}},{"id":"LOYALTY_WALKTHROUGH_SETUP_NOTE_AVAILABILITY","type":"constant","attributes":{"value":" !!!info\n These steps assume that you are setting up a loyalty program for the first time. To change an existing program, in the navigation pane, choose **Loyalty**, choose **Settings**, and then edit the **Earning Points** and **Redeeming Rewards** settings to match the settings described in this topic.\n\n The **Loyalty** page is available only if your Square account is activated in a [supported country,](/loyalty-api/overview#loyalty-market-availability) or if you open the Seller Dashboard with a [test account](/testing/create-and-authorize-sandbox-account) configured for a supported country. Custom test accounts use an OAuth access token instead of the Sandbox access token, so you must grant the account the [required permissions](/oauth-api/square-permissions) for the Square APIs used in this walkthrough. \n !!!"}},{"id":"CUSTOMER_ASSIGNMENTS_FOR_ORDERS_AND_PAYMENTS","type":"constant","attributes":{"value":"In the Seller Dashboard, transaction activity is based on the `customer_id` of the order and other related settings, but the `customer_id` of the payment is ignored. For example, if the order does not have a customer assignment, the transaction's **Paid by** field might not display the customer who is assigned to the payment. To reliably link transactions to customers in the Seller Dashboard, make sure to specify the `customer_id` field in your `CreateOrder` request. \n\nIn addition, omitting this field on the `Order` object might result in the creation of new [instant profiles](/customers-api/what-it-does?preview=true#instant-profiles) that are linked to the payment."}},{"id":"LOYALTY_TAX_ACCRUAL_LOGIC","type":"constant","attributes":{"value":"!!!info\nThe country of the seller's Square account determines whether tax is included in the purchase amount by default when accruing points for amount-spent and visit-based programs. For more information, see [Availability of Square Loyalty.](/loyalty-api/overview#loyalty-market-availability)\n!!!"}},{"id":"GIFT_CARD_ACTIVATE_OR_LOAD_ORDER_REQ","type":"constant","attributes":{"value":"If your application uses the Orders API to process gift card orders, the order must be in the `COMPLETED` state before you can use it to activate or load a gift card."}},{"id":"WALKTHROUGH_GATHER_ACCOUNT_INFO","type":"constant","attributes":{"value":"Follow these steps to get the access token and location ID used in this walkthrough.\n\n1. Sign in to the [Developer Dashboard](${APP_DASHBOARD}). If you do not have a Square account, see [Get Started](/get-started) to learn how to create an account and an application. \n2. Open your application.\n3. Get your Sandbox access token: \n 1. At the top of the page, in the **Sandbox** and **Production** toggle, choose **Sandbox**. \n 2. On the **Credentials** page, under **Sandbox Access Token**, choose **Show** and then copy the token. All Square API requests require an access token for authorization. This [personal access token](/build-basics/access-tokens) grants full access to the Sandbox resources in your account. \n4. Get your location ID: \n 1. In the navigation pane, choose **Locations**. \n 2. On the **Locations** page, keep **Default Test Account** selected and copy a location ID."}},{"id":"GIFT_CARD_PHYSICAL_CARD_IN_SANDBOX","type":"constant","attributes":{"value":"!!!info\nThis walkthrough creates a digital gift card in the Sandbox. Although testing physical gift cards is not supported in the Sandbox, you can register and activate physical gift cards in the production environment using the process described in this walkthrough.\n!!!"}},{"id":"SECURE_SANDBOX_ACCESS_TOKEN","type":"constant","attributes":{"value":"!!!important\nThe Sandbox access token is a secure secret. Do not share it with anyone.\n!!!"}},{"id":"MD_BLOCKS","type":"constant-set","relationships":{"constants":{"data":[{"id":"REUSE_BLOCK_FIND_LOCATION_INTRO","type":"constant"},{"id":"INFO_YOU_NEED","type":"constant"},{"id":"INFO_LOCATION_ID","type":"constant"},{"id":"INFO_APP_ID","type":"constant"},{"id":"INFO_APP_SECRET","type":"constant"},{"id":"INFO_ACCESS_TOKEN","type":"constant"},{"id":"PREREQ_ACTIVE_ACCOUNT","type":"constant"},{"id":"PREREQ_SQUARE_ACCOUNT","type":"constant"},{"id":"PREREQ_HTTPS","type":"constant"},{"id":"LIMIT_NO_SANDBOX","type":"constant"},{"id":"ASSUME_IOS","type":"constant"},{"id":"ASSUME_ANDROID","type":"constant"},{"id":"ASSUME_LOCALHOST","type":"constant"},{"id":"ASSUME_WEB_DEV","type":"constant"},{"id":"ASSUME_BACKEND","type":"constant"},{"id":"ASSUME_PRODUCT","type":"constant"},{"id":"BUY_SQUARE_READER_TIP","type":"constant"},{"id":"COF_ASK_PERMISSION","type":"constant"},{"id":"CONFIG_FILE_TIP","type":"constant"},{"id":"INFO_READER_SDK_REPO_PASSWORD","type":"constant"},{"id":"EXPAND_WITH_RECIPES","type":"constant"},{"id":"ASSUME_CONFIG_FILE","type":"constant"},{"id":"GET_APPID_LOCATIONID_WITH_ANIMATION","type":"constant"},{"id":"ASSUME_PAYMENTFORM_INTEGRATION","type":"constant"},{"id":"IAP_DIGITAL_WARNING","type":"constant"},{"id":"INFO_SANDBOX_APP_ID","type":"constant"},{"id":"SQUARE_SANDBOX","type":"constant"},{"id":"LOG_IN_AND_VIEW_SANDBOX_DASHBOARD","type":"constant"},{"id":"LOG_IN_AND_RETURN_TO_DOCPAGE","type":"constant"},{"id":"GET_HELP","type":"constant"},{"id":"PREREQ_SANDBOX_SDK","type":"constant"},{"id":"PREREQ_SANDBOX_CURL","type":"constant"},{"id":"GRN_CHK","type":"constant"},{"id":"V2_WEBHOOK","type":"constant"},{"id":"API_EXPLORER","type":"constant"},{"id":"DISPUTES_TEST_VALUES","type":"constant"},{"id":"DEPRECATION_TABLE","type":"constant"},{"id":"LOYALTY_SANDBOX_PHONE","type":"constant"},{"id":"MASTERPASS_LONG","type":"constant"},{"id":"MASTERPASS","type":"constant"},{"id":"MASTERPASS_SRC","type":"constant"},{"id":"TERMINAL_CHECKOUT","type":"constant"},{"id":"TERMINAL_REFUND","type":"constant"},{"id":"MONITARY_AMOUNT_LIMITS","type":"constant"},{"id":"SQUARE_ONLINE_EAP","type":"constant"},{"id":"LOYALTY_WALKTHROUGH_SETUP_NOTE_AVAILABILITY","type":"constant"},{"id":"CUSTOMER_ASSIGNMENTS_FOR_ORDERS_AND_PAYMENTS","type":"constant"},{"id":"LOYALTY_TAX_ACCRUAL_LOGIC","type":"constant"},{"id":"GIFT_CARD_ACTIVATE_OR_LOAD_ORDER_REQ","type":"constant"},{"id":"WALKTHROUGH_GATHER_ACCOUNT_INFO","type":"constant"},{"id":"GIFT_CARD_PHYSICAL_CARD_IN_SANDBOX","type":"constant"},{"id":"SECURE_SANDBOX_ACCESS_TOKEN","type":"constant"}]}}},{"id":"7v93KkCkyE6YGaMHE2HSD","type":"markdown-block","attributes":{"name":"Inventory API : How It Works : Intro","markdown":"Take a deeper look at the the Inventory API.\n\n{TOC}","programming-language":"All","platform":"All"},"relationships":{"constant-sets":{"data":[{"id":"DEVELOPERS_URLS","type":"constant-set"},{"id":"MD_BLOCKS","type":"constant-set"}]}}},{"id":"5m2hxuFGTw8KUEoUlCBCuS","type":"markdown-block","attributes":{"name":"Inventory API : How It Works : Process Flow","markdown":"## Inventory API process flow\n\nInventory unit counts are calculated by applying all the adjustments received since the last recorded physical count. If no physical count has been recorded, the adjustments are applied with an assumed starting unit quantity of zero. \n\nInventory changes (including changes due to sales transactions) can be sent to\nSquare out of order. As a result, adjustments and physical count updates require\na client-specified [RFC 3339 timestamp](https://tools.ietf.org/html/rfc3339)\n(`occurred_at`) so the inventory history can be ordered correctly.\n\nConsider a situation where the Square Point of Sale application processes transactions in offline mode while a custom inventory management solution makes inventory adjustments through the API.\n\nAssume that the related item variation starts with 100 IN_STOCK units.\n\n1. At 13:10 GMT, the inventory management backend sends an `InventoryAdjustment` request using the Inventory API to record a sale through a non-Square system and move 3 units from `IN_STOCK` to `SOLD`. At this point, there are 97 `IN_STOCK` units.\n1. At 13:20 GMT, the Square Point of Sale device goes offline. The seller sells 2 units in offline mode with a recorded transaction time of 13:20 GMT.\n1. At 13:30 GMT, the inventory management backend sends an `InventoryPhysicalCount` request using the Inventory API to reconcile the computed quantity in the Square inventory service (97 units) with a verified physical quantity available for sale (90 units).\n1. At 13:35 GMT, the Square Point of Sale device reconnects to the Internet and pushes the offline sale to Square, which moves 2 `IN_STOCK` units to `SOLD`. Square applies the transaction results, with a client timestamp of 13:20 GMT, before the `InventoryPhysicalCount` request that occurred at 13:30 GMT. Although the Point of Sale transaction was the last change sent to Square, the `IN_STOCK` quantity is still 90 units, as indicated by the physical count update, because the last change according to the client timestamp was the `InventoryPhysicalCount` request.\n1. At 13:40 GMT, the inventory management backend sends another `InventoryAdjustment` request using the Inventory API to move 2 from `IN_STOCK` to `WASTE` because they are no longer suitable for sale. The `InventoryAdjustment` request has a client timestamp that happens after the count reconciliation so the `IN_STOCK` count is now 88 units and the `WASTE` count is 2 units.\n\n![timeline-good](//images.ctfassets.net/1nw4q0oohfju/76MOBKLDlb5yIfcMvkpenE/fd987052fe950232fbd2d257230e0d71/timeline-good.png)\n","programming-language":"All","platform":"All"},"relationships":{"constant-sets":{"data":[{"id":"DEVELOPERS_URLS","type":"constant-set"},{"id":"MD_BLOCKS","type":"constant-set"}]}}},{"id":"77uu1BWePCBePZlbg42UzY","type":"markdown-block","attributes":{"name":"Inventory API : How It Works : Supplemental Topic - Reconciliation","markdown":"## Reconciliation with InventoryPhysicalCount\n\n`InventoryPhysicalCount` should only be used to reconcile the inventory count computed by Square with the results of performing a physical count or syncing with a trusted external system. Do not use `InventoryPhysicalCount` to apply sequential adjustments to `CatalogItemVariation` quantities. Retrieving an `InventoryCount` from the server, modifying the count based on recent changes, and pushing the updated inventory count as an `InventoryPhysicalCount` forces Square to ignore changes that might have occurred in the interim and results in inaccurate tracking.\n\nConsider the case where the Square Point of Sale application captures a sale after the `InventoryCount` request but before the `InventoryPhysicalCount` update.\n\n![timeline-bad](//images.ctfassets.net/1nw4q0oohfju/YpR6I8NFwzySymMKFTP74/bf8b9b6d8121778b939ae027e404c44c/timeline-bad.png)\n\nAssume that an application knows that 3 units were sold through a non-Square channel. The application calls the Inventory API and the `InventoryCount` result indicates 10 units in the `IN_STOCK` state. At the same time, the Square Point of Sale application captures a sale of 2 units and moves those 2 units from `IN_STOCK` to `SOLD`. There are now 8 units in the `IN_STOCK` state.\n\nBased on the `InventoryCount` result, the application incorrectly believes there are currently 10 units in the `IN_STOCK` state. If the application uses `InventoryPhysicalCount` to reduce the `IN_STOCK` quantity by 3, the final quantity of `IN_STOCK` units is forced to be 7 units (10 `IN_STOCK` units − 3 units sold externally) when it should be 5 units (10 `IN_STOCK` units − 2 units sold through the Square Point of Sale application − 3 units sold externally).\n\nThe correct way to track sales through a non-Square system is to push an `InventoryAdjustment` that moves units from `IN_STOCK` to `SOLD`. Inventory adjustments force Square systems to apply inventory changes in the correct order rather than explicitly overwriting the count. For example, by subtracting the 3 units sold externally after subtracting the 2 units sold through the Square Point of Sale application.\n","programming-language":"All","platform":"All"},"relationships":{"constant-sets":{"data":[{"id":"DEVELOPERS_URLS","type":"constant-set"},{"id":"MD_BLOCKS","type":"constant-set"}]}}},{"id":"4hffvk0l4x5wbcfrkdn0jM","type":"markdown-block","attributes":{"name":"Inventory API : How It Works : Supplemental Topic - Batching","markdown":"## Batched state transitions\n\nSquare servers record inventory operations based on timestamps provided by the communicating client and batched updates succeed or fail as atomic operations. For example, consider the case where a single request batches the following changes for a single item variation:\n\n* 100 units move from the `NONE` state to the `IN_STOCK` state.\n* 5 units move from the `IN_STOCK` state to the `WASTE` state.\n* Record a physical count of 90 units.\n\n![example-batch-update](//images.ctfassets.net/1nw4q0oohfju/1i30jeN26i722BFAIo5otN/920a7758f09b599e1fa15ec9366cfa09/example-batch-update.png)\n\nIndividual changes in a batched state are recorded based on their individual client timestamps, but they are applied (all or nothing) as a single request. Assuming that the inventory count for the targeted catalog item variation starts at zero:\n\n1. 100 units move from `NONE` to `IN_STOCK` with a timestamp of 23:00 GMT, making the calculated inventory count 100.\n1. 5 units move from `IN_STOCK` to `WASTE` with a timestamp of 23:10 GMT, making the calculated inventory count 95.\n1. The system records a physical count of 90 units with a timestamp of 23:30 GMT, resetting the calculated inventory count to 90 rather than 95.\n\nIf all three changes succeed, the new calculated inventory count for `IN_STOCK` units is 90. However, if any of the individual changes fail, the entire update fails and the calculated inventory count remains unchanged at zero.\n\nInventory quantities are also affected by Square payment APIs and Point of Sale applications. In the previous example, when the Square Point of Sale application records a transaction, it moves 3 units from the `IN_STOCK` state to the `SOLD` state. Assuming that the transaction timestamp places it after the batch update succeeds, the new calculated inventory count for `IN_STOCK` units is 87.","programming-language":"All","platform":"All"},"relationships":{"constant-sets":{"data":[]}}},{"id":"5yAxTf41fqsntz40btQ2tQ","type":"markdown-block","attributes":{"name":"Inventory API : How It Works : Supplemental Topic - Special states","markdown":"## Special InventoryState values\n\n### NONE\n\nThe `NONE` state is not a true inventory state. `NONE` is a `from_state` placeholder to represent the fact that a given `CatalogItemVariation` was introduced as new inventory. Inventory quantities can be transitioned from the `NONE` state, but cannot be transitioned to the `NONE` state.\n\n### IN_STOCK\n\nThe `IN_STOCK` state does not represent a pool of available items decremented over time. Item variation quantities move into and out of the `IN_STOCK` state as they do with other states. In general, when quantities move between states, the total quantity for that item variation across all states does not change. For example, consider the item variation \"Small Leather Collar\" with a total of 100 units. Initially all 100 units are in the `IN_STOCK` state. If 3 units become damaged, there are still 100 units at the end of the day: 97 units in the `IN_STOCK` state and 3 in the `WASTE` state. The `IN_STOCK` state is only special in that the Square Point of Sale application and Seller Dashboard use the quantity of item variations with the `IN_STOCK` state to determine the number of units currently available for sale.\n\n\n### SOLD\n\n`SOLD` is a terminal state. When inventory items move to the `SOLD` state, the units are no longer explicitly tracked. Transferring quantities from `SOLD` to some other state introduces a new quantity into inventory rather than changing the quantity in the `SOLD` state. For example, consider the case where \"Small Leather Collar\" has 100 units in the `IN_STOCK` state. If 5 units are sold online and 3 units are sold in the store, there are 92 units tracked. If a customer returns 2 units to the store, there are 94 units tracked: 92 units with the `IN_STOCK` state and 2 units with the `RETURNED_BY_CUSTOMER` state.\n","programming-language":"All","platform":"All"},"relationships":{"constant-sets":{"data":[]}}},{"id":"hbithQUnZW4g65wB8N2m5","type":"markdown-block","attributes":{"name":"Inventory API : How It Works : Supplemental Topic - Supported states","markdown":"## Supported state transitions\n\nInventory state transitions represent real world changes to inventory quantities. As a result, some state changes are permitted (such as, `IN_STOCK` to `SOLD`) while others are not (such as, `WASTE` to `RETURNED_BY_CUSTOMER`). Square supports the following inventory state transitions:\n\n![state-transitions](//images.ctfassets.net/1nw4q0oohfju/4nkzthvVyiMXXynap8pKfA/f95f320a7d6f42bb17c9821e7beff3b0/state-transitions.png)\n\nFrom state | To state | Related event |\n----------------- | ---------- | ------------- |\n`NONE` | `IN_STOCK` | A quantity of items was received and is available for sale. | \n`IN_STOCK` | `SOLD` | A quantity of items was sold. | \n`IN_STOCK` | `WASTE` | A quantity of items was damaged or lost and cannot be sold. | \n`UNLINKED_RETURN` | `IN_STOCK` | A quantity of items was returned by the customer and is available for sale. The return is not affiliated with a specific transaction. | \n`UNLINKED_RETURN` | `WASTE` | A quantity of items was returned by the customer and deemed to be unsellable. The return is not affiliated with a specific transaction. | \n\nIn addition to the support state transitions, the Inventory API might return additional read-only states as part of the change history for a given item variation. Transitions to or from read-only states can only be triggered from within Square products.\n\n## Automatic IN_STOCK adjustments\nIf inventory tracking is enabled in the Square Seller Dashboard, completing an itemized transaction with Square products automatically moves the quantity sold from the `IN_STOCK` state to the `SOLD` state.\n\nFor example, consider a [Payment API request that references an Order object](/payments-api/take-payments#orders-integration) containing three catalog line\nitems: a small leather dog collar, a 5-foot retractable leash, and Chewy chicken trainer treats.\n\n![automatic-updates](//images.ctfassets.net/1nw4q0oohfju/yAViAQfdjzeqDzbzLTEYG/e0edce0b14e715b5205b1f048dc2f463/automatic-updates.png)\n\nWhen the `Charge` endpoint processes the transaction, Square automatically adjusts the `IN_STOCK` quantities by moving 1 unit of the small leather dog collar from `IN_STOCK` to `SOLD`, 1 unit of the 5-foot retractable leash from `IN_STOCK` to `SOLD`, and 2 units of Chewy chicken trainer treats from `IN_STOCK` to `SOLD`.","programming-language":"All","platform":"All"},"relationships":{"constant-sets":{"data":[{"id":"DEVELOPERS_URLS","type":"constant-set"},{"id":"MD_BLOCKS","type":"constant-set"}]}}},{"id":"36oxndp8t1hhLjopp9CWHn","type":"markdown-block","attributes":{"name":"Inventory API : How It Works : Supplemental Topic - ignore_unchanged_counts flag","markdown":"## ignore_unchanged_counts flag\n\nRequests to the `BatchChangeInventory` endpoint include an `ignore_unchanged_counts` flag. The `ignore_unchanged_counts` flag tells Square to skip updates for the `CatalogItemVariation` if nothing has changed. When the new physical count for a `CatalogItemVariation` is the same as the previous physical count and no `InventoryAdjustment` requests have been received between the two physical counts, the physical count update is skipped. The `ignore_unchanged_counts` flag lets third-party systems push potentially redundant inventory counts to Square without polluting the Seller Dashboard with unnecessary adjustments.\n\nThe `ignore_unchanged_counts` flag is enabled by default so developers do not inadvertently spam Square servers with redundant `InventoryPhysicalCount` requests. Do not disable the `ignore_unchanged_counts` flag unless the associated `InventoryPhysicalCount` request represents a true reconciliation, such as an actual physical count by a person.","programming-language":"All","platform":"All"},"relationships":{"constant-sets":{"data":[]}}},{"id":"4RQ3CwBuLoRMSPpNSgMX00","type":"doc-page","attributes":{"slug":"inventory-api/how-it-works","heading":{"id":"VoHpiM3v32kvpnTt66E2k","title":"How It Works","eyebrow":"Inventory API","summary":" ","browser_title":"Inventory API: How It Works","release_status":"PUBLIC"},"environments":null,"related-pages":null,"search-summary":"Learn more about how the Inventory API processes information.","languages-supported":["All"],"platforms":["All"]},"relationships":{"content":{"data":[{"id":"7v93KkCkyE6YGaMHE2HSD","type":"markdown-block"},{"id":"5m2hxuFGTw8KUEoUlCBCuS","type":"markdown-block"},{"id":"77uu1BWePCBePZlbg42UzY","type":"markdown-block"},{"id":"4hffvk0l4x5wbcfrkdn0jM","type":"markdown-block"},{"id":"5yAxTf41fqsntz40btQ2tQ","type":"markdown-block"},{"id":"hbithQUnZW4g65wB8N2m5","type":"markdown-block"},{"id":"36oxndp8t1hhLjopp9CWHn","type":"markdown-block"}]},"constant-sets":{"data":[{"id":"DEVELOPERS_URLS","type":"constant-set"}]}}}]}

How It Works

On this page