Automating Android App Builds with the WAC API and AI Agents

Until recently, turning a website into an Android app required a person sitting at a computer making deliberate choices. Fill in fields, upload assets, click build, wait, download, repeat. For one app, that is a few minutes. For fifty apps, it is a workday. For a workflow that needs to fire automatically when a CMS publishes new content, it is not possible with a web interface at all.

The WebToAppConvert REST API makes the build process programmable. Scripts, CI pipelines, and AI agents can drive it exactly the way the dashboard does. And the MCP server takes that one step further: the AI does not need to be scripted. It receives natural language instructions and handles the process itself.

The Agency Case: Fifty Apps From One Script

The clearest argument for the API is an agency building the same app configuration across multiple clients or locations. A regional franchise chain might have twenty locations, each with its own URL, app name, and package name, but identical branding and WebView configuration. Through the dashboard, that is twenty separate builds with twenty sets of identical clicks. Through the API, it is one script run.

The pattern that works cleanest is template-based duplication. Configure one app completely in the dashboard: icon, splash screen, colors, signing key, WebView behavior, navigation rules, everything. Then for each new location:

1. Call POST /apps/:templateId/duplicate. The new app inherits all configuration from the template, including binary assets.
2. Call PATCH /apps/:newSiteId with only the fields that differ: URL, display name, package name.
3. Call POST /builds to trigger the build.
4. Poll GET /builds/:buildId until status is terminal.
5. Retrieve the download URL from GET /builds/:buildId/download.

The duplication endpoint copies icons, splash screens, signing key references, and all WebView configuration. Your script never handles binary uploads. Credits deduct per build at the same rate as dashboard builds. The time saving for an agency doing volume work is significant: what took an afternoon of identical clicks takes the time the builds need to run.

AI Agents Building Apps on Request

The MCP server is the more interesting development. It lets an AI agent interact with the build pipeline using natural language, which changes the picture for non-technical users entirely.

Once configured, the workflow looks like this in practice:

User: "The new client site is live. Use the coffee shop template,
update the URL to their domain, and get me a signed APK."

Claude (via MCP tools):
1. duplicate_app(templateSiteId)
2. update_app(siteId, url, name)
3. create_build(siteId, tier="starter")
4. wait_for_build(buildId)
5. get_download_url(buildId)

Claude: "Done. Signed APK is ready at [link]. 50 credits used,
340 remaining."

The agent handles polling, error checking, and credit reporting. A user who has never opened the dashboard can trigger a complete build through a single conversational instruction. The agent does not need special handling or workarounds; the API surface was designed to be machine-friendly, with stable error codes, a duplication endpoint that eliminates binary upload handling, and build status responses that include estimated wait times.

To add the MCP server to Claude Code, add this to your ~/.claude/mcp.json:

{
  "mcpServers": {
    "webtoappconvert": {
      "type": "http",
      "url": "https://api.webtoappconvert.com/mcp",
      "headers": {
        "x-api-key": "YOUR_WAC_API_KEY"
      }
    }
  }
}

For VS Code Copilot, the equivalent goes in .vscode/mcp.json in your workspace. The same server URL works for Cursor, Cline, and Windsurf.

CI/CD: Builds Inside Your Pipeline

If your team deploys a website through a release pipeline, Android builds can live inside that pipeline rather than as a separate manual step. A GitHub Actions workflow triggered on a version tag or content deploy can call the API directly:

on:
  push:
    tags: ['v*']

jobs:
  android-build:
    runs-on: ubuntu-latest
    steps:
      - name: Trigger WAC build
        run: |
          RESULT=$(curl -s -X POST "$WAC_BASE_URL/builds" \
            -H "X-API-Key: $WAC_API_KEY" \
            -H "Content-Type: application/json" \
            -d '{"siteId":"$SITE_ID","buildTier":"professional"}')
          echo "Build ID: $(echo $RESULT | jq -r .buildId)"

Debug builds at 10 credits are cheap enough to run on every pull request for visual regression checks. Production builds stay gated to version tags. The credit system naturally limits production build frequency without any additional configuration logic.

Rate Limits and Polling Behavior

The API enforces 20 requests per minute and 20 builds per UTC day per API key. For most automation, these limits are not a practical constraint. A single build workflow makes around 20 to 30 total requests, mostly status polling.

Every build status response includes estimatedWaitSeconds for non-terminal builds. Use it. If the estimate says 180 seconds, polling every two seconds burns requests without making the build finish faster. The estimate is calculated from recent build performance on your account and improves as usage history accumulates. If automation is hitting 429 responses, the problem is almost always polling cadence rather than genuine request volume.

Getting Access

API access requires a paid account. Any credit purchase upgrades the account to paid tier and enables API access immediately. Generate a key from the API Access section of your profile page. Free accounts do not have API access.

The full reference with endpoint documentation, error codes, and examples in curl, Python, and JavaScript is at the Developer API documentation. An OpenAPI specification is published at /openapi.json for tools that consume contracts directly.

Get API access and start automating →