Skip to main content
The Revenue Reporting API returns the same rows as the nightly accounting files Cedar delivers to your SFTP folder, as JSON you can request on demand. Ask for any range of reporting days, filter by car or waybill, and page through the results.
The rows for a day are the rows of that day’s file, in the same order. Only the formatting differs: real dates and times instead of fixed-width text, dollar amounts instead of cents, and spelled-out values instead of codes. Each row also carries fields the files do not have, such as CIF numbers, addresses, SPLC/FSAC codes and commodity names.

Endpoints

The base URL is https://api-lg-k.arms.cedarai.com.

Authentication

Send the same headers as every Cedar API, plus Carrier: The user in x-arms-assume-user needs the revenueReporting.api role on that railroad.⁠‌​‌‌‌​​‌‌​‌​​‌​​​‌​​‌‌​‌⁠ One key can read several railroads if its user has the role on each.

Choosing days

Every endpoint except funds-transfers takes the same required parameters:
  • startDate and endDate — YYYY-MM-DD, both inclusive, in the railroad’s local time zone. For one day, send the same date twice.
  • The range can be as long as you like. Long ranges come back over several pages; see Paging.
funds-transfers takes month instead, as YYYY-MM (for example 2026-10), because Railinc settles interline revenue monthly. It returns every funds transfer whose transfer date falls in that month, read from the Daily Settlement Reports. Each row keeps the day it settled, and a month’s transfers are there before Railinc’s month-end notification arrives. When Railinc sends a revised report, its lines replace the ones it revises, so a transfer is listed once. These are the transfers of that month’s Funds Transfer Monthly file; the two differ only when Cedar is missing one of the daily reports or the notification. daily-settlements is a record of each night’s reports, so it lists both the original and the revised report. The nightly Daily Interchanges file covers the 7 days before its run date. The interchanges endpoint returns exactly the days you ask for, so to reproduce a night’s file, ask for the 7 days before that night.
Data for a day that has not ended yet is incomplete. Pull up to yesterday.

Filters

Every endpoint accepts the same optional filters, which match the car and waybill on each row:
  • equipmentInitial and equipmentNumber — one car. Send both or neither.
  • waybillNumber
  • waybillDate — YYYY-MM-DD.
Leading zeros and letter case are ignored.⁠‌​‌‌‌​​‌‌​‌​​‌​​​‌​​‌‌​‌⁠ Filters combine: a row must match every filter you send.

Paging

  • pageSize — rows per page. Defaults to 500; the most is 1000.
  • When more rows remain, the response has a nextPageToken. Send it back as pageToken, with the same dates and filters, to get the next page. When the response has no nextPageToken, you have every row.
  • Each page covers at most 31 reporting days. Over a long range, a page can have fewer rows than pageSize, or none, and still have a nextPageToken. Keep following the token until it is gone.
A token only works with the dates and filters it was issued for. If the underlying data changes between pages, a row can move between pages.

Example

How values are written

  • Field names are camelCase, in responses and in query parameters (reportDate, startDate). Query parameters also accept snake_case (start_date).
  • Dates are YYYY-MM-DD. Times are RFC 3339 with the railroad’s UTC offset, for example 2026-11-01T09:14:52-05:00.
  • Money is an object with a decimal string amount ("1225.00") and a currency.
  • 64-bit numbers, such as numberOfCars and netWeightLbs, are JSON strings, as is standard for these APIs.
  • Parties (shipper, consignee, freight-bill party, bill-to) are identified by their Railinc CIF with its 4-character location suffix (13 characters, such as 0529862500000), with the address as billed on the waybill. accountNumber is your own account number for the customer, from its Cedar customer location.
  • Stations carry the station name, state, SPLC, FSAC (five digits) and the railroad serving them on that move. These come from the industry station master rather than the waybill, which often leaves the SPLC blank.
  • settlementStatus is the URRWIN’s status as of the end of the row’s reportDate, from the last settlement message Railinc sent before then. Pulling a past day again gives the status it had that day, not today’s.
  • The car on a Waybill Extract row is the one recorded on the transaction when it was made, so it stays the same if the shipment later moves to another car.
  • A text, number or true/false field Cedar has no value for is sent empty: "", 0 or false. For example, a local move has no URRWIN, so urrwin.number is "" and urrwin.version is 0. A list with no entries is []. A party Cedar has nothing for, and settlementStatus on a row that has not settled, are left out.

File columns and API fields

The other reports follow the same pattern; each endpoint’s reference page lists every field.

Deletions in the Waybill Extract

A TRANSACTION_DELETED or TRANSACTION_UNDELETED row appears only for a transaction that was sent to you in an earlier day’s rows, the same rule the file follows.⁠‌​‌‌‌​​‌‌​‌​​‌​​​‌​​‌‌​‌⁠ It carries the deleted transaction’s id and fields, with transaction.at set to when it was deleted and transaction.originalAt to when the transaction was made.

Errors

An error comes back with an HTTP status and a JSON body that says what was wrong: