Payroll

A1-2: required (still nullable) — every producer already emits null rather than omitting the field when there is no next page, so this only removes a third, unused wire state (absent) a strict client had to handle for nothing.

Present only with ?expand=summary (LIST-SUMMARY-1). Computed over every run matching the request's status_group (never cursor/limit). The three counts are the Payroll hub's own sections, NOT the status_group buckets: needs_action = draft, approved, reviewed, funding_pending, funded, partial, failed; in_progress = executing; completed = completed, cancelled. A status this version does not know counts in total only.

Prefixed, opaque. The prefix is part of the contract; the suffix is never parsed.

A1-2: open — an unrecognized member is an opaque string, never a deserialization failure.

The run's lifecycle. draft and approved are DB-legal but not reachable through a /v1 action of this caller's own: runs_create writes reviewed directly and runs_approve writes funding_pending directly, so neither state is ever produced by this API — only an internal ops webhook (or a seeded row) can leave one in draft or approved. Both are published in this enum regardless (G decision 2026-09-14): GET /v1/payroll_runs reads real rows, and a caller-unreachable status is still a status a real row can carry — omitting it 500'd the entire list the moment one such row existed, rather than 200ing every row but that one. funded: an inbound funding event was observed — it does not mean the run is fully funded; read funding_state, funding_confirmed_amount and needs_attention. Execution is refused for a funded run whose funding_state is not funded or overfunded.

ISO 4217 code the run pays in.

payroll_runs.pay_period_start is a NULLABLE DB column — the internal create path (optionalDate) writes null whenever the caller omits it, and most real rows do (prod: 59 of 74 rows, 21 of 25 employers, have a null pay period on at least one side). respondValidated's .strict() parse used to require a string here, so that dominant row shape 500'd the entire list the same way the missing draft/approved enum values did (BL-15) — the key stays present (never omitted), the value is null when the run has no pay period on record.

Nullable for the same reason as pay_period_start — see that field.

The funding classifier's verdict, independent of status. unfunded: nothing attributable arrived. partially_funded: money arrived and is short of funding_amount — payroll_runs.execute answers 409 payroll_run_underfunded naming the shortfall. funded: the confirmed amount matches. overfunded: more arrived than was asked for; the run may execute and the surplus is recorded.

Derived from funding_state: true when money was observed but the amount is short, is in surplus, or was never confirmed at all. Advisory — the refusal that actually protects the money is on execute.

How the employer funds the run: fiat by bank transfer to a Bridge virtual account, crypto by sending USDC to the employer's Bridge payroll wallet. crypto is offered per currency by GET /v1/capabilities?product=payroll (funding_currencies[].crypto_funding); while crypto funding is switched off it answers 409 capability_unavailable on create, approve and the funding call — it is never silently substituted with a fiat instruction.

Counts over this run's items, by destination readiness.

A money value. amount is a minor-unit integer as a string; decimals states the scale so a client never re-derives it (USDC is 6). Floats never appear on a money path.

A money value. amount is a minor-unit integer as a string; decimals states the scale so a client never re-derives it (USDC is 6). Floats never appear on a money path.

A money value. amount is a minor-unit integer as a string; decimals states the scale so a client never re-derives it (USDC is 6). Floats never appear on a money path.

The inbound amount the funding classifier attributed to this run and compared against funding_amount. Denominated in the currency the money actually arrived in: the run's own currency on the bank rail, USDC on the crypto rail, where the requirement itself was converted before it was compared. It is never restated into another currency. Null means no amount was ever confirmed — and a run with a null value here cannot execute.

The asset this run's funding pool holds — what the deposit becomes in the employer's Bridge payroll wallet and what every payout is paid out of. USDC for every run, or EURC for an EUR run whose recipients chose EURC wallets, where the EURC pool is enabled for the account. Chosen at approve from the wallet destinations (one pool per run: a run that mixes EURC and USDC wallets answers 409 run_mixed_pool) and never changed once money was observed (409 pool_asset_locked). Null while the run's funding records no pool: before approve (and on a run cancelled before it), or on an older approved run whose funding recorded no wallet. Read-only.

Present once a funding attempt has been requested; null before that.

A funding event was observed for this run — not proof the run is fully funded.

Prefixed, opaque. The prefix is part of the contract; the suffix is never parsed.

A1-2: open — an unrecognized member is an opaque string, never a deserialization failure.

The run's lifecycle. draft and approved are DB-legal but not reachable through a /v1 action of this caller's own: runs_create writes reviewed directly and runs_approve writes funding_pending directly, so neither state is ever produced by this API — only an internal ops webhook (or a seeded row) can leave one in draft or approved. Both are published in this enum regardless (G decision 2026-09-14): GET /v1/payroll_runs reads real rows, and a caller-unreachable status is still a status a real row can carry — omitting it 500'd the entire list the moment one such row existed, rather than 200ing every row but that one. funded: an inbound funding event was observed — it does not mean the run is fully funded; read funding_state, funding_confirmed_amount and needs_attention. Execution is refused for a funded run whose funding_state is not funded or overfunded.

ISO 4217 code the run pays in.

payroll_runs.pay_period_start is a NULLABLE DB column — the internal create path (optionalDate) writes null whenever the caller omits it, and most real rows do (prod: 59 of 74 rows, 21 of 25 employers, have a null pay period on at least one side). respondValidated's .strict() parse used to require a string here, so that dominant row shape 500'd the entire list the same way the missing draft/approved enum values did (BL-15) — the key stays present (never omitted), the value is null when the run has no pay period on record.

Nullable for the same reason as pay_period_start — see that field.

The funding classifier's verdict, independent of status. unfunded: nothing attributable arrived. partially_funded: money arrived and is short of funding_amount — payroll_runs.execute answers 409 payroll_run_underfunded naming the shortfall. funded: the confirmed amount matches. overfunded: more arrived than was asked for; the run may execute and the surplus is recorded.

Derived from funding_state: true when money was observed but the amount is short, is in surplus, or was never confirmed at all. Advisory — the refusal that actually protects the money is on execute.

How the employer funds the run: fiat by bank transfer to a Bridge virtual account, crypto by sending USDC to the employer's Bridge payroll wallet. crypto is offered per currency by GET /v1/capabilities?product=payroll (funding_currencies[].crypto_funding); while crypto funding is switched off it answers 409 capability_unavailable on create, approve and the funding call — it is never silently substituted with a fiat instruction.

Counts over this run's items, by destination readiness.

A money value. amount is a minor-unit integer as a string; decimals states the scale so a client never re-derives it (USDC is 6). Floats never appear on a money path.

A money value. amount is a minor-unit integer as a string; decimals states the scale so a client never re-derives it (USDC is 6). Floats never appear on a money path.

A money value. amount is a minor-unit integer as a string; decimals states the scale so a client never re-derives it (USDC is 6). Floats never appear on a money path.

The inbound amount the funding classifier attributed to this run and compared against funding_amount. Denominated in the currency the money actually arrived in: the run's own currency on the bank rail, USDC on the crypto rail, where the requirement itself was converted before it was compared. It is never restated into another currency. Null means no amount was ever confirmed — and a run with a null value here cannot execute.

The asset this run's funding pool holds — what the deposit becomes in the employer's Bridge payroll wallet and what every payout is paid out of. USDC for every run, or EURC for an EUR run whose recipients chose EURC wallets, where the EURC pool is enabled for the account. Chosen at approve from the wallet destinations (one pool per run: a run that mixes EURC and USDC wallets answers 409 run_mixed_pool) and never changed once money was observed (409 pool_asset_locked). Null while the run's funding records no pool: before approve (and on a run cancelled before it), or on an older approved run whose funding recorded no wallet. Read-only.

Present once a funding attempt has been requested; null before that.

A funding event was observed for this run — not proof the run is fully funded.

Prefixed, opaque. The prefix is part of the contract; the suffix is never parsed.

A1-2: open — an unrecognized member is an opaque string, never a deserialization failure.

The run's lifecycle. draft and approved are DB-legal but not reachable through a /v1 action of this caller's own: runs_create writes reviewed directly and runs_approve writes funding_pending directly, so neither state is ever produced by this API — only an internal ops webhook (or a seeded row) can leave one in draft or approved. Both are published in this enum regardless (G decision 2026-09-14): GET /v1/payroll_runs reads real rows, and a caller-unreachable status is still a status a real row can carry — omitting it 500'd the entire list the moment one such row existed, rather than 200ing every row but that one. funded: an inbound funding event was observed — it does not mean the run is fully funded; read funding_state, funding_confirmed_amount and needs_attention. Execution is refused for a funded run whose funding_state is not funded or overfunded.

ISO 4217 code the run pays in.

payroll_runs.pay_period_start is a NULLABLE DB column — the internal create path (optionalDate) writes null whenever the caller omits it, and most real rows do (prod: 59 of 74 rows, 21 of 25 employers, have a null pay period on at least one side). respondValidated's .strict() parse used to require a string here, so that dominant row shape 500'd the entire list the same way the missing draft/approved enum values did (BL-15) — the key stays present (never omitted), the value is null when the run has no pay period on record.

Nullable for the same reason as pay_period_start — see that field.

The funding classifier's verdict, independent of status. unfunded: nothing attributable arrived. partially_funded: money arrived and is short of funding_amount — payroll_runs.execute answers 409 payroll_run_underfunded naming the shortfall. funded: the confirmed amount matches. overfunded: more arrived than was asked for; the run may execute and the surplus is recorded.

Derived from funding_state: true when money was observed but the amount is short, is in surplus, or was never confirmed at all. Advisory — the refusal that actually protects the money is on execute.

How the employer funds the run: fiat by bank transfer to a Bridge virtual account, crypto by sending USDC to the employer's Bridge payroll wallet. crypto is offered per currency by GET /v1/capabilities?product=payroll (funding_currencies[].crypto_funding); while crypto funding is switched off it answers 409 capability_unavailable on create, approve and the funding call — it is never silently substituted with a fiat instruction.

Counts over this run's items, by destination readiness.

A money value. amount is a minor-unit integer as a string; decimals states the scale so a client never re-derives it (USDC is 6). Floats never appear on a money path.

A money value. amount is a minor-unit integer as a string; decimals states the scale so a client never re-derives it (USDC is 6). Floats never appear on a money path.

A money value. amount is a minor-unit integer as a string; decimals states the scale so a client never re-derives it (USDC is 6). Floats never appear on a money path.

The inbound amount the funding classifier attributed to this run and compared against funding_amount. Denominated in the currency the money actually arrived in: the run's own currency on the bank rail, USDC on the crypto rail, where the requirement itself was converted before it was compared. It is never restated into another currency. Null means no amount was ever confirmed — and a run with a null value here cannot execute.

The asset this run's funding pool holds — what the deposit becomes in the employer's Bridge payroll wallet and what every payout is paid out of. USDC for every run, or EURC for an EUR run whose recipients chose EURC wallets, where the EURC pool is enabled for the account. Chosen at approve from the wallet destinations (one pool per run: a run that mixes EURC and USDC wallets answers 409 run_mixed_pool) and never changed once money was observed (409 pool_asset_locked). Null while the run's funding records no pool: before approve (and on a run cancelled before it), or on an older approved run whose funding recorded no wallet. Read-only.

Present once a funding attempt has been requested; null before that.

A funding event was observed for this run — not proof the run is fully funded.

Prefixed, opaque. The prefix is part of the contract; the suffix is never parsed.

A1-2: open — an unrecognized member is an opaque string, never a deserialization failure.

The run's lifecycle. draft and approved are DB-legal but not reachable through a /v1 action of this caller's own: runs_create writes reviewed directly and runs_approve writes funding_pending directly, so neither state is ever produced by this API — only an internal ops webhook (or a seeded row) can leave one in draft or approved. Both are published in this enum regardless (G decision 2026-09-14): GET /v1/payroll_runs reads real rows, and a caller-unreachable status is still a status a real row can carry — omitting it 500'd the entire list the moment one such row existed, rather than 200ing every row but that one. funded: an inbound funding event was observed — it does not mean the run is fully funded; read funding_state, funding_confirmed_amount and needs_attention. Execution is refused for a funded run whose funding_state is not funded or overfunded.

ISO 4217 code the run pays in.

payroll_runs.pay_period_start is a NULLABLE DB column — the internal create path (optionalDate) writes null whenever the caller omits it, and most real rows do (prod: 59 of 74 rows, 21 of 25 employers, have a null pay period on at least one side). respondValidated's .strict() parse used to require a string here, so that dominant row shape 500'd the entire list the same way the missing draft/approved enum values did (BL-15) — the key stays present (never omitted), the value is null when the run has no pay period on record.

Nullable for the same reason as pay_period_start — see that field.

The funding classifier's verdict, independent of status. unfunded: nothing attributable arrived. partially_funded: money arrived and is short of funding_amount — payroll_runs.execute answers 409 payroll_run_underfunded naming the shortfall. funded: the confirmed amount matches. overfunded: more arrived than was asked for; the run may execute and the surplus is recorded.

Derived from funding_state: true when money was observed but the amount is short, is in surplus, or was never confirmed at all. Advisory — the refusal that actually protects the money is on execute.

How the employer funds the run: fiat by bank transfer to a Bridge virtual account, crypto by sending USDC to the employer's Bridge payroll wallet. crypto is offered per currency by GET /v1/capabilities?product=payroll (funding_currencies[].crypto_funding); while crypto funding is switched off it answers 409 capability_unavailable on create, approve and the funding call — it is never silently substituted with a fiat instruction.

Counts over this run's items, by destination readiness.

A money value. amount is a minor-unit integer as a string; decimals states the scale so a client never re-derives it (USDC is 6). Floats never appear on a money path.

A money value. amount is a minor-unit integer as a string; decimals states the scale so a client never re-derives it (USDC is 6). Floats never appear on a money path.

A money value. amount is a minor-unit integer as a string; decimals states the scale so a client never re-derives it (USDC is 6). Floats never appear on a money path.

The inbound amount the funding classifier attributed to this run and compared against funding_amount. Denominated in the currency the money actually arrived in: the run's own currency on the bank rail, USDC on the crypto rail, where the requirement itself was converted before it was compared. It is never restated into another currency. Null means no amount was ever confirmed — and a run with a null value here cannot execute.

The asset this run's funding pool holds — what the deposit becomes in the employer's Bridge payroll wallet and what every payout is paid out of. USDC for every run, or EURC for an EUR run whose recipients chose EURC wallets, where the EURC pool is enabled for the account. Chosen at approve from the wallet destinations (one pool per run: a run that mixes EURC and USDC wallets answers 409 run_mixed_pool) and never changed once money was observed (409 pool_asset_locked). Null while the run's funding records no pool: before approve (and on a run cancelled before it), or on an older approved run whose funding recorded no wallet. Read-only.

Present once a funding attempt has been requested; null before that.

A funding event was observed for this run — not proof the run is fully funded.

Prefixed, opaque. The prefix is part of the contract; the suffix is never parsed.

A1-2: open — an unrecognized member is an opaque string, never a deserialization failure.

The run's lifecycle. draft and approved are DB-legal but not reachable through a /v1 action of this caller's own: runs_create writes reviewed directly and runs_approve writes funding_pending directly, so neither state is ever produced by this API — only an internal ops webhook (or a seeded row) can leave one in draft or approved. Both are published in this enum regardless (G decision 2026-09-14): GET /v1/payroll_runs reads real rows, and a caller-unreachable status is still a status a real row can carry — omitting it 500'd the entire list the moment one such row existed, rather than 200ing every row but that one. funded: an inbound funding event was observed — it does not mean the run is fully funded; read funding_state, funding_confirmed_amount and needs_attention. Execution is refused for a funded run whose funding_state is not funded or overfunded.

ISO 4217 code the run pays in.

payroll_runs.pay_period_start is a NULLABLE DB column — the internal create path (optionalDate) writes null whenever the caller omits it, and most real rows do (prod: 59 of 74 rows, 21 of 25 employers, have a null pay period on at least one side). respondValidated's .strict() parse used to require a string here, so that dominant row shape 500'd the entire list the same way the missing draft/approved enum values did (BL-15) — the key stays present (never omitted), the value is null when the run has no pay period on record.

Nullable for the same reason as pay_period_start — see that field.

The funding classifier's verdict, independent of status. unfunded: nothing attributable arrived. partially_funded: money arrived and is short of funding_amount — payroll_runs.execute answers 409 payroll_run_underfunded naming the shortfall. funded: the confirmed amount matches. overfunded: more arrived than was asked for; the run may execute and the surplus is recorded.

Derived from funding_state: true when money was observed but the amount is short, is in surplus, or was never confirmed at all. Advisory — the refusal that actually protects the money is on execute.

How the employer funds the run: fiat by bank transfer to a Bridge virtual account, crypto by sending USDC to the employer's Bridge payroll wallet. crypto is offered per currency by GET /v1/capabilities?product=payroll (funding_currencies[].crypto_funding); while crypto funding is switched off it answers 409 capability_unavailable on create, approve and the funding call — it is never silently substituted with a fiat instruction.

Counts over this run's items, by destination readiness.

A money value. amount is a minor-unit integer as a string; decimals states the scale so a client never re-derives it (USDC is 6). Floats never appear on a money path.

A money value. amount is a minor-unit integer as a string; decimals states the scale so a client never re-derives it (USDC is 6). Floats never appear on a money path.

A money value. amount is a minor-unit integer as a string; decimals states the scale so a client never re-derives it (USDC is 6). Floats never appear on a money path.

The inbound amount the funding classifier attributed to this run and compared against funding_amount. Denominated in the currency the money actually arrived in: the run's own currency on the bank rail, USDC on the crypto rail, where the requirement itself was converted before it was compared. It is never restated into another currency. Null means no amount was ever confirmed — and a run with a null value here cannot execute.

The asset this run's funding pool holds — what the deposit becomes in the employer's Bridge payroll wallet and what every payout is paid out of. USDC for every run, or EURC for an EUR run whose recipients chose EURC wallets, where the EURC pool is enabled for the account. Chosen at approve from the wallet destinations (one pool per run: a run that mixes EURC and USDC wallets answers 409 run_mixed_pool) and never changed once money was observed (409 pool_asset_locked). Null while the run's funding records no pool: before approve (and on a run cancelled before it), or on an older approved run whose funding recorded no wallet. Read-only.

Present once a funding attempt has been requested; null before that.

A funding event was observed for this run — not proof the run is fully funded.

PAYROLL- plus the run id, stripped of non-alphanumerics, first 12 characters, upper-cased.

The rail family behind these instructions (bank or crypto), driving which of bank/crypto below is populated. A run whose funding_method is crypto reads crypto_deposit_to_wallet in every state before verified.

Present when funding_route_type is bank. beneficiary_name carries what was previously beneficiary; rail is the single settlement rail for this instruction (the run's own run_reference above stays on the parent object, not nested here).

Present when funding_route_type is crypto_deposit_to_wallet and status is verified: the employer's Bridge payroll wallet — address (case-preserved, send to it verbatim), chain (the wallet's chain, e.g. solana), asset (USDC) and amount, the run's funding_amount (fee included) converted to USDC when the instructions were prepared. Send the whole amount in ONE transfer of asset on chain: deposits on this route are not summed — a short deposit leaves the run partially_funded, and a top-up does not fund it (contact support). A later funding call without a method switch returns this same amount; it is never re-priced under a deposit already sent. This whole object is null (never a zero-valued object) when the amount cannot be priced; status then reads failed with failure_reason: fx_unconverted. This route answers capability_unavailable on create/approve/refresh while crypto funding is switched off — it is never returned as a silent substitute for the bank shape, and the bank shape is never returned as a silent substitute for it.

Normalized only — never the raw Bridge or provider error text. A snake_case code (for example bridge_wallet_address_unavailable); provider_error when the provider failed with text that is not published. On blocked, the first blocker's code — for example bank_payout_fx_unsupported, a bank row on a run whose pool is not paid out 1:1 in the run currency: a non-USD run paid out of the USDC its funding converted into, or an EUR run's EURC pool (bank payouts from an EURC pool are not offered yet) — or deposit_window_expired, a crypto run whose deposit details were issued more than 14 days ago (held for review; not retryable). A BRL (Pix) or MXN (SPEI) bank funding account opens only under the employer's own deposit approval at Bridge, checked before the account is requested: funding_endorsement_required (a verification step is left — finish it, then retry), funding_endorsement_in_review (Bridge is reviewing it; retry later) or funding_rail_not_available (Bridge does not offer that deposit rail to this employer, e.g. Pix to a non-Brazilian resident; not retryable) on blocked, and funding_endorsement_unverifiable (the approval could not be read; retryable) on failed.

PAYROLL- plus the run id, stripped of non-alphanumerics, first 12 characters, upper-cased.

The rail family behind these instructions (bank or crypto), driving which of bank/crypto below is populated. A run whose funding_method is crypto reads crypto_deposit_to_wallet in every state before verified.

Present when funding_route_type is bank. beneficiary_name carries what was previously beneficiary; rail is the single settlement rail for this instruction (the run's own run_reference above stays on the parent object, not nested here).

Present when funding_route_type is crypto_deposit_to_wallet and status is verified: the employer's Bridge payroll wallet — address (case-preserved, send to it verbatim), chain (the wallet's chain, e.g. solana), asset (USDC) and amount, the run's funding_amount (fee included) converted to USDC when the instructions were prepared. Send the whole amount in ONE transfer of asset on chain: deposits on this route are not summed — a short deposit leaves the run partially_funded, and a top-up does not fund it (contact support). A later funding call without a method switch returns this same amount; it is never re-priced under a deposit already sent. This whole object is null (never a zero-valued object) when the amount cannot be priced; status then reads failed with failure_reason: fx_unconverted. This route answers capability_unavailable on create/approve/refresh while crypto funding is switched off — it is never returned as a silent substitute for the bank shape, and the bank shape is never returned as a silent substitute for it.

Normalized only — never the raw Bridge or provider error text. A snake_case code (for example bridge_wallet_address_unavailable); provider_error when the provider failed with text that is not published. On blocked, the first blocker's code — for example bank_payout_fx_unsupported, a bank row on a run whose pool is not paid out 1:1 in the run currency: a non-USD run paid out of the USDC its funding converted into, or an EUR run's EURC pool (bank payouts from an EURC pool are not offered yet) — or deposit_window_expired, a crypto run whose deposit details were issued more than 14 days ago (held for review; not retryable). A BRL (Pix) or MXN (SPEI) bank funding account opens only under the employer's own deposit approval at Bridge, checked before the account is requested: funding_endorsement_required (a verification step is left — finish it, then retry), funding_endorsement_in_review (Bridge is reviewing it; retry later) or funding_rail_not_available (Bridge does not offer that deposit rail to this employer, e.g. Pix to a non-Brazilian resident; not retryable) on blocked, and funding_endorsement_unverifiable (the approval could not be read; retryable) on failed.

A1-2: required (still nullable) — every producer already emits null rather than omitting the field when there is no next page, so this only removes a third, unused wire state (absent) a strict client had to handle for nothing.

Prefixed, opaque. The prefix is part of the contract; the suffix is never parsed.

Frozen at run creation — does not track later edits to the recipient record.

The item's payout lifecycle inside its run (R14-payroll §4). No item-level cancelled exists — cancelling a run leaves its items wherever they were.

A money value. amount is a minor-unit integer as a string; decimals states the scale so a client never re-derives it (USDC is 6). Floats never appear on a money path.

Null while destination_status is missing.

Planned — no producer exists yet (payroll_run_items carries no such column and payroll_events mints no such event today); a caller must not read this as a live signal until a producer ships. Always false until then.

Present only when this item pays a local bank account in another currency than the run's — a USD run paying BRL by Pix, MXN by SPEI or COP by Bre-B. The item's amount stays in the run currency; Bridge converts it once, at payout, at its own rate (its FX spread is inside that rate, never a second deduction). estimate is Bridge's non-binding figure from when the account was saved; delivered is exactly what Bridge's receipt says arrived, set only once the payout is paid and cleared if it is returned — never the estimate in its place.

One recipient's line inside a run — a masked destination projection, never the raw bank or wallet detail (mirrors the payouts beneficiary projection).

The employer's own copy of the recipient's onboarding link. The token appears ONLY inside url, never as a bare field, and only to this run's own employer (the same trust boundary the operation description states). Null on an Idempotent-Replayed response — the token is shown once, never re-served from the idempotency store (AuthenticatedRoute.secretFields, the same mechanism api_keys' own secret uses).

A1-2: required (still nullable) — every producer already emits null rather than omitting the field when there is no next page, so this only removes a third, unused wire state (absent) a strict client had to handle for nothing.

A1-2: required (still nullable) — every producer already emits null rather than omitting the field when there is no next page, so this only removes a third, unused wire state (absent) a strict client had to handle for nothing.

A1-2: required (still nullable) — every producer already emits null rather than omitting the field when there is no next page, so this only removes a third, unused wire state (absent) a strict client had to handle for nothing.

Prefixed, opaque. The prefix is part of the contract; the suffix is never parsed.

Non-null only once the employer has adopted a recipient-supplied destination onto the roster (payroll_recipients.adopt_pending_destination) — for where a specific payment actually lands, read payroll_run_items.destination_snapshot instead; null for every recipient with no adopted destination, including rows created before this field existed, which are never backfilled.

null when nothing is waiting. Independent of destination_status: a recipient with a ready default can also have a newer destination waiting.

A payee referenced by one or more runs. Created only as a byproduct of create — there is no direct create, update or archive on /v1; the one write is adopt_pending_destination, which saves the destination in pending_destination as the default. email is genuinely optional: existing rows can be email-less — from data that predates this field's own validation, or from the legacy dashboard-v1 action handler (payroll/actions.ts's own optionalEmail) — even though the public POST /v1/payroll_runs itself always requires recipient.email and accepts no destination input of its own (PayrollRunCreateRequest; a /v1 caller cannot currently create an email-less row this way — Codex review finding, round 12, correcting an earlier description here that implied it could). The sibling PayrollRunItem.recipient_snapshot.email and PayrollTemplate.items_snapshot[].recipient.email already model the identical optionality for the identical field on those resources (Codex review finding, round 7 — email was required here only, out of step with every other resource carrying the same field, and the list route's .strict() validation of every returned row meant one such legitimately-email-less recipient failed the ENTIRE list response with a 500, not just its own row).

A1-2: required (still nullable) — every producer already emits null rather than omitting the field when there is no next page, so this only removes a third, unused wire state (absent) a strict client had to handle for nothing.

Prefixed, opaque. The prefix is part of the contract; the suffix is never parsed.

The source run's items at the moment the template was saved.

Prefixed, opaque. The prefix is part of the contract; the suffix is never parsed.

The source run's items at the moment the template was saved.

A money value. amount is a minor-unit integer as a string; decimals states the scale so a client never re-derives it (USDC is 6). Floats never appear on a money path.

Humanised item state. locked covers every status past ready — the page shows one line, never a per-status detail.

Whether payroll_recipient_sessions.destination.set will currently accept a submission from this token. status alone stopped predicting this once a ready item's parent run could also lock it: a ready item reads can_update_destination: false once the run has moved past draft/reviewed (approved onward), and a needs_destination item reads false once the run is cancelled/completed/failed — nothing will ever be approved against it. Check this before rendering the destination form rather than inferring it from status.

The employer's real business name, not an internal handle.

Only present on payroll_recipient_sessions.destination.set, and only for the holder that just used the old token. Changing a destination retires the token that did it and mints a replacement, so a leaked copy of a payslip link cannot redirect the same payout twice. Use this value for every subsequent call; the token in the path you just called is dead.

Null until a destination is saved for this run item.

Present only when this item pays a local bank account in another currency than the run's — a USD run paying BRL by Pix, MXN by SPEI or COP by Bre-B. The item's amount stays in the run currency; Bridge converts it once, at payout, at its own rate (its FX spread is inside that rate, never a second deduction). estimate is Bridge's non-binding figure from when the account was saved; delivered is exactly what Bridge's receipt says arrived, set only once the payout is paid and cleared if it is returned — never the estimate in its place.