/cms_open_payments/recipients/payments-summary

POST /api/cms_open_payments/recipients/payments-summary

Price: 1 credit

Get per-company payment totals received by a CMS Open Payments recipient (all years)

How to use it

Get the all-years summary of payments received by a single CMS Open Payments recipient, broken down by paying manufacturer or group purchasing organization. Provide the recipient's CMS profile id. Each row shows the paying entity, payment category, the number of transactions and the total amount that entity paid the recipient — i.e. who paid this recipient and how much.

Parameters

• access-token string required

Request body

• timeout integer — Max scrapping execution timeout (in seconds) (default: 300; min: 20; max: 1500)
• recipient_id string required — CMS covered recipient profile id (minLength: 1)
• count integer required — Max number of results (min: 1)
• payment_type string nullable — Filter by payment category (one of: "General", "Research", "Ownership")

Response

• @type string (default: "CmsRecipientPaymentSummary")
• recipient_id string required
• recipient_type string nullable
• recipient_npi string nullable
• recipient_first_name string nullable
• recipient_middle_name string nullable
• recipient_last_name string nullable
• teaching_hospital_name string nullable
• payment_type string nullable
• manufacturer_id string nullable
• manufacturer_name string nullable
• number_of_transactions integer nullable
• total_amount number nullable

Errors

• 422 — The request body did not validate Check the fields against this schema. A URN with the wrong prefix is the most common cause.
• 408 — The request ran past its time limit Raise `timeout` in the request body, up to the maximum this endpoint documents. Lowering `count` or turning off the `with_*` flags also helps, because less work finishes sooner.
• 412 — Recipient not found Retrying will not help: either the entity does not exist, or the input points at a different one.
• 429 — Too many requests: a rate limit or a usage window is exhausted When the response carries an X-Retry-After header, wait that many seconds and retry: the same number is in the body as `detail.retry_after`, and the limit clears once that window passes. The message in the body names the limit that was hit.
• 500 — Something broke on our side Retrying will not help. If it keeps happening, send us the X-Request-ID from the response headers.
• 529 — Rate limit reached, or the endpoint is overloaded Wait at least 30 seconds, then retry.

Response headers

• X-Error — Error message text (present only on error)
• X-Request-ID — Unique request identifier
• X-Execution-Time — Execution time in seconds
• X-Result-Count — How many records the body carries. 0 means an empty result, which is a normal answer and not by itself an error. A non-zero count can come back together with X-Error when the failure happened partway through — read this header and X-Error independently.
• X-Total-Available-Results — How many records exist for this query, when the endpoint can say. On a `dry_run` request this is the answer and the body is empty. It saturates: the endpoint's documented maximum means 'at least that many', any smaller number is exact.
• X-Warning — Present when the request body carried keys this endpoint does not document. They were ignored, so any filter you meant to apply through them did not apply. Check the spelling against this schema and retry.
• X-Retry-After — Seconds to wait before retrying. Present only on 429.