GetFacade

Add one line to a generated estimate. `unit` must be a display code of the estimate's own measurement system — read an existing line to see which codes it uses rather than guessing. Totals are recomputed by the server.

Buy one token package for this key's wallet. Only works if the key was issued with purchasing enabled, and only up to what the key may still spend — a purchase cannot lift the key's own spend cap. The answer says `charged` when the payment provider took it from the saved payment method, or `requires_human` with a `checkout_url` a person has to open. Either way the tokens arrive asynchronously: poll get_balance.

Create a building (a house to design). The name must be unique within the account, max 50 characters — reusing a name is refused, so pick a distinct one instead of retrying the same. `goals` is the free-form brief (max 10000 chars).

Delete a building with everything under it: photos, designs, renders, estimates and albums. Deletion is soft on the server side and can be undone by a person in the app; this tool cannot undo it. Tokens already spent are not refunded.

Delete one design (concept) of a building, with the renders under it. Deletion is soft on the server side and can be undone by a person in the app; this tool cannot undo it.

Remove one line from a generated estimate. Totals are recomputed by the server.

Delete one render. Deleting the main render of a design returns that design to draft, so it can be rendered again without creating a new one. Deletion is soft on the server side and can be undone by a person in the app; this tool cannot undo it.

What this key can still spend: the api-scope balance of the account and the cap of this key. `is_admissible` is the server's own answer to "will the next paid call be accepted" — read it instead of comparing the numbers yourself.

The finished estimate: its totals, the area and duration it assumes, and every line with its quantity, unit and price. This is the only way to see what was estimated — get_job reports the status of an estimate, never its content. The `unit` of a line is the display code to reuse in add_estimate_line.

Poll one queued job. `kind` says what it is: a render, an estimate, or an album (albums are listed per design, so an album lookup needs `design_id`). The finished status differs by kind: a render and an album read `completed`, an estimate reads `ready`. Stop polling on any of those and on `failed`, where `error` says what went wrong and `error_code` names it; repeat that reason as it stands instead of composing one. A render and an album report `expected_seconds`, how long that job usually takes end to end, so the wait between polls can be paced by it; an estimate does not, and reads null. The `result_url` of a finished job is a permanent public link: no signature, no expiry, so it can be handed to a person as it stands. It also keeps working for anyone it is forwarded to and cannot be recalled, so pass it on as deliberately as any other shared link.

All designs of a building with their renders. This is where the render ids for order_estimate, order_album and refine_design come from — `main_render_id` is the finished render of a design, null while nothing has finished, and `main_render_url` is its permanent public link (no signature, no expiry, safe to hand to a person, and not recallable once shared). Per-render state is not here: poll get_job for that.

Recent jobs across the account — renders, estimates and albums in one list, unfinished ones first. Use it to catch up after a restart: each row carries the `kind` and `design_id` that get_job asks for, and the `building_id` the job belongs to. Use get_job to poll a single known job.

The views of a building: every photo accepted as a view of the house, whether it was uploaded here or added by the person in the app at `photos_page`. `view_id` is what start_design takes; `is_main` marks the main view. Use it after asking the person to add a photo in the app, to pick up what they added.

The packages this account can buy, with their price and how many tokens each carries. Read this before buy_tokens instead of assuming a ladder — the packages and their prices change.

Document the design as a PDF album (the blueprint document) for the renders you name: the materials, the build-up of the facade, safety notes and the regulatory references behind them. This is the document a crew builds from. Name the `estimate_id` of the estimate whose prices belong in it: without one the album takes the newest finished estimate of the design, which is not necessarily the one that was just ordered. Requires a completed main render on that design, otherwise the API refuses with an explanation. `requirements` is not honoured on every account: when it is not, the album is still made and `notices` says so, in the API's own words. The finished album is a permanent public link, so it can be handed to a person as it stands, and it stays readable for anyone it is forwarded to.

Price the design, line by line, in materials and labour, for the renders you name. The figures come from the design itself: what the specified materials and build-up cost in this country. Currency and measurement system default to the building's country and the written text to the account language; do not guess any of them, omit them unless the caller asked for a specific one. The money follows the house, the words follow the reader: a building in one country can be priced in its own currency and still be written up in the language the person asking reads.

Revise a finished design in words: "put a canopy over the front door", "make the roof darker". The revision is applied to the finished design, so what is not mentioned stays as it is — this is the tool for every step after the first, not start_design. Give it either the `render_id` of the picture to change (the job id start_design returned) or the `design_id` (with `building_id`) of the design whose finished main render should be changed. The parent render must be finished; refining an unfinished one is refused. Queues a render and returns a new job id, plus the `design_id` the result lands in (the server keeps every step as its own design, so the previous picture is never overwritten). Styles, colors and brands are optional here: pass them only to change them.

Report something wrong with this API itself: a field that is documented but never arrives, a refusal whose wording leaves no way forward, a call that only works on the second try, a result that does not match what was asked for. Free, and it works on an empty wallet, so a refusal can be reported the moment it happens. This is not the way to reach a person about an account or a charge, and no reply comes back through it; what comes back is a reference to quote. Say what was attempted, what was expected and what happened instead, and put the tool name and the ids in `context` so the report can be traced.

Design the exterior of this house on a chosen view, and show the result as a picture. The design is worked out against the building's country: which materials are applicable there, which manufacturer products are really sold there, and what the build-up behind the surface is — the render shows that decision on the house itself. Creates a new design (concept) and queues the work; returns a job id to poll with get_job. `prompt` is the free-form wish for this design ("a modern facade with a wide porch"). Colors accept the same strings the apps use: "palette:1", "paint:412", "siding:88@double-4-dutchlap" or "#RRGGBB" — order carries the 60/30/10 role, the first entry is the dominant wall color; `brand_selections` names real manufacturer products: "siding:brand:12", "siding:line:40@double-4-dutchlap", "paint:product:412". Omit `seed` unless reproducing an earlier render. To change a design that already rendered, use refine_design instead of starting another one.

Change one line of a generated estimate — its name, quantity, unit, unit price, category or section. Only the fields passed are changed. Totals are recomputed by the server.

Upload an exterior photo of the building and wait for the answer. Three legs: register the file, PUT the bytes to storage, confirm. What the photo turns out to be is decided on the server, and `kept_as` says which: "view" (a photo of the house to design from — `view_id` names it), "document" (a drawing kept with the building), "reference" or "render_style" (kept alongside it), or nothing kept at all. A file kept as anything but a view is not a refusal, and `can_use_as_view` says when it can still be claimed as one with use_photo_as_view. `can_retry` means the read failed on the service side: nothing was created, nothing was charged, send the same photo again. The wait is bounded: a `pending` answer means it is still being read, and calling this again with the same file resumes it rather than uploading a second copy.

Enlarge a completed render to a higher resolution. Costs tokens like a render and runs asynchronously: poll the returned job with get_job. A render that is already upscaled, or not finished yet, is refused by the API with an explanation.

Claim a photo the service kept elsewhere — as a drawing, a reference, or a building it read as a different one — as a view of this building to design from. Returns the `view_id` it becomes; the reference it had been is removed. Offered only when upload_photo answered `can_use_as_view: true`; otherwise the call is refused.