Plugin check: Run
node "${CLAUDE_PLUGIN_ROOT}/scripts/check-version.js"— if it outputs a message, show it to the user before proceeding.
Integrate Web API
Integrate Power Pages Web API into a code site's frontend. This skill orchestrates the full lifecycle: analyzing where integrations are needed, implementing API client code for each table, configuring permissions and site settings, and deploying the site.
Core Principles
- First table sequential, then parallel: The first table must be processed alone because it creates the shared
powerPagesApi.tsclient. Once that exists, remaining tables can be processed in parallel since each creates independent files (types, service, hooks). - Parallelize independent agents: The
table-permissions-architectandwebapi-settings-architectagents are independent — invoke them in parallel rather than sequentially. - Permissions require deployment: The
.powerpages-sitefolder must exist before table permissions and site settings can be configured. Integration code can be written without it, but permissions cannot. - Use TaskCreate/TaskUpdate: Track all progress throughout all phases — create the todo list upfront with all phases before starting any work.
Prerequisites:
- An existing Power Pages code site created via
/create-site- A Dataverse data model (tables/columns) already set up via
/setup-datamodelor created manually- The site must be deployed at least once (
.powerpages-sitefolder must exist) for permissions setup
Initial request: $ARGUMENTS
Workflow
- Verify Site Exists — Locate the Power Pages project and verify prerequisites
- Explore Integration Points — Analyze site code and data model to identify tables needing Web API integration
- Review Integration Plan — Present findings to the user and confirm which tables to integrate
- Implement Integrations — Use the
webapi-integrationagent for each table - Verify Integrations — Validate all expected files exist and the project builds successfully
- Setup Permissions & Settings — Choose permissions source (upload diagram or let the architects analyze), then configure table permissions and Web API site settings with case-sensitive validated column names
- Review & Deploy — Ask the user to deploy the site and invoke
/deploy-siteif confirmed
Phase 1: Verify Site Exists
Goal: Locate the Power Pages project root and confirm that prerequisites are met
Actions:
1.1 Locate Project
Look for powerpages.config.json in the current directory or immediate subdirectories to find the project root. Use your file-search tool (e.g., Glob with patterns powerpages.config.json and */powerpages.config.json) rather than a shell-specific command.
If not found: Tell the user to create a site first with /create-site.
1.2 Read Existing Config
Read powerpages.config.json to get the site name.
1.3 Detect Framework
Read package.json to determine the framework (React, Vue, Angular, or Astro). See ${CLAUDE_PLUGIN_ROOT}/references/framework-conventions.md for the full framework detection mapping.
1.4 Check for Data Model
Look for .datamodel-manifest.json to discover available tables:
**/.datamodel-manifest.json
If found, read it — this is the primary source for table discovery.
1.5 Check Deployment Status
Look for the .powerpages-site folder:
**/.powerpages-site
If not found: Warn the user that the permissions phase (Phase 5) will require deployment first. The integration code (Phases 2–4) can still proceed.
Output: Confirmed project root, framework, data model availability, and deployment status
Phase 2: Explore Integration Points
Goal: Analyze the site code and data model to identify all tables needing Web API integration
Actions:
Use the Explore agent (via Task tool with agent_type: "explore") to analyze the site code and data model. The Explore agent should answer these questions:
2.1 Discover Tables
Ask the Explore agent to identify all Dataverse tables that need Web API integration by examining:
.datamodel-manifest.json— List of tables and their columnssrc/**/*.{ts,tsx,js,jsx,vue,astro}— Source code files that reference table data, mock data, or placeholder API calls- Existing
/_api/fetch patterns in the code - TypeScript interfaces or types that map to Dataverse table schemas
- Component files that display or manipulate data from Dataverse tables
- Mock data files or hardcoded arrays that should be replaced with API calls
TODOorFIXMEcomments mentioning API integration
Prompt for the Explore agent:
"Analyze this Power Pages code site and identify all Dataverse tables that need Web API integration. Check
.datamodel-manifest.jsonfor the data model, then search the source code for: mock data arrays, hardcoded data, placeholder fetch calls to/_api/, TypeScript interfaces matching Dataverse column patterns (publisher prefix likecr*_), TODO/FIXME comments about API integration, and components that display table data. For each table found, report: the table logical name, the entity set name (plural), which source files reference it, what operations are needed (read/create/update/delete), and whether an existing API client or service already exists insrc/shared/orsrc/services/. Also check ifsrc/shared/powerPagesApi.tsalready exists."
2.2 Identify Existing Integration Code
The Explore agent should also report:
- Whether
src/shared/powerPagesApi.ts(or equivalent API client) already exists - Which tables already have service files in
src/shared/services/orsrc/services/ - Which tables already have type definitions in
src/types/ - Any framework-specific hooks/composables already created
This avoids duplicating work that was already done.
2.3 Compile Integration Manifest
From the Explore agent's findings, compile a list of tables needing integration:
| Table | Logical Name | Entity Set | Operations | Files Referencing | Existing Service |
|---|---|---|---|---|---|
| Products | cr4fc_product | cr4fc_products | CRUD | ProductList.tsx, ProductCard.tsx | None |
| Categories | cr4fc_category | cr4fc_categories | Read | CategoryFilter.tsx | None |
Output: Complete integration manifest listing all tables, their operations, referencing files, and existing service status
Phase 3: Review Integration Plan
Goal: Present the integration manifest to the user and confirm which tables to integrate
Actions:
3.1 Present Findings
Show the user:
- The tables that were identified for Web API integration
- For each table: which files reference it, what operations are needed
- Whether a shared API client already exists or needs to be created
- Any tables that were skipped (already have services)
3.2 Confirm Tables
Use AskUserQuestion to confirm:
| Question | Options |
|---|---|
| I found the following tables that need Web API integration: [list tables]. Which tables should I integrate? | All of them (Recommended), Let me select specific tables, I need to add more tables |
If the user selects specific tables or adds more, update the integration manifest accordingly.
Output: User-confirmed list of tables to integrate
Phase 4: Implement Integrations
Goal: Create Web API integration code for each confirmed table using the webapi-integration agent
Actions:
4.1 Invoke Agent Per Table
For each table, use the Task tool to invoke the webapi-integration agent at ${CLAUDE_PLUGIN_ROOT}/agents/webapi-integration.md:
Prompt template for the agent:
"Integrate Power Pages Web API for the [Table Display Name] table.
- Table logical name:
[logical_name]- Entity set name:
[entity_set_name]- Operations needed