---
id: post/thinkaboutit-be/7683
type: post
title: "API Pages vs API Queries in Business Central: When to Use Each"
summary: API pages and API queries are two distinct REST API object types in Business Central with different purposes. API pages support full CRUD operations and are best for write operations, while API queries are optimized for read-only access with multi-table joins and server-side aggregation. Understanding when to use each type is critical for performance and integration design.
tier: community
language: en
tags:
  - api pages
  - api queries
  - rest api
  - odata
  - integration design
  - performance
  - power bi
  - power automate
system: integration
review:
  state: reviewed
  by: opus
  at: "2026-10-08T01:56:06.715Z"
  flags: []
generated:
  at: "2026-10-08T01:26:53.141Z"
  pipeline: 0.2.0
  prompts:
    extract-post: 1
  input_hash: 939a93137791787587b1fe53103e3a19d044cf3b9c736725623f9ef3a9f72baa
evidence:
  - kind: blog
    url: https://thinkaboutit.be/2026/03/api-pages-vs-api-queries-in-business-central-when-to-use-each/
    title: "API Pages vs API Queries in Business Central: When to Use Each"
    date: "2026-03-17"
    commit: null
    t: null
    quote: null
  - kind: blog
    url: https://thinkaboutit.be/2026/03/api-pages-vs-api-queries-in-business-central-when-to-use-each/
    title: "API Pages vs API Queries in Business Central: When to Use Each"
    date: "2026-03-17"
    commit: null
    t: null
    quote: For any read-only scenario, the default choice is an API query. Not one option among two, but the default.
  - kind: blog
    url: https://thinkaboutit.be/2026/03/api-pages-vs-api-queries-in-business-central-when-to-use-each/
    title: "API Pages vs API Queries in Business Central: When to Use Each"
    date: "2026-03-17"
    commit: null
    t: null
    quote: If you design integrations with a clear separation between write and read paths, most performance and complexity problems disappear before they start.
links:
  learn: []
  objects: []
  features: []
  topics: []
  localizations: []
  videos: []
  posts: []
  guidelines: []
post_id: "7683"
source_id: thinkaboutit-be
source_name: think about IT - Steven Renders
url: https://thinkaboutit.be/2026/03/api-pages-vs-api-queries-in-business-central-when-to-use-each/
published_at: "2026-03-17T09:01:38.000Z"
author: Steven Renders
full_text: false
words: 2248
quotes:
  - text: For any read-only scenario, the default choice is an API query. Not one option among two, but the default.
    why_it_matters: Establishes the primary design principle for choosing the correct integration pattern for read-only access
  - text: If you design integrations with a clear separation between write and read paths, most performance and complexity problems disappear before they start.
    why_it_matters: Emphasizes that proper architectural separation is the key to avoiding performance issues in integration design
code_objects_mentioned: []
systems:
  - integration
  - reporting
  - platform
versions_mentioned:
  - "24"
  - "30"
preview:
  embeddable: true
  frame_url: https://thinkaboutit.be/2026/03/api-pages-vs-api-queries-in-business-central-when-to-use-each/embed/
  image: https://i0.wp.com/thinkaboutit.be/wp-content/uploads/2026/03/APIs1.png?fit=1200%2C800&ssl=1
  image_alt: null
  image_w: 1200
  image_h: 800
  site_name: think about IT
  favicon: https://i0.wp.com/thinkaboutit.be/wp-content/uploads/2026/02/cropped-SiteIcon2-1.png?fit=32%2C32&ssl=1
  probed_at: "2026-10-07T11:50:48.693Z"
---

# API Pages vs API Queries in Business Central: When to Use Each

[Read the post](https://thinkaboutit.be/2026/03/api-pages-vs-api-queries-in-business-central-when-to-use-each/) · think about IT - Steven Renders (Steven Renders) · 2026-03-17 · 2248 words · tier community · reviewed (checked by Opus)

> API pages and API queries are two distinct REST API object types in Business Central with different purposes. API pages support full CRUD operations and are best for write operations, while API queries are optimized for read-only access with multi-table joins and server-side aggregation. Understanding when to use each type is critical for performance and integration design.

## Key points

- API pages support full CRUD on a single source table, deep insert and webhooks, with related data via subpages and $expand
- API queries are read-only, join multiple tables in one SQL statement, and aggregate via the Method property with an implicit GROUP BY and SIFT support
- Property choices such as SystemId as OData key, alphanumeric enum names under schema version 2.0, DelayedInsert and avoiding ODataEDMType affect consumers like Power Automate
- Default to API queries for read-only scenarios; use API pages for writes, webhooks or deep insert, ideally combining both with separate write and read paths
- For Power BI, build one focused API query per data domain with DataAccessIntent ReadOnly and LastModifiedOn filtering, then relate them in the semantic model

## Quotes

- "For any read-only scenario, the default choice is an API query. Not one option among two, but the default." (Establishes the primary design principle for choosing the correct integration pattern for read-only access)
- "If you design integrations with a clear separation between write and read paths, most performance and complexity problems disappear before they start." (Emphasizes that proper architectural separation is the key to avoiding performance issues in integration design)

## Context

- Features: CRUD operations, multi-table joins, server-side aggregation, SIFT indexes, DataAccessIntent, schema version 2.0, LastModifiedOn filtering, query folding
- Versions: 24, 30

Source: think about IT - Steven Renders, community blog. Summary, key points and quotes are derived (CONTENT-NOTICE.md); read the original for the full text.