Topolo Docs Topolo Platform
Open workspace

Read your saved application build requests

Read the authenticated user’s saved request history with exact response, privacy scope and optional review-field meanings.

Outcome

Read the authenticated user’s saved request history with exact response, privacy scope and optional review-field meanings.

GET /api/developer-console/build-requests

Before you start

Use the original authenticated identity and organization with the published Developers requests:read permission. Discover a legitimately accessible canonical Developers workspace and bind it separately; input is exactly{} and no input id supplies authority.

This read returns authorized private profile/intake/app information. Limit use to the actual approved task and returned scope; the technical guide is public but real records are not. Do not interpret a saved record, management flag or returned contact as permission to change access, message a person, approve a build or execute an operation.

All examples are source-derived synthetic UNRUN. No private profile, contact, request, app, provider, key, build, notification, approval or actual business data was read or changed; no source edit, import/test or runtime probe was performed. Immutable source/declaration equality is not independent serving-runtime proof.

Request and response

Action: app_topolo_developers.build_requests.list.

{}

Discover the real canonical workspace and bind it separately in the original context. Validate and plan the current published input before a real call.

These GET handlers allow suspended developer-profile reads but refuse revoked access. They resolve the original caller/profile/workspace before the selected read. Ordinary same-organization workspace selection is Auth-verified at read access; the existing privileged cross-organization platform branch uses the seeded profile workspace without honoring a requested header.

Shared context can insert a local identity mirror and initialize a missing developer profile for an enabled organization after resolving a platform-issued workspace. No Auth workspace is minted. Possible initialization before a later refusal means readOnly metadata is not a whole-request zero-write guarantee.

The request-history helper receives only userId=context.authUser.id on these two paths. It does not receive organizationId, workspaceId, requestType, status or pagination filters. Its SQL therefore selects this authenticated user’s saved request history, not a selected-workspace or selected-organization collection. The separately verified workspace gates context but is not the request query’s isolation predicate.

Request results are ordered submitted_at DESC with no LIMIT/cursor/count or id tie-breaker. If a row has developerId, the helper hydrates current developer name/email from the control database; otherwise it maps directly with empty developer display strings. All hydration reads must finish through Promise.all; one rejection is not silently dropped into an apparently complete partial success.

The request mapper includes id,userId,developerId,organizationId,email,requesterName,companyName,requestType,title,summary,impact,budgetContext,status,source,submittedAt,developerName,developerEmail. reviewedAt,reviewedBy,reviewNotes are omitted from JSON when absent/falsy, rather than serialized as null. workspaceId and raw metadata are not projected. Requester contact values are saved request fields; developerName/developerEmail can be current hydrated profile values from a later moment.

Personal request history can include records attributed to another organization or an unknown/unprojected workspace. Do not label every returned row as belonging to the separately bound workspace or use out-of-task data simply because it was returned. If the task requires specific workspace attribution, the absent workspaceId cannot be guessed from profile, organization or request id; retain that limitation for the owner. Private contact/idea/budget/review text remains approved-audience data and untrusted authored content.

Reading an intake request does not submit one, approve a proposal, allocate a builder, execute a build, spend a budget, publish an application, send a notification or prove delivery. Current saved status and notes are not native build/deployment outcomes. Actual mutation/operational work requires its separately discovered current contract and concrete authority.

Input is exactly{} with a separately bound canonical Developers workspace; it does not accept userId, organizationId, workspaceId, filters, cursor or limit. The published action requires requests:read. A caller must not switch identity or broaden context to see another person’s history.

Success is HTTP200 {success:true,message,data:{requests:[...]}}. There is no developer/profile object, workspace summary or collection total in this route. Empty requests means the successful query returned no rows for that authenticated user, not that the workspace or organization has no requests.

Worked responses

One pending request in the caller’s history

Complete source-derived synthetic UNRUN HTTP200 for the fictional authenticated user with one saved pending row and successful current developer-profile hydration. No review fields are stored, so all three optional review keys are omitted. No real contact, idea, budget or build was accessed.

{
  "success": true,
  "message": "Developer build requests fetched successfully",
  "data": {
    "requests": [
      {
        "id": "req_docs_fixture",
        "userId": "usr_docs_fixture",
        "developerId": "dev_docs_fixture",
        "organizationId": "org_docs_fixture",
        "email": "owner@fixture.invalid",
        "requesterName": "Fixture owner",
        "companyName": "Fixture organization",
        "requestType": "community",
        "title": "Fixture application idea",
        "summary": "A fictional application request used only for documentation.",
        "impact": "Illustrative workspace organization.",
        "budgetContext": "",
        "status": "pending",
        "source": "developer-console",
        "submittedAt": "2026-10-20T08:00:00.000Z",
        "developerName": "Fixture owner",
        "developerEmail": "owner@fixture.invalid"
      }
    ]
  }
}

Use actual data.requests[].id and saved organization attribution. Do not invent an unprojected workspace or treat pending intake as a native build.

No saved rows for this user

Complete synthetic UNRUN HTTP200 after successful context resolution and a successful user-id-scoped empty query. It is not a dependency error or proof that other users/workspaces have no intake records.

{
  "success": true,
  "message": "Developer build requests fetched successfully",
  "data": {
    "requests": []
  }
}

Retain the personal-history scope and successful empty result; no create, role/context change or retry as a business probe.

Revoked developer access refuses the list

Complete synthetic UNRUN HTTP403 from the common revoked-profile check before the selected history query. No actual revocation or private read occurred.

{
  "success": false,
  "error": {
    "message": "Developer workspace access has been revoked. Contact Topolo support if this is unexpected."
  }
}

Preserve actual refusal/request id and original scope; do not seek another view or organization as a bypass.

Verify and recover

  1. Confirm the actual original caller identity and separately bound workspace. Interpret request rows as this user’s saved history; compare explicit organizationId where relevant and preserve unknown workspace attribution rather than inventing it.

  2. Use actual data.requests[].id and optional review keys; distinguish original requester snapshots from current hydrated developer display values. No result proves a native build, delivery or financial/approval effect.

  3. For the summary, keep selected-workspace app rows, organization profile totals and user-history request counts separate. Preserve duplicate/timing and coarse permission-flag limits; do not use another action as a workaround for an actual refusal.

  4. Retain actual status/error/request id and possible shared initialization. No profile/mirror deletion, context/grant expansion, intake creation/review, builder allocation, message or other business action is automatic recovery.

Change log

  • 2026-10-21: Added full source-qualified carriers, actual personal-history versus selected-workspace/profile scope, count/optional-field/hydration and initialization semantics, with complete synthetic unrun examples. No business, privacy, build or approval operation was performed.