> ## Documentation Index > Fetch the complete documentation index at: https://docs.base44.com/llms.txt > Use this file to discover all available pages before exploring further. # The build turn > The loop your product wraps to create, watch, answer, and ship an app. A build turn is the loop your product wraps. A builder describes what they want, and the Base44 agent builds it, pausing occasionally to ask a question, until an app is ready. These are the calls that loop is made of. Call [Create app](/api-reference/create-app) to create the app and start building it from the specified prompt. Because the build starts inside this call, anything the build itself needs has to be in this request. That includes: | Field | Purpose | | :-------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `initial_message` | The prompt used to seed the first build. It starts the build and is not persisted on the app. | | `organization_id` | Creates the app in the specified workspace. Without it the app lands in the [acting account's personal workspace](/developers/white-label/tenancy-and-credentials#the-credential), missing your design system, skills, and plan. Send `X-Active-Workspace-Id` too, because capability checks read the active workspace rather than the body. | | `custom_instructions` | [Custom instructions](/developers/white-label/custom-instructions) applied by the agent on every turn and persisted on the app. | **Updating an app uses a different call.** Send each new prompt through [Send chat message](/api-reference/send-chat-message), with the app ID in the URL. App creation is capped at 5 requests per minute. Queue bursts rather than firing them in parallel. If a field name doesn't match what Create app accepts, whether from a typo or because it's unsupported, the platform drops it with no error, and the create still succeeds. Read the field back from the created app afterward to confirm it applied. Nothing is pushed to you. Poll [Get app](/api-reference/get-app) and read `status.state`, which is `processing` while the build runs, `ready` when it settles, and `error` when it failed. [Read conversation messages](/api-reference/read-conversation-messages) gives you the transcript to render alongside it. **Size your timeouts for an LLM turn, not for CRUD.** [Create app](/api-reference/create-app), [Send chat message](/api-reference/send-chat-message), [Submit tool-call input](/api-reference/submit-tool-call-input), and [Deploy an app](/api-reference/deploy-an-app) all wait on real work. A turn measures from around thirty seconds and can run to several minutes. A blanket 30-second client timeout aborts working builds and reports them as upstream failures. The reference integration allows 120 seconds for those four. The transcript carries every tool call's arguments and results, file contents included, so it grows all build long. Page it rather than re-reading the whole thing. A turn doesn't always run to completion. The agent can stop, ask the builder a question, and wait indefinitely. Nothing else you send moves until it is answered. You find the question in the transcript, as a tool call whose `status` is `waiting_for_user_input`. It carries `waiting_on.kind`, and there are exactly three kinds. Build one UI for each, and you can handle every question the agent might ask. | `waiting_on.kind` | What the agent wants | What to show | | :---------------- | :----------------------------------- | :------------------- | | `choice` | A pick between options it offered. | A picker. | | `input` | A value it needs, such as a key. | A form. | | `approval` | Permission to run a proposed action. | Approve and decline. | [Submit tool-call input](/api-reference/submit-tool-call-input) takes the tool call's id and a decision, and resumes the turn. When the question wants content rather than a yes or no, use `extra_user_input`. If you approve, the agent receives it as the tool's `user_input`. Send an `X-Request-ID` that stays the same across retries of the same submit. The reference integration derives it from the tool call's id. Without a stable ID, a network-retried POST could resume the turn a second time and charge for it twice. With one, the server recognizes the retry and dedupes it. A few UI details matter here: * **Declining is an answer.** A rejection records the call as stopped, the tool never runs, and the agent carries on. Your UI needs an explicit decline button, not just an approve one. * **Lock the message input while a question is open.** If it isn't locked the builder can attempt to send a message into a stopped turn and nothing happens. When several questions are waiting and one decision answers all of them, use [Submit tool-call input (batch)](/api-reference/submit-tool-call-input-batch). [Get preview URL](/api-reference/get-preview-url) returns a URL that serves the app as it currently stands, including unpublished changes, along with a separate `preview_token` needed to authenticate against it. Each app runs in its own sandbox, a live instance of its code that serves the preview. After a period of inactivity, the sandbox may require a cold start, so the first call can take noticeably longer. The response's `sandbox_info.cold_start` field tells you whether that happened. The `preview_token` is a credential with a short lifetime. Never cache it, and keep it out of logs. [Deploy an app](/api-reference/deploy-an-app) is synchronous and has no review gate of its own, so any approval step your product needs is yours to build in front of it. By default the app's current version goes live. To ship an earlier version, pick it from [List checkpoints](/api-reference/list-checkpoints). [Get published URL](/api-reference/get-published-url) returns the address of the deployed app. A `404` covers an app that was never published, one you unpublished, and one that does not exist, so read it as "nothing to link to yet" rather than as a diagnosis. ## See also * [Setup checklist](/developers/white-label/setup-checklist): Everything you need to do to get an integration running * [Common APIs](/developers/white-label/common-apis): The endpoint for every job in your product * [Custom instructions](/developers/white-label/custom-instructions): Give the agent app-specific instructions * [Tenancy and credentials](/developers/white-label/tenancy-and-credentials): The account that owns your builders' apps, and the key that creates them