/revenue-attributions and /revenue-attributions/{id}, where id is a job ID. Every owned job with an available owned account has a representation, including jobs with credits:[]. Page by job ID ascending and replace each refreshed job’s complete array. A credit records its type, signed revenue_cents, credited member, optional current invoice and matching invoice line IDs. Credits have no separate public IDs or save timestamps.
Query credit details or member totals
Independent credit measures
Credits are the amounts explicitly saved by the company. Each selected person can receive the whole item amount independently for SOLD and EARNED. Keep those measures separate, and do not sum member credit rows as company revenue. Zero and negative credits remain meaningful recorded entries. Reading does not infer credit from participation, divide it among people, recalculate invoice prices, or require current payment status, job-cost tracking or verification.Report dates and totals
report_date is the company-local date of work_completed_at, with no fallback. The summary uses this date, matching the existing backend technician-performance export; the current team dashboard uses revenue recognition (closure, then work completion), so date selection can differ. Jobs without work completion remain readable with a null report date and do not contribute to any dated summary. The report uses the shared half-open date ranges, clipped day/week/month/quarter/year buckets, and omitted empty buckets.
The summary always groups by credited team member. It returns separate sold_revenue_cents, earned_revenue_cents, their respective credit counts, and the distinct count of jobs with contributing credits. A zero sum with a positive credit count differs from no recorded credit. Inactive and non-technician members remain named. A null member group retains saved credits for unavailable people and can combine several people. It does not assert an anonymous person or invent a replacement identity.
Current references and joins
Current references provide context for saved credits. Missing or foreign people and invoices become null while the owned credit amount remains included. Invoice context requires a currently owned invoice and account with that job link, regardless of invoice status.invoice_line_item_ids lists current owned invoice lines matching the recorded cart key or owned original pricebook key. Several lines can share one original catalog item and match one saved credit; count that credit once. An empty array means no currently resolvable matching line. Do not recalculate a historical credit from the current matching lines, or use array positions as durable credit IDs. Identical-looking entries with unavailable references remain separate saved credits.
Join the parent ID to /jobs and /job-financials, team_member.id to /team-members, and invoice.id to /invoices; match line IDs within that invoice’s line_items. Collection filters include job IDs, location, account, business unit, job type/class, job-creation bounds and completion-date report_from/report_before. team_member_id and credit_type must match the same credit to select a job, but its returned array remains complete. In the report those filters select contributing credits, so filtering SOLD leaves earned count and cents at zero. There is no grouping override, inferred attribution mode or combined sold-plus-earned total.
Refresh complete credit sets
Attribution has no reliableupdated_since: saves replace entire job credit sets and related records can change independently. Refresh known job IDs and recent completion-date windows, then periodically reconcile broader scopes. Replace complete arrays, including newly empty arrays. Work-date corrections can move a job between windows or make it undated; absence from a filtered window is not a deletion signal. Report cursors page current results rather than a snapshot. As with profitability, amounts outside the safe integer cents range return the standard 500 without rounding, clamping or partial results.