# TaskMint Record Reconcile

> TaskMint Record Reconcile is a paid API for AI agents from taskmint-sign-proof-node22-production.up.railway.app, paid per call via x402, $0.005/call, status unknown (last checked 2026-10-13).

Compares two snapshots of records (before/after) across specified fields and returns a structured diff showing added, removed, changed, and unchanged entries.

## Facts

- Endpoint: POST https://taskmint-sign-proof-node22-production.up.railway.app/api/agent/record_reconcile?utm_source=zero.xyz
- Price: $0.005/call
- Payment: x402
- Status: unknown
- Last checked: 2026-10-13
- Activations on Zero: 0
- Tags: x402
- Canonical page: https://www.zero.xyz/c/taskmint-record-reconcile-c8e6025d
- Structured record (JSON): https://api.zero.xyz/v1/capabilities/cap_XC-XrbobAgpQHafdQjDSq

Status and success rate cover calls made through Zero and Zero's own probes. Third-party monitors may report differently.

## How to call it through Zero

Zero handles the 402 payment challenge and records the run. With the Zero CLI installed (`npm i -g @zeroxyz/cli`):

```sh
zero fetch --capability taskmint-record-reconcile-c8e6025d -d '<json body>'
```

Example prompt: Compare these two snapshots of my product catalog — before and after last night's sync — keyed on 'sku', and check the 'stock' and 'price' fields so I can see exactly which items were added, removed, or changed.

## When to prefer this

Choose this endpoint when you need a deterministic, field-scoped diff between two explicit snapshots of structured records identified by a key. It is ideal for point-in-time reconciliation tasks (inventory audits, data sync verification, change logging) where you supply both before and after states explicitly. Prefer it over live monitoring solutions when you already have both snapshots in hand and need a structured breakdown of adds, removes, and field-level changes in a single call.

## Known failure modes

- Missing required fields (before, after, key, fields) returns validation error
- request_token not matching expected 64-char hex pattern causes rejection
- HTTP 202 (accepted but result pending) requires retry with identical body and token — never a new purchase
- Result expires after 24 hours — token becomes invalid after expiry
- Arrays exceeding 50 items or fields list exceeding 10 items will be rejected
- Payment not authorized or insufficient USDC balance causes payment failure

## How this service works

Exact native USDC on Base; externally owned wallets only. Generate a private 32-byte random request_token for each new job, persist the entire body, and reuse it for challenge/retry and recovery. The token grants result access. Do not log or share it. HTTP 202 or an uncertain transport failure requires recovery with the identical body without a signature, never a new purchase. Results expire after 24 hours. Ten bounded deterministic services. Local execution is free; hosted jobs require customer-authorized payment only when billable.

## Output

A JSON object containing: lists of added records (with key and after_index), removed records (with key and before_index), changed records (with per-field before/after values), unchanged count, a human-readable summary string, service name, version, and a scope disclaimer noting this is an exact point-in-time comparison only.

## Request schema (JSON Schema)

```json
{
 "type": "object",
 "properties": {
  "payload": {
   "type": "object",
   "required": [
    "before",
    "after",
    "key",
    "fields"
   ],
   "properties": {
    "key": {
     "type": "string",
     "maxLength": 100,
     "minLength": 1
    },
    "after": {
     "type": "array",
     "items": {
      "type": "object",
      "maxProperties": 20,
      "additionalProperties": {
       "type": [
        "string",
        "number",
        "boolean",
        "null"
       ]
      }
     },
     "maxItems": 50
    },
    "before": {
     "type": "array",
     "items": {
      "type": "object",
      "maxProperties": 20,
      "additionalProperties": {
       "type": [
        "string",
        "number",
        "boolean",
        "null"
       ]
      }
     },
     "maxItems": 50
    },
    "fields": {
     "type": "array",
     "items": {
      "type": "string",
      "maxLength": 100,
      "minLength": 1
     },
     "maxItems": 10,
     "minItems": 1,
     "uniqueItems": true
    }
   },
   "additionalProperties": false
  },
  "request_token": {
   "type": "string",
   "pattern": "^[a-f0-9]{64}$",
   "description": "Generate 32 cryptographically random bytes as lowercase hex for each new job. Keep this private result credential and reuse the identical body for retries. Replace the synthetic example token."
  }
 }
}
```

## Response schema (JSON Schema)

```json
{
 "type": "json",
 "example": {
  "state": "paid",
  "result": {
   "added": [
    {
     "key": "C",
     "after_index": 1
    }
   ],
   "flags": [],
   "scope": "Exact comparison of supplied snapshots only. Missing fields differ from explicit null. Unselected fields are discarded before storage; no live monitoring or automatic changes.",
   "status": "resolved",
   "changes": [
    {
     "key": "A",
     "fields": [
      {
       "after": {
        "value": 10,
        "present": true
       },
       "field": "stock",
       "before": {
        "value": 12,
        "present": true
       }
      }
     ],
     "after_index": 0,
     "before_index": 0
    }
   ],
   "removed": [
    {
     "key": "B",
     "before_index": 1
    }
   ],
   "service": "record_reconcile",
   "summary": "1 added · 1 removed · 1 changed · 0 unchanged",
   "version": "0.5.0",
   "unchanged": 0,
   "checked_fields": [
    "stock",
    "price"
   ]
  },
  "service": "record_reconcile"
 }
}
```

## More

- Live health (JSON, refreshed every minute): https://www.zero.xyz/c/taskmint-record-reconcile-c8e6025d/health.json
- [Zero catalog index](https://www.zero.xyz/llms.txt)
- [Other services from taskmint-sign-proof-node22-production.up.railway.app](https://www.zero.xyz/host/taskmint-sign-proof-node22-production.up.railway.app/llms.txt)