Floor plan API: upload, reconstruct and export a model

Use the INK TO BRICK API when a product or internal workflow needs to upload floor plans, monitor reconstruction and download a pinned model revision. Team includes API access; Pro includes MCP, not API access. MCP is a conversational layer for existing projects; it does not replace the upload and export endpoints.

Request application access first

For API application access, email hello@inktobrick.com with the use case, expected floor plan volume and the application that will make requests. Onboarding assigns the documented OAuth application identity and organization access. Do not put a personal browser token into a server or invent an API-key flow.

The floor plan pipeline

1. Use the onboarded OAuth application identity and intended organization. Create the project context required by your integration.
2. Create a floor plan upload with POST /v1/floorplan-uploads, upload the bytes to the returned destination, and complete the upload. Preserve the content hash, byte size, consent record and source-frame metadata used in the request.
3. Start the supported reconstruction flow, then poll its job until it reaches a terminal state. Do not treat an accepted job as a finished model.
4. Read the resulting project and revision, compare the geometry with the source, and resolve scale before using dimensions.
5. Create a hash-pinned export with POST /v1/projects/{projectId}/revisions/{revisionId}/exports. Poll the export job, then request its short-lived delivery grant.

Choose the handoff for the destination

For conversational review after a project exists, connect Codex through MCP. For the Blender side of the handoff, use the floorplan-to-Blender guide.

Use the authenticated tool catalog as the source of available operations and permissions. Pro and Team include MCP, and Team includes API access. Model reads, proposed changes and export delivery are distinct operations; obtain the actual delivery before saying an export is ready. Confirm the project and revision before any change.

Try it and check your result

Before onboarding, specify the input, expected physical-floor count and one required output format. After access is arranged, run the documented flow in the agreed test environment: retry the same request with the same idempotency key, verify the same job rather than a duplicate, and distinguish accepted, completed and delivered states. Compare the downloaded revision and two dimensions with the source. This page is a workflow overview; use the application-specific schema and authentication instructions supplied at onboarding.