Pawsitive Future Pawsitive FutureDeveloper docs

post_ownership_transfers_by_orgid_by_transferid_verify

Changes data · you confirm first

Calls POST /api/ownership-transfers/{orgId}/{transferId}/verify as the signed-in person · REST reference

Confirm the caller's own side of an ownership transfer with their code

With the caller's own token; the side is whoever the caller is — the owner or the member the transfer names — and nobody else may confirm (403). The code is the one emailed to the caller and verifies for their side of this transfer only. The second confirmation completes the transfer: the old owner becomes a read-only member, the member becomes the owner, both are emailed, and both see their new permissions on their next request. Wrong, expired, exhausted and missing are distinct 400s (INVALID_CODE, CODE_EXPIRED, TOO_MANY_ATTEMPTS, NO_PENDING_TRANSFER); three wrong codes cancel the transfer. A transfer that can no longer happen when both have confirmed — the member left, the org was deleted — is cancelled: 409 TRANSFER_CANCELLED. Refused while impersonating.

Arguments

ArgumentTypeDescription
orgIdpathstring (uuid)required
transferIdpathstring (uuid)required
bodyJSONobjectrequiredThe request body, as a JSON object. Its fields are listed below.

Fields of body

FieldTypeDescription
codestringrequired6-digit code. Non-digits are stripped before the length check.

Example call

A client sends this over the MCP session; Claude and other agents build it for you. The values are placeholders — the shape is real.

json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "post_ownership_transfers_by_orgid_by_transferid_verify",
    "arguments": {
      "orgId": "11111111-1111-4111-8111-111111111111",
      "transferId": "11111111-1111-4111-8111-111111111111",
      "body": {
        "code": "string"
      }
    }
  }
}
Confirmation
The client shows the person the exact request and waits. Nothing runs until they tick Make this change. See Reading and changing.

Result

On success (HTTP 200) the tool returns one text item holding the API's JSON, pretty-printed.

This side is confirmed (VERIFIED), or the transfer completed (COMPLETED).

json
{
  "data": {
    "outcome": "VERIFIED",
    "transfer": {
      "createdAt": 1,
      "expiresAt": 1,
      "from": {},
      "id": "11111111-1111-4111-8111-111111111111",
      "orgId": "11111111-1111-4111-8111-111111111111",
      "orgName": "string",
      "status": "PENDING",
      "to": {},
      "cancelReason": "string",
      "cancelledAt": 1,
      "completedAt": 1
    }
  },
  "success": true
}

Fields

FieldTypeDescription
dataobject
data.outcome"VERIFIED" | "COMPLETED"
data.transferobject
data.transfer.cancelReasonstring | null
data.transfer.cancelledAtinteger | null
data.transfer.completedAtinteger | null
data.transfer.createdAtintegerEpoch milliseconds.
data.transfer.expiresAtintegerEpoch milliseconds — the deadline both sides must confirm by. The same lifetime as every other code (OTP_EXPIRY_SECONDS).
data.transfer.fromobject
data.transfer.idstring (uuid)
data.transfer.orgIdstring (uuid)
data.transfer.orgNamestring
data.transfer.status"PENDING" | "COMPLETED" | "CANCELLED" | "EXPIRED"
data.transfer.toobject
successtrue

When it fails

A failed call returns isError: true with the API's message as text. A change the person declines, or lets time out, also comes back this way and nothing changes.

400

The request was malformed or failed a guard.

403

Authenticated, but the caller holds none of the required permissions.

409

The resource is not in a state that allows this operation.

What the model is shown

This is the tool exactly as the server lists it in tools/list. The description starts with the REST call it makes.

json
{
  "name": "post_ownership_transfers_by_orgid_by_transferid_verify",
  "description": "POST /api/ownership-transfers/{orgId}/{transferId}/verify — With the caller's own token; the side is whoever the caller is — the owner or the member the transfer names — and nobody else may confirm (403). The code is the one emailed to the caller and verifies for their side of this transfer only. The second confirmation completes the transfer: the old owner becomes a read-only member, the member becomes the owner, both are emailed, and both see their new permissions on their next request. Wrong, expired, exhausted and missing are distinct 400s (INVALID_CODE, CODE_EXPIRED, TOO_MANY_ATTEMPTS, NO_PENDING_TRANSFER); three wrong codes cancel the transfer. A transfer that can no longer happen when both have confirmed — the member left, the org was deleted — is cancelled: 409 TRANSFER_CANCELLED. Refused while impersonating.\n\nThis changes data. The person is asked to confirm it before it runs, and nothing happens if they decline.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "orgId": {
        "type": "string"
      },
      "transferId": {
        "type": "string"
      },
      "body": {
        "type": "string",
        "description": "The JSON request body: { code*: string (6-digit code.) }"
      }
    },
    "required": [
      "orgId",
      "transferId",
      "body"
    ]
  },
  "annotations": {
    "readOnlyHint": false,
    "destructiveHint": true,
    "idempotentHint": false,
    "openWorldHint": false
  }
}